互聯網架構設計：高可用

作者：Royal Luo

來源：微信公眾號：互聯網架構 InternetArch

大多數情況，在測試自己電腦能否上網時，我們都會用瀏覽器打開百度首頁，如果不能打開百度首頁，那就是我們電腦的網路沒有連通，如果能夠打開百度首頁，那說明我們電腦的網路是連通的。之所以我們會拿百度首頁來測試網路的連通性，是因為百度網站做到了高可用，我們相信只要網路正常就一定能打開百度首頁。

同時，對於百度來說， 每次搜索查詢都可以創造廣告收入，服務不可用就意味著金錢的損失，意味著用戶的流失。同理，服務不可用對於其他網站而言，也是公司的損失。網站的可用性這麼重要，那我們怎麼來衡量網站的可用性呢？有哪些措施可以用來提高網站的可用性？

網站可用性衡量指標

一個高可用網站不能頻頻出現故障，只要發生故障，即使是很短時間的中斷，都會影響業務運營。其次，高可用網站，即使出現故障，也應該能很快恢復。如果一個網站一年不出一次故障，但一次故障需要幾個小時，甚至幾天才能恢復，那麼這個網站也算不上一個高可用網站。

網站可用性(availability)也即網站正常運行時間的百分比，業界用 N 個9 來量化可用性， 最常說的就是類似 「4個9(也就是99.99%)」 的可用性。 百度網站的可用性號稱是5個9，即99.999% 。下表是N個9的具體說明。

描述通俗叫法可用性級別年度停機時間基本可用性2個999%87.6小時較高可用性3個999.9%8.8小時具有故障自動恢復能力的可用性4個999.99%53分鐘極高可用性5個999.999%5分鐘

如何提高網站的可用性？

對於大型網站來說，網站可用性越高越好。互聯網架構的高可用設計可以從以下方面去考慮：

1）基於負載均衡的故障轉移

對於業務邏輯服務，一般會設計成無狀態化的服務，無狀態化也就是服務模塊只處理業務邏輯，而無需關心業務請求的上下文信息。所以無狀態化的伺服器之間是相互平等和獨立的。

故障轉移就是在某一個應用伺服器不能服務用戶請求的時候，通過一定的技術實現用戶請求轉移到其他應用伺服器上來進行業務邏輯處理。

如上圖所示，用戶請求通過負載均衡器分發到具體的應用伺服器上，應用伺服器進行業務邏輯的處理。當應用伺服器1出現故障不能對外提供服務時，負載均衡器可以探測到應用伺服器的狀態，然後將業務請求負載均衡到應用伺服器2和應用伺服器3上去，進而達到應用伺服器故障時，不影響服務的使用。

2）冗餘備份

冗餘備份就是針對某一個服務通過伺服器集群或多機房部署來達到伺服器冗餘和相互備份的目的。

在上一小節中的基於負載均衡器的失效轉移方案，其實也一種冗餘備份容災的方式。同時有三台伺服器組成一個集群來對外提供服務，三台伺服器之間是相互備份的關係，只是三台伺服器是在同一機房。

為了達到更高的可用性，我們還可以考慮通過多機房的冗餘備份，如上圖所示。正常情況下，負載均衡器將請求都分發到機房1的伺服器上去，在機房1處理故障，或者處理性能比較高時，負載均衡器可以將請求切換到機房2上來，從而達到機房之間的容災備份。

冗餘備份可以達到避免單點，系統容量備份，多方式容災等目的。

4）超時設置

一般網站服務都會有主調服務和被調服務之分。超時設置就是主調服務在調用被調服務的時候設置一個超時等待時間Timeout，主調服務發現超時後，主動進入超時處理流程。

例如：主調服務A調用被調服務B時，設置超時等待時間為3秒，可能由於B服務宕機、網路情況不好或程序BUG而導致B服務不能及時回復A服務的調用，此時A服務在等待3秒後，將觸發超時邏輯而不再關心B服務的回復情況。A服務的超時邏輯可以依據情況而定，比如可以採取重試，或到另一個對等的B服務去請求，或直接放棄直接對外進行回包。

超時設置的好處在於當某個服務不可用時，不至於整個系統發生連鎖反應。

5）非同步調用

採用非同步調用的方式調用被調服務，有利於將主調服務和被調服務進行解耦，同時提高系統的處理性能。

例如：當你在微信發布朋友圈時，微信APP的後台伺服器需要把文字和圖片存儲到不同的服務模塊上去，這時後台服務收到請求後，將兩種不同的數據以非同步調用的方式分發到不同的功能模塊，這樣的後台服務處理會更高效，同時即使圖片存儲模塊響應時間長也不會影響到文字存儲過程。

註：簡化朋友圈發表邏輯舉例僅為說明問題，不代表實際的做法。

6）服務分級和降級

在一個大系統中，一般會有核心服務和次要服務之分，那麼對於不同的服務可以採用不同的處理方案，出現故障時應該優先保證核心服務的運行。再者就是針對一個完善的服務，可能需要1-2-3 三步才能完成，但是1-2兩步也可以滿足基本需要，那麼可以將1-2 兩步完成的服務是 1-2-3三步完成的服務的降級。

假如朋友圈發表邏輯，需要將用戶發表的朋友圈中的文字進行存儲（步驟1），同時也需要將圖片進行存儲（步驟2），還需要處理用戶的地理位置（步驟3），三個步驟都成功完成後，用戶的朋友圈就算成功發布。在某些情況下，地理位置服務可能出現故障，那麼朋友圈發表邏輯模塊在成功執行文字和圖片的存儲後，對用戶返回勉強發布成功，雖然用戶看到的信息不夠完整，但是還勉強可用，比發布失敗還是要好一些的。這就是服務降級的過程。

7）監控告警

大型網站系統的服務模塊眾多，經常會因為各種原因出現進程core掉，網路質量不好，機器宕機等現象，我們設計的系統應該具備監控上報和告警的能力，運維和開發能夠通過監控報表實時的查看系統的運行狀態。服務一旦出現問題能夠及時發現，通過自動化處理，或者人工介入處理，從而達到縮短系統的不可用時間，提高可用性。

常見的監控指標有：CPU、帶寬、內存使用率、網路連接狀態，系統調用錯誤，成功率，PV，UV等

8）防雪崩機制

對於設計的任何一個系統，都需要進行容量的預估和最大容量設置，當外部請求量超過最大容量時，應該啟動防雪崩機制，以避免大量外部請求把服務壓跨而不能對外提供服務。

例如A服務的最大QPS是5W/S，那麼當外部請求達到5W/S時，A服務只服務5W/S的QPS，超過的部分直接拒絕服務，而不是強吞下導致A服務完全不可用。

9）流量緩衝機制

在服務內可以建立隊列，當流量過大時，儲存一定的用戶請求到隊列，當流量偏小時再拿出來快速處理，從而達到削峰填谷的作用。在請求資料庫時，這個方案使用得很多，避免寫入高峰時壓跨資料庫。

10）自動化測試

對於每一次代碼的提交，都能通過自動測試程序對整個服務進行整體的回歸測試，這樣可以快速地避免代碼修改引入新的問題，而導致服務不穩定。

11）灰度發布和回滾機制

對於網站系統要發布的服務，可以採用灰度發布的方式來進行發布。所謂灰度發布就是先在生產環境中選取一小部分機器進行發布，然後再測試驗證，驗證成功後再繼續加大發布範圍。如果遇到發布的版本存在重大BUG需要能快速的啟動服務回滾機制，迅速恢復到發布前的穩定版本。

12）代碼控制

對於大型系統來說，一般會有多個團隊或者工程師同時進行開發。需要對相同的代碼庫進行版本管理和發布管理。目前大部分開發團隊都採用SVN和Git等工具來進行代碼管理和發布。

Git是一個開源的分散式版本控制系統，可以有效、高速的處理從很小到非常大的項目版本管理，是目前最流行的代碼管理工具之一。