上面已經介紹了使用者業務上雲時如何進行網絡設計、運維管理環境規劃，本章将重點介紹如何基于阿裡雲産品和服務設計應用系統架構。
3.3.1 負載均衡
阿裡雲負載均衡（Server Load Balancer，SLB）是将通路流量根據轉發政策分發到後端多台ECS的流量分發控制服務。使用者可以通過負載均衡的流量分發擴充應用系統對外的服務能力，通過消除單點故障提升應用系統的可用性。
阿裡雲負載均衡主要功能：
負載均衡服務通過設定虛拟服務位址（IP），将多台雲伺服器ECS執行個體虛拟成一個高性能、高可用的應用服務池。根據應用指定的方式，将來自用戶端的網絡請求分發到雲伺服器池中。
負載均衡服務會檢查雲伺服器池中ECS的健康狀态，自動隔離異常狀态的ECS，進而解決單台ECS的單點問題，同時提高應用的整體服務能力。
在标準的負載均衡功能之外，負載均衡服務還具備TCP與HTTP抗DDoS攻擊的特性，增強應用伺服器的防護能力。
負載均衡服務是ECS面向多機方案的一個配套服務，需要同ECS結合使用。
在阿裡雲平台之上，使用者應用可以使用SLB軟負載均衡産品實作Web伺服器和應用伺服器的自動負載均衡和故障檢測。阿裡雲SLB負載均衡産品可支援四層TCP協定和七層HTTPHTTPS協定。
3.3.2 可擴充性
前面介紹了阿裡雲上應用系統接入層的設計，本節将介紹應用系統的可擴充性設計。應用系統可擴充性設計主要包含應用程式層的可擴充性設計和資料存儲層的可擴充性設計。
1 . 應用程式可擴充性設計
采用縱向擴充時，無須擔心如何處理使用者請求，這些請求都将彙集到單個伺服器的網絡接口卡上，并且得到處理，對它們的恢複也是通過網卡發送的。在不同處理器之間配置設定負載的具體任務，就交給作業系統排程程式來完成。如果應用程式是多程序的，可以給每個處理器配置設定一個子程序，然後同時處理多個請求。
但在橫向擴充時，新問題出現了。我們有多個處理器，卻沒有作業系統配置設定請求。我們将在同一IP位址收到多個請求，而且希望在多台機器上服務這些請求。
最簡單解決方案是引入應用層的負載均衡方案。一種方式是在DNS中為應用程式的域名建立一條以上的記錄。通過DNS輪詢随機将業務請求發送給實際提供服務的主機進行處理，以擴充應用伺服器的處理能力。但此方案存在一個問題，即DNS服務無法自動發現後端出現異常的應用伺服器，并自動屏蔽故障應用伺服器對業務的影響。另外一種方式是使用阿裡雲SLB産品，作為統一接入層對外提供服務，SLB可自動轉發業務流量到不同的後端伺服器進行處理，并自動檢測後端應用伺服器是否正常，主動發現和處理異常應用伺服器。
2 . 資料存儲層可擴充性設計
阿裡雲上資料存儲層的常用産品有RDS關系資料庫服務、OSS對象存儲服務和Redis資料緩存服務。OSS對象存儲服務可動态擴充存儲容量和通路量，無須使用者在業務層考慮容量的可擴充性設計。下面将重點介紹RDS關系資料庫服務和Redis資料緩存服務應如何實作可擴充性設計。
Redis資料緩存服務可支援主從版和叢集版兩種執行個體，如果使用者業務在存儲量或通路量急劇增加，已超過之前設計容量時，使用者可以考慮通過擴充Redis執行個體規格或從主從版執行個體更新為叢集版執行個體，來實作Redis資料緩存在存儲容量和通路量方面的能力提升。使用者使用阿裡雲Redis服務時，如果業務遇到執行個體通路量QPS的CPU瓶頸，需要通過擴充Redis執行個體節點數目來解決，如考慮從主從版Redis執行個體更新為叢集版Redis執行個體，或從低規格的叢集版Redis執行個體更新高規格叢集版Redis執行個體。
RDS關系資料庫服務的擴充能力，主要從以下幾個次元考慮：
更新RDS執行個體規格：可在一定程度上擴充RDS讀寫請求的處理能力和存儲容量。
引入RDS隻讀執行個體：使用DRDS實作自動讀寫分離，可擴充RDS資料庫的讀流量，适用于讀多寫少的業務場景。
引入Redis進行熱點資料緩存：這同樣适用于讀多寫少和高性能、低延時的場景，需要業務代碼能維護好Redis緩存和RDS關系資料庫的資料一緻性。
使用DRDS分庫分表功能實作RDS資料庫存儲容量和讀寫通路量的可擴充性設計：這适用于隻讀執行個體、緩存、執行個體規格更新無法解決的場景。由于DRDS引入了分布式存儲技術，需要對業務進行合理規劃和設計盡量避免分布式問題。
3.3.3 微服務
1 . 微服務與傳統的集中化開發方式的差異
在傳統的開發模式下，所有的功能打包在一個WAR包裡，基本沒有外部依賴，部署在一個J2EE容器（Tomcat、JBoss、WebLogic）裡，包含DO/DAO、Service、UI等所有邏輯。所有的邏輯組合成一個龐大的運維單元，獨立進行開發、更新、測試、部署等。
而微服務架構主張網際網路應用由一系列細粒度的職責單一的服務組成，每個服務運作在各自獨立的程序中，服務之間通過輕量機制（如HTTP/JSON）進行通信。這些服務建立在業務領域之上，可通過全自動方式獨立部署。這些服務基本沒有中央式的管理，服務可以用不同的程式設計語言編寫，也可以使用不同的資料存儲技術。微服務的目的是有效地對拆分的應用進行服務治理，簡化部署，實作靈活開發和部署。
然而，微服務不是免費的午餐。微服務系統複雜度高，運維開銷大，需要完善的服務架構、傳遞、監控、安全隔離和規模擴充等必要的基礎設施的支撐，對于DevOps技能要求高。對于初創和中小規模公司來說，借助于阿裡雲的基礎設施來實作微服務的治理架構和持續傳遞，不失為最佳選擇。
2 . 服務治理架構的選擇
（1）使用Spring Cloud構造微服務
Spring Cloud是Springframework裡的一個項目，提供了開發分布式系統時比較常見的一些模式能力。其中，配置管理（Config Server）、服務發現（Eureka）、服務熔斷（Hystrix）、智能路由（Zuul）等是基于Netflix OSS的一個封裝，利用Java注解（annotation）聲明，可以在Spring Boot應用裡便捷地使用Netflix的開源産品建構生産級可用的微服務應用。而且，可以通過Docker鏡像的方式快速地在阿裡雲容器服務上部署。
（2）使用EDAS來構造微服務
EDAS産品充分利用阿裡雲的資源管理和服務體系，引入阿裡巴巴中間件整套成熟的分布式産品，全面相容Apache Tomcat的Java容器，提供高性能的分布式服務架構以及秒級推送的分布式配置管理服務。此外，EDAS還創新性地提供了分布式系統鍊路追蹤、容量規劃、資料化營運等多款元件，可以幫助企業級客戶輕松建構大型分布式應用服務系統。
在複雜的雲環境下，應用釋出與管理變得十分複雜。本地開發完成的應用需要逐個部署到伺服器，然後登入每一台伺服器終端進行應用的釋出和部署；後續還會有應用的重新開機、擴容等工作需要完成。伺服器的不斷增加對于運維人員是一個極大的挑戰。針對這個場景，EDAS 提供了一個可視化的應用釋出與管理平台，無論叢集規模多大，都可以在 Web 控制台上輕松地進行應用生命周期管理。
當從集中式應用轉變成分布式系統的時候，系統之間的可靠調用一直都是分布式架構的難題，比如需要确定網絡通信、序列化協定設計等很多技術細節。EDAS 提供了一個高性能的 RPC 架構，能夠建構高可用的分布式系統，系統地解決各個應用之間的分布式服務發現、服務路由、服務調用以及服務安全等細節。
應用開發完畢部署到生産環境之後，通常需要對應用運作時狀态進行監控，比如監控CPU使用率、機器負載、記憶體使用率和網路流量等。但此類基礎監控通常滿足不了業務需求，比如系統運作變慢卻無法定位瓶頸所在，或者頁面打開出錯但是無法排查具體調用錯誤等。對此，EDAS提供了一系列系統資料化營運元件，針對分布式系統的每一個元件和每一個服務進行精細化的監控和跟蹤，建立數字化分析系統，進而精準地找到系統瓶頸。
3 . 如何通過各種建構物實作持續傳遞方案
（1）使用阿裡雲持續傳遞平台CRP系統來進行代碼持續傳遞
阿裡雲持續傳遞平台CRP支援以滑鼠在白屏上拖拽節點的方式定義項目釋出工作流，每個節點可以加入多個任務，用以完成自動化更新代碼、編譯、運作單元測試、自動化釋出到ECS機器上的工作。
如果需要基于代碼庫，執行代碼掃描（安全檢查）→自動化編譯→測試→自動化部署到伺服器的工作時，可以在持續傳遞平台CRP上定制一條持續釋出線。持續釋出線定制完成後，當代碼更新後，CRP會監聽到分支更新了代碼，自動建立1條新的釋出線開始運作，自動進行編譯、測試、部署等工作。并且出現問題時，可以發郵件通知項目成員。
不同的技術棧有不同的建構物類型，同時也有相關的工具來建立和安裝這些建構物，例如，Ruby中有gem、Java中有WAR包、Python中有egg。我們可以通過CRP等工具部署并且啟動這些建構物，但是需要安裝和配置一些基礎環境軟體。類似于Puppet、Chef、ansible等自動化配置管理工具，可以很好地解決這個問題。通過這些工具可對不同建構物的底層部署機制進行屏蔽。
（2）ECS定制化鏡像
使用類似Puppet、Chef及Ansible這些自動化配置管理工具的一個問題是，需要花費大量時間在機器上運作這些腳本。假設伺服器在ECS上，使用的是标準的CentOS鏡像，為了運作Java應用程式，需要做的第一件事情就是安裝Oracle JVM，接下來需要安裝Tomcat容器。随着叢集規模的擴充，同樣的工具被一遍一遍地重複安裝，對技術人員而言也是一種煎熬。
減少擴容成本的一種方法就是建立一個虛拟機鏡像，鏡像是雲伺服器 ECS 執行個體運作環境的模闆，一般包括作業系統和預裝的軟體。可以使用鏡像建立新的 ECS 執行個體和更換 ECS 執行個體的系統盤。使用這種功能之後，事情就變得簡單了。現在可以把公共的工具安裝在鏡像上，然後在部署軟體時，隻需要根據鏡像建立一個執行個體，然後在其上安裝最新的服務版本即可。也就是說，隻需要建構一次鏡像，然後根據這些鏡像啟動ECS，就不需要再花費時間來安裝相應的依賴，因為它們已經在鏡像中安裝好了，這樣可以節省很多時間。如果核心依賴沒有改變，那麼新版本的服務就可以繼續使用相同的基礎鏡像。
當然，既然已經做到了使用包含依賴的虛拟機鏡像來加速傳遞，那麼還可以更進一步，把服務本身也包含在鏡像中，直接把鏡像作為建構物進行傳遞，通過阿裡雲ECS的建立自定義鏡像功能，利用自定義鏡像安裝ECS，當虛拟機啟動鏡像時，服務就已經就緒了。
通過鏡像傳遞可以屏蔽作業系統和軟體的差異性，但是如果在一次傳遞流程中，從開發測試、預生産、生産環境，每個環節都要制作自定義鏡像、重新安裝作業系統，對于疊代速度非常頻繁的應用，那麼虛拟機鏡像傳遞這種略顯笨重方式顯然是難以接受的。
如果想既傳遞服務代碼又要保證應用環境和作業系統的差異性，同時希望以靈活、輕量級的方式傳遞，那麼阿裡雲容器服務能很好地滿足這個需求。利用容器技術把應用及其依賴做成一個标準的鏡像，從開發到測試到生産環境都用同樣的容器鏡像，極大彌補了應用開發過程中開發和運維之間的傳遞鴻溝。
（3）容器服務定制化docker鏡像
阿裡雲容器服務（Container Service）提供了高性能可伸縮的容器應用管理服務，支援在一組雲伺服器上通過Docker容器來進行應用生命周期管理。容器服務極大簡化了使用者對容器管理叢集的搭建工作，無縫整合了阿裡雲虛拟化、存儲、網絡和安全能力，進而實作雲端優化的運作環境。容器服務提供了多種應用釋出方式和流水線般的持續傳遞能力，原生支援微服務架構，可幫助使用者無縫上雲并進行跨雲管理。
傳統的開發過程開發者的代碼裡有邏輯、應用以及代碼依賴包，通過使用阿裡雲容器服務，代碼中會加入Dockerfile、Docker Compose，用來制作集裝箱和搬運集裝箱。代碼送出成功後，代碼伺服器會通知持續內建服務（比如Jenkins），持續內建服務會拉取代碼進行代碼打包，打包後進行單元測試。如果單元測試沒有通過，就會馬上向開發者回報。如果通過測試，則會根據代碼中的Dockerfile制作鏡像，并把鏡像推送到阿裡雲容器倉庫服務，并用于應用傳遞。在Docker容器鏡像中可以支援不同類型的應用，無論是PHP應用還是Java應用，也就是說，不同種類的應用可以用相同的指令或API進行管理，規避了不同軟體之間的差别，标準化了軟體的建構、傳遞和運維方式。
3.3.4 異步化
在高并發量下，微服務中如果采用同步調用方式，在服務單元處理時間變長的情況下，會導緻服務線程消耗盡，遇到無法再建立線程處理服務請求的情況。對于這種情況的優化，除了在程式上不斷調優（資料庫調優、算法調優、緩存等），可以考慮在架構上做些調整，先傳回結果給用戶端，讓使用者可以繼續使用用戶端的其他操作，再把服務端的複雜邏輯處理子產品做異步化處理。
比如，一個下單系統的展現端的邏輯強依賴後端10個服務，包括減庫存、生成快照、運查詢費、優惠查詢等，其中9個都執行成功了，最後一個卻執行失敗，那麼是不是前面9個都要復原掉？如果這樣做，成本還是非常高的。是以在拆分大的流程為多個小的本地事務的前提下，對于非實時、非強一緻性的關聯業務，在本地事務執行成功後，我們選擇通過消息機制将關聯事務異步化執行，進而保障整個業務流程的高效運轉。
在阿裡雲上，可以使用阿裡雲提供的消息隊列服務（Message Queue，MQ），幫助業務開發人員完成業務流程異步化。MQ消息隊列服務是企業級網際網路架構的核心産品，基于高可用分布式叢集技術，搭建了包括釋出訂閱、消息軌迹、資源統計、定時（延時）、監控報警等一套完整的消息雲服務。MQ可以幫助使用者實作分布式計算場景中服務的異步化調用，幫助服務解耦并進行異步化改造。MQ目前提供TCP、HTTP、MQTT三種協定層面的接入方式，支援Java、C++以及.NET等程式設計語言，友善用不同程式設計語言開發的應用能快速接入MQ消息雲服務。使用者可以将應用部署在阿裡雲ECS、企業自建雲，或者嵌入到移動端、物聯網裝置中，與MQ建立連接配接并進行消息收發，同時，本地開發者也可以通過公網接入MQ服務進行消息收發。
3.3.5 高可用
建設應用系統時，特别是建設一些核心和關鍵的業務系統時，我們需要考慮和評估一些極端異常的場景或故障發生時對整個應用系統和業務的影響。例如，單個機房出現網絡或電力故障導緻機房無法對外提供服務、某個城市地震、台風等自然災害等情況。
針對這些極端場景或問題，阿裡雲提供“同城雙機房”和“兩地三中心”的災備高可用解決方案，通過在同城或者異地建立兩套或多套功能相同的應用系統，并內建健康監測和災備切換功能，當一處系統因意外（如火災、地震等）停止工作時，整個應用系統可切換到另一處備用系統，繼續對外提供服務。
1 . 同城雙機房高可用設計
圖3-4給出了同城雙機房架構。其中包括SLB網絡接入層、ECS雲伺服器Web層和應用層、RDS資料庫層以及OSS檔案存儲層。
1）SLB網絡接入層：使用者通過Internet通路BGP SLB，SLB叢集根據使用者來源IP段，将流量配置設定到不同機房的SLB節點上，實作機房間SLB雙活。
2）ECS雲伺服器Web層和應用層：在不同機房配置設定ECS資源，在不同機房完成對等的Web和應用伺服器部署，所有的Web伺服器分别挂載到對應機房的SLB上。
3）RDS資料庫層：RDS采用主備庫模式雙機房部署，資料實作近實時同步。Web & APP伺服器正常情況下隻通路RDS的Active的主庫。
4）OSS檔案存儲層：非結構化資料将存入OSS，如ECS的系統快照和RDS的資料庫備份等靜态資料會統一上傳到OSS存儲叢集上。
2 . 兩地三中心高可用方案
圖3-5給出了兩地三中心架構。其中，最上層是DNS SLB網絡接入層，使用者通過外網DNS通路線上叢集的SLB，DNS引流到活動的主站點。中間是由ECS叢集組成的Web層和應用層，該層在不同地域、不同機房配置設定ECS資源，并完成Web和應用伺服器部署。不同地域的Web和應用伺服器分别挂載到相同地域的SLB執行個體之上。最下面是RDS資料庫層，同一地域RDS采用主備庫模式雙機房部署，資料同步采用RDS主備複制方案，不同地域的RDS之間的資料同步使用阿裡雲資料傳輸産品實作秒級複制。Web和APP伺服器正常情況下隻通路活躍的RDS主庫。
OSS檔案存儲層負責快照檔案、備份檔案等非結構化資料存儲，如ECS作業系統的快照、RDS資料庫的備份檔案等靜态資料，存儲到OSS存儲服務上。不同地域OSS資料容災采用OSS資料遷移服務完成。
當機房發生故障時，會優先切換到本地域的不同機房。當因主幹網絡或其他原因導緻整個地域業務受影響時，會将業務切換到不同地域的機房。
3.3.6 雲資料庫架構最佳實踐
前面幾節分别從應用負載均衡、可擴充性、微服務架構、異步化、高可用等技術層面做了介紹，本節将結合典型應用場景介紹整體技術架構的設計與實作。
1 . 小型OLTP系統
小型OLTP系統是指資料量小（小于500GB）、單表資料量級别（千萬級）、通路量小、操作簡單的系統，這類系統主要用于線上處理業務、簡單實時資料統計和定期的資料報表（統計的資料量小（10w級）、确定性強的查詢）。
針對這類系統，可采用單機RDS+DRDS方案。當遇到資料庫讀壓力過大，可以通過增加RDS隻讀執行個體，采用DRDS将部分讀流量切到隻讀執行個體來解決問題。
這類系統的典型應用場景包括财務、OA辦公類系統。圖3-6給出了小型OLTP的架構。
2 . 中型OLTP系統
中型OLTP系統是指資料量中等規模（大于500GB但小于2TB）、單表資料量級别（千萬以上到1～2億内）、寫通路量較小但讀通路量較大、較複雜的系統，主要用于線上處理業務、實時資料統計和定期的資料報表（統計的資料量小（50w内）、确定性較強的查詢）。
對于這類系統，通常采用DRDS+單節點RDS+隻讀RDS方案，DRDS用于對大表進行分表和自動讀寫分離。
該類系統的典型應用場景包括市級政務平台、網際網路金融平台等。圖3-7給出了中型OLTP系統架構。
3 . 大型OLTP系統
大型OLTP系統是指資料量大（大于2TB）、單表資料量級别（億級以上）、寫通路量超過單機RDS容量、較複雜的系統，主要用于線上處理業務、實時資料統計和定期的資料報表（統計的資料量小（100w内）、确定性較強的查詢）。
大型OLTP系統多采用DRDS+多個RDS執行個體的方案，DRDS進行分庫分表和自動讀寫分離。
大型OLTP系統的典型應用場景包括部委級業務平台、企業總部級應用系統。圖3-8給出了大型OTLP系統架構。
4 . 線上、離線一體化架構
綜合型業務系統中的資料量大（超過RDS執行個體存儲容量2TB）、單表資料量極大（達到億級、十億級甚至百億級），需要處理各種複雜的實時、定時大資料報表需求。
綜合型業務系統通常包括線上交易、準實時大資料分析和離線大資料分析三個部分。其中線上交易部分采用DRDS+多個RDS執行個體的方案，準實時大資料分析部分采用AnalyticDB，離線大資料分析部分采用MaxCompute。綜合型業務系統的典型應用場景包括各類國家級綜合業務平台。圖3-9給出了線上、離線一體化架構。