高可用架構設計總結：

前言:海恩法則和墨菲定律

海恩法則

· 事故的發生是量的積累的結果。
· 再好的技術、再完美的規章，在實際操作層面也無法取代人自身的素質和責任心。

墨菲定律

· 任何事情都沒有表面看起來那麼簡單。
· 所有事情的發展都會比你預計的時間長。
· 會出錯的事總會出錯。
· 如果你擔心某種情況發生，那麼它更有可能發生。

警示我們，在互聯網公司裏，對生產環境發生的任何怪異現象和問題都不要輕易忽視，對於其背後的原因一定要徹查。同樣，海恩法則也強調任何嚴重事故的背後都是多次小問題的積累，積累到一定的量級後會導致質變，嚴重的問題就會浮出水面。那麼，我們需要對線上服務產生的任何徵兆，哪怕是一個小問題，也要刨根問底: 這就需要我們有技術攻關的能力，對任何現象都要秉着以下原則：爲什麼發生？發生了怎麼應對？怎麼恢復？怎麼避免？對問題要徹查，不能因爲問題的現象不明顯而忽略。

1、可用性度量和考覈

業務可用性：

所謂業務可用性(availability)也即系統正常運行時間的百分比，架構組最主要的 KPI (Key Performance Indicators ，關鍵業績指標)。對於我們提供的服務（web，api）來說，現在業界更傾向用 N 個9 來量化可用性，最常說的就是類似 “4個9(也就是99.99%)” 的可用性。

故障時間=故障修復時間點-故障發現（報告）時間點
服務年度可用時間%=（1-故障時間/年度時間）× 100%。

故障的度量與考覈

對管理者而言：可用性是產品的整體考覈指標。每個工程師而言：使用故障分來考覈：

類別	描述	權重
高危S級事故故障	一旦出現故障，可能會導致服務整體不可用	100
嚴重A級故障	客戶明顯感知服務異常：錯誤的回答	20
中級B級故障	客戶能夠感知服務異常：響應比較慢	5
一般C級故障	服務出現短時間內抖動	1

考覈指標：故障分=故障時間分鐘* 故障級別權重。

服務級別可用性：

如果是一個分佈式架構設計，系統由很多微服務組成，所有的服務可用性不可能都是統一的標準。

爲了提高我們服務可用性，我們需要對服務進行分類管理並明確每個服務級別的可用性要求。

類別	服務	可用性要求	描述
一級核心服務	核心產品或者服務	99.99%（全年53分鐘不可用）	系統引擎部分：一旦出現故障，整個系統癱瘓
二級重要服務	重要的產品功能	99.95%（全年260分鐘不可用）	類比汽車輪子：該服務出現問題，該重要功能不可用。
三級一般服務	一般功能	99.9%（全年8.8小時不可用）	類比汽車倒車影像：該部分出現問題，稍微影響用戶體驗
四級工具服務	工具類是服務	99%	非業務功能：比如爬蟲、管理後臺、運維工具

2、典型架構分層設計

典型架構分層設計如下：按照功能處理順序劃分應用，這是面向業務深度的劃分。

每個公司的架構分層可能不一樣，但是目的都是爲了統一架構術語，方便團隊內部溝通。

接入層：主要流量入口，經過簡單

應用層：直接對外提供產品功能，例如網站、API接口等。接入層不包含複雜的業務邏輯，只做呈現和轉換。

服務層：根據業務領域每個子域單獨一個服務，分而治之。

數據層：數據庫和NoSQL，文件存儲等。

我們先列出目前我們系統有哪些環節,每個環節是否薄弱. 客戶端訪問服務器端，經過很多環節，任何環節出問題，都不能訪問：

接入層：

1、dns被劫持：域名是否使用https。
2、黑客攻擊：是否有弱密，服務器權限，數據庫權限
3、ddos攻擊：是否有必要使用高防IP接入流量。
4、CC攻擊：免費和收費版域名分開，網關是否有限流和防刷措施。

應用層：

1、應用服務器宕機。
2、應用服務bug。
3、第三方服務不可用。

服務層：

1、服務不可用或者出現bug
2、第三方服務不可用。

數據層：

1、數據庫服務器磁盤損壞導致數據庫不可用等

3、接入層高可用設計

在接入層，這裏主要是架構運維的高可用要求的事項：

1、域名規範解析和規範化管理，應該制定《域名規範管理說明》，例如根據產品重要等級，制定使用高防ip的策略。
2、規範API管理。
3、明確各個API限流和防刷策略。

因此我們設計接入層架構：

目前我們對外的接口繁多，同時不同的項目不同的接口，沒有一個統一管理的系統，也不方便監控和
跟蹤 api 的健康狀況。因此搭建我們 api 網關，方便 api 日常管理，包括控版本管理，升級，回滾。同時提供調試工具，方便開發人員， qa 調試和測試。更重要的是 api 網關起到限流防刷（CC攻擊）作用，保護後端服務。

4、應用層高可用設計

應用層設計主要原則：

1、可以水平擴展：通過接入層的負載均衡，實現故障自動轉移。

2、無狀態設計：無狀態的系統更利於水平擴展，更利於做負載均衡。

狀態是系統的吞吐量、易用性、可用性、性能和可擴展性的大敵，要盡最大可能避免。

3、回滾設計：確保系統可以向後兼容，如果應用服務上線後出現bug，可以緊急回滾。

4、灰度發佈：結合接入層設計A/B 功能，實現灰度發佈，比如按ip，請求參數等分發流量。

5、服務層高可用設計

服務層設計最主要原則：服務分級管理

線上有很多服務，每個服務的可用性要求不一樣，我們需要先這些服務做分級。
1、各級服務的部署原則：核心服務：獨立服務器且N+1部署。三級和四級服務可以共享服務器部署。
2、各級服務上線發佈原則：核心和重要服務：晚上12點上線。，三級和四級隨時可上線
3、各級服務監控原則

一級核心服務：

定義：
可用性:99.99%，極高可用性，全年53分鐘不可用。
條件：
1、服務自身可用性：99.99%。
2、依賴數據資源服務可用性要求：（應用服務研發方自定義）。
3、依賴第三方服務可用性要求：（應用服務研發方自定義）。
4、需要部署的服務器數：N臺。

服務設計滿足以下原則：
1、冗餘N+1部署：故障自動轉移到多部署一個節點，避免單點問題。
2、可監控：服務流量預警、端口存活、進程佔用的資源、服務接口功能邏輯是否正常，應用FGC等情況。
3、可回滾、灰度：灰度部署服務，部署的服務出現問題可快速回滾。
4、可獨立部署：可以直接在運維平臺打包部署，而不需要依賴其他服務部署完成後才能部署運行。
5、可獨立測試：可以單獨測試。
6、水平擴展：流量激增可快速擴容。
7、異步設計：服務需要通知第三方服務，必須通過消息隊列進行異步方式完成。
8、冪等設計：服務可以重複調用，不影響結果。
7、可容錯：自身有容錯和修復能力：
      1)、隔離手段：服務使用的資源（CPU、線程、IO等）隔離，使用艙壁模式；
      2)、自我保護手段：快速失敗(failfast)、流控、超時、熔斷；
      3)、失效轉移或恢復手段：失效檢測、重試、轉移(failover)、回退恢復（failback)；
      4)、降級手段：依據依賴服務的重要性或依賴程度（強、弱）,同步變異步，降級開關、拒絕部分服務等。

二級重要服務：

定義：
可用性99.95%（故障具備自動恢復的能力，全年260分鐘不可用）。
條件：
1、服務自身可用性：99.95%。
2、依賴數據資源服務可用性要求：（應用服務研發方自定義）。
3、依賴第三方服務可用性要求：（應用服務研發方自定義）。
4、需要部署的服務器數：N臺。

服務設計滿足以下原則：
1、冗餘N+1部署：故障自動轉移到多部署一個節點，避免單點問題。
2、可監控：監控進程、端口存活、進程佔用的資源，應用FGC等。
3、可回滾、灰度：灰度部署服務，部署的服務出現問題可快速回滾。
4、故障隔離：服務器只部署唯一該應用服務，該應用服務出現問題，隻影響自身服務問題。
5、可獨立部署：可以直接在運維平臺打包部署，而不需要依賴其他服務部署完成後才能部署運行。
6、可獨立測試：可以單獨測試。
7、水平擴展：流量激增可快速擴容。
8、可容錯：自身有容錯和修復能力。

三級一般服務：

定義：
可用性99.9%（較高可用性，全年260分鐘不可用）。
條件：
1、服務自身可用性：99.95%。
2、依賴數據資源服務可用性要求：（應用服務研發方自定義）。
3、依賴第三方服務可用性要求：（應用服務研發方自定義）。
4、需要部署的服務器數：N臺。
服務設計滿足以下原則：
1、冗餘N+1部署：可以單點部署。
2、可監控：可監控服務進程、端口存活是否正常。
3、可回滾、灰度：灰度部署服務，部署的服務出現問題可快速回滾。
4、故障隔離：一個服務器上可以部署多個應用，但保證服務器資源充足。
5、可獨立部署：需要獨立部署。
6、可獨立測試：可以單獨測試。
7、水平擴展：流量激增可快速擴容。
8、可容錯：需要具備一般的容錯能力。

四級工具服務：

定義：
可用性99.9%（全年8.8小時分鐘不可用）。
條件：
1、服務自身可用性：99.9%。
2、依賴數據資源服務可用性要求：（應用服務研發方自定義）。
3、依賴第三方服務可用性要求：（應用服務研發方自定義）。
4、需要部署的服務器數：N臺。

服務設計滿足以下原則：

1、冗餘N+1部署：可以單點部署，只要有個進程存活就可以。
2、可監控：不需要監控。
3、可回滾、灰度：只要部署成功就可以。
4、故障隔離：哪個服務器有資源就可以部署。
5、可獨立部署：不用考慮。
6、可獨立測試：不用考慮。
7、水平擴展：不用考慮。
8、可容錯：不用考慮。

6、高可用的數據庫架構

數據架構設計原則

7、高質量的服務管理

1、規範服務管理：CMDB對項目、服務、服務器進行統一管理。
2、自動化發佈：發佈不影響用戶，完善發佈流程，自動化發佈，可以及時回滾。
3、自動化測試：上線完成後進行全面自動化測試。
4、性能壓測：通過對服務壓測，瞭解服務可以承載併發能力，以致可以讓運維通過預警進行服務器擴容。
5、代碼控制：測試環境使用測試分支，beta環境發佈tag，線上使用該tag發佈。
6、發佈流程：規範上線發佈流程。
7、灰度發佈：灰度發佈服務。
8、應急處理機制。

8、完善的監控告警機制

在高可用服務設計章節提到，核心服務可以監控：服務流量預警、端口存活、進程佔用的資源、服務接口功能邏輯是否正常，應用FGC等情況，需要一個完善監控告警機制，並在告警後，通過一定的策略進行處理，以致服務可以快速恢復。例如，監控FGC，如果在一分鐘內存出現10次FGC，自動重啓服務。

1、網絡流量監控。
2、系統監控：服務器資源和網絡相關監控（CPU、內存等）
3、日誌監控：統一日誌收集（各個服務）監控，跟蹤(log2) 。
4、應用監控：端口存活、進程佔用的資源，應用FGC等情況
5、業務監控：服務接口功能邏輯是否正常
6、立體監控監控數據採集後，除了用作系統性能評估、集羣規模伸縮性預測等，最終目標是還可以根據實時監控數據進行風險預警，並對服務器進行失效轉移，自動負載調整，最大化利用集羣所有機器的資源。

9、容災

1、備份：數據備份（熱備，冷備（冗餘），異地）
2、過載保護：
3、同城多活-》異地多活
4、流量切換
5、重試，防雪崩（概率很小，成本很高）

10、職責

海恩法則提到：再好的技術、再完美的規章，在實際操作層面也無法取代人自身的素質和責任心。

因此要做到高可用的架構設計，職責也要清晰明確，要不然出現問題，相互推諉，問題解決進度很慢，會直接影響業務服務可用性。

1、架構師職責：

1、高可用架構設計：包括業務流程，模塊劃分組合，框架設計，流程紕漏，最後架構設計，技術實現步驟。系統性的思考，權衡利弊，綜合各種因素，設計出具有前瞻性的架構。
2、和運維協調溝通，提出高效的服務治理解決方案，把控服務質量管理。
3、協調溝通：開發之間溝通，產品之間溝通，市場溝通，運維溝通、溝通後產出圖形化文檔及設計。
4、規範和統籌：保證系統秩序，統一，規範，穩定，高效運行。

2、運維職責：

1)、熟悉系統技術架構，和架構師制定各種規範化要求。
2)、和架構師共同協調溝通，對系統架構提出可靠性，伸縮，擴展，數據庫切分，緩存應用等解決方案。
3)、提供監控系統，自動化發佈系統，代碼管理，文檔平臺，自動運維平臺等基礎設施
4)、制定運維規範。
5)、建立運維安全體系。
5)、建立容災備份體系。

3、研發職責：

1)、參與架構師的架構師設計，並根據設計實現具體細節。
2)、針對開發功能進行自測，壓測。
3)、開發代碼，使用工具或組件符合架構師制定規範。包括代碼規範、文檔規範。
4)、代碼部署符合運維部署規範要求。

參考《《大型網站技術架構+核心原理與案例分析》》

架構設計(8)—高可用架構設計