每秒處理1000萬使用者請求，雲上架構如何實現高效能和高可用

雲上搭建架構不單單需要考慮到效能和可用性，還有安全性、可管理性、彈性等層面都需要注意，實際工作中每一個環節都需要顧及到。

傳統架構與雲上架構設計方法對比，傳統的架構設計週期會比較長，一般的企業架構都會考慮今後3到5年的規劃，解決的主要是有無的問題，是從0到1的架構搭建。雲上的架構設計週期相對來說比較短，需求明確且主要是解決或優化已有的問題。

效能是很難衡量的，狹義上的效能指的是執行速度的快慢，廣義的效能則涉及更多的內容，如功耗、利用率、效能價格比、速度等。不同視角下關注效能的側重點不同，使用者視角下關注的是從請求傳送到獲得響應的整個時間間隔，對使用者來說時間越長效能越差。從架構和開發者視角出發更多是關注響應延時、系統吞吐量以及併發處理能力，而更重要的是明確瞭解使用者反映問題的根源。

搭建高效能架構有4個基本步驟，首先要明確效能的目標，接著分析系統中影響目標實現的所有問題，找到問題後再著手解決這些問題，最後通過效能評估的手段來測試當前效能指標。如果評估結果與效能目標之前存在差異，就說明影響效能的問題還沒有被全部找到，這時需要重新開始進行之前的步驟。

整個過程其實是一個迴圈，即使某一次效能評估達標，但隨著時間的推移業務的發展還是會出現新的效能需要。

效能目標指的是制定的符合高效能的指標，比如頁面響應時間小於1秒，併發使用者可以達到1萬，高峰期每秒處理10000萬使用者請求等。

然後要根據效能目標分析當前業務系統中不同層次有哪些影響效能指標的問題，比如網路層方面的頻寬、延遲，計算層方面的Cpu處理能力、是否採用叢集，以及一些其他方面的影響因素。所以說系統效能高低由整體的處理能力決定，不由單一因素決定。

分析出問題後就開始解決問題，這時可以從兩個方面著手。一方面是最簡便也是大多數人首先會想到的，即提升系統硬體配置，如果硬體資源的升級能夠解決問題，那麼就直接採用這種方式，它最大的好處在於不用對現有的程式碼邏輯做任何的修改。但是大部分的情況下往往無法簡單的通過硬體升級解決所有問題，還需要從架構的層次上入手，降低伺服器壓力，採用可擴充套件架構提高效能。

傳統的測試可以使用LoadRunner之類的工具，雲上則可以使用阿里雲效能測試服務PTS。PTS與傳統的效能測試最大的不同在於LoadRunner需要自己搭建，同時搭建好的測試系統會受限於本身的服務上限，伺服器的數量決定了所能模擬的測試壓力。PTS則可以快速的模擬大量併發請求，因為是雲上所以PTS後端能夠通過叢集的方式模擬使用者需要的併發量。

上圖是我們提出的相對較好的架構方案，前端由負載均衡服務響應使用者請求，在把請求轉發給後端具體的伺服器之前會有一個前端快取，用來提升響應時間以及減輕後端壓力。後端伺服器通過叢集方式響應使用者請求，同時應用之間通過非同步進行互動。訪問資料庫之前先通過快取響應請求，在不能命中的時候再去訪問資料庫。

使用快取時有個問題需要特別注意，即快取與資料庫的資料不一致。針對這一問題解決方式是不同的，要根據不同的需求來選擇。比如有一種方式是在寫資料庫的資料同時更新快取中的資料或者讓快取失效，這樣使用者在讀取的時候，要麼獲取的是最新資料，要麼得從資料庫中重新讀取資料。

上圖是我們某個客戶的雲上架構。前端使用者請求通過CDN服務響應，CDN主要用來做服務加速，對於可以滿足的響應直接使用CDN解決，無法滿足的請求轉發給後端SLB。

從圖中可以看到不同的應用使用的伺服器數量不同，這裡所有的服務都被部署到ECS上，ECS又掛載在SLB後面，另外其中還有OCS資料快取，使用者請求的資料如果無法從快取中獲取到，就從資料庫中讀取。

資料庫的設計同樣也非常複雜，首先它實現了一套讀寫分離，其次有一個DRDS分散式關係型資料庫，能夠掛載多個RDS例項，所有的請求都會傳送給DRDS，而DRDS則相當於中間的路由代理，它會根據請求從不同的RDS中獲取資料。

使用DRDS有幾點需要注意，第一DRDS必須要和RDS結合使用，DRDS本身不儲存資料，資料的儲存都是在RDS上；第二DRDS後的RDS例項必須是Mysql資料庫；第三DRDS有兩種使用方式，一種是表的拆分一種是表的不拆分，如果不拆分DRDS會將表存在某一個RDS例項。

從字面意思上來看高可用其實就是為了減少停工時間，保持服務高度可用性。系統做高可用首先要具備自動偵測、自動切換、和自動恢復的能力。

自動偵測：通過冗餘偵測發現執行的情況，將所彙集的訊息記錄下來，以供維護參考。

自動切換：確認對方故障，則正常主機代替故障主機工作。

自動恢復：故障主機修復後，自動切換回修復完成的主機上。

進行高可用設計時一般建議事先對自身架構做層次化和模組化的改造，按照應用層、基礎設施層進行高可用設計，再按照功能劃分模組，模組之間鬆耦合，且要求穩定可靠易於擴充套件，結構簡單易於維護。

高可用設計包含三種方式，分別是主從方式，主機工作，備機處於監控準備；雙機互備，兩臺主機同時執行各自服務工作且相互監測；叢集工作，多臺主機一起工作，各自執行一個或幾個服務。

- 假定失效設計：假定任何環節都會出問題，然後倒推設計；

- 多可用區設計：盡最大可能避免架構中的單點故障；

- 自動擴充套件設計：不進行設計調整，就能滿足業務量增長；

- 自我修復設計：內建容錯及檢查能力，應用能夠在部分元件失效時自我修復繼續工作；

- 鬆耦合設計：耦合度越小，擴充套件性越好，容錯能力越強

在SLB例項下繫結不同可用區的ECS，從而避免因為單個可用區的故障而導致對外服務的不可用。多可用區的雲資料庫RDS可以實現同城的資料災備，OSS儲存的資料預設會儲存在多個不同可用區中。

如果某臺ECS例項不健康，導致健康中例項數低於最小值，彈性伸縮就會自動建立健康的ECS例項代替不健康的例項。

通過訊息解耦將原應用拆分成獨立的模組，模組間的影響小，就不會因為部分失效導致整體不可用。