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

海恩法則

• 事故的發(fā)生是量的積累的結(jié)果。
• 再好的技術(shù)、再完美的規(guī)章 ， 在實(shí)際操作層面也無(wú)法取代人自身的素質(zhì)和責(zé)任心 。

墨菲定律

• 任何事情都沒(méi)有表面看起來(lái)那么簡(jiǎn)單 。
• 所有事情的發(fā)展都會(huì)比你預(yù)計(jì)的時(shí)間長(zhǎng) 。
• 會(huì)出錯(cuò)的事總會(huì)出錯(cuò)。
• 如果你擔(dān)心某種情況發(fā)生，那么它更有可能發(fā)生 。

警示我們，在互聯(lián)網(wǎng)公司里，對(duì)生產(chǎn)環(huán)境發(fā)生的任何怪異現(xiàn)象和問(wèn)題 都不要輕易忽視，對(duì)于其背后的原因一定要徹查。同樣，海恩法則也強(qiáng)調(diào)任何嚴(yán)重事故的背后 都是多次小問(wèn)題的積累，積累到一定的量級(jí)后會(huì)導(dǎo)致質(zhì)變，嚴(yán)重的問(wèn)題就會(huì)浮出水面 。 那么，我們需要對(duì)線上服務(wù)產(chǎn)生的任何征兆，哪怕是一個(gè)小問(wèn)題，也要刨根問(wèn)底: 這就需要我們有技術(shù)攻關(guān)的能力，對(duì)任何現(xiàn)象都要秉著以下原則： 為什么發(fā)生？ 發(fā)生了怎么應(yīng)對(duì)？ 怎么恢復(fù)？ 怎么避免？ 對(duì)問(wèn)題要徹查，不能因?yàn)閱?wèn)題的現(xiàn)象不明顯而忽略 。

一、可用性度量和考核

業(yè)務(wù)可用性：

所謂業(yè)務(wù)可用性(availability)也即系統(tǒng)正常運(yùn)行時(shí)間的百分比，架構(gòu)組最主要的 KPI (Key Performance Indicators ，關(guān)鍵業(yè)績(jī)指標(biāo))。對(duì)于我們提供的服務(wù)（web，api）來(lái)說(shuō)，現(xiàn)在業(yè)界更傾向用 N 個(gè)9 來(lái)量化可用性， 最常說(shuō)的就是類似 “4個(gè)9(也就是99.99%)” 的可用性。

故障時(shí)間=故障修復(fù)時(shí)間點(diǎn)-故障發(fā)現(xiàn)（報(bào)告）時(shí)間點(diǎn)

服務(wù)年度可用時(shí)間%=（1-故障時(shí)間/年度時(shí)間）× 100%。

故障的度量與考核

對(duì)管理者而言：可用性是產(chǎn)品的整體考核指標(biāo)。 每個(gè)工程師而言：使用故障分來(lái)考核：

服務(wù)級(jí)別可用性：

如果是一個(gè)分布式架構(gòu)設(shè)計(jì)，系統(tǒng)由很多微服務(wù)組成，所有的服務(wù)可用性不可能都是統(tǒng)一的標(biāo)準(zhǔn)。

為了提高我們服務(wù)可用性，我們需要對(duì)服務(wù)進(jìn)行分類管理并明確每個(gè)服務(wù)級(jí)別的可用性要求。

二、典型架構(gòu)分層設(shè)計(jì)

典型架構(gòu)分層設(shè)計(jì)如下：按照功能處理順序劃分應(yīng)用，這是面向業(yè)務(wù)深度的劃分。

每個(gè)公司的架構(gòu)分層可能不一樣，但是目的都是為了統(tǒng)一架構(gòu)術(shù)語(yǔ)，方便團(tuán)隊(duì)內(nèi)部溝通。

• 接入層：主要流量入口，經(jīng)過(guò)簡(jiǎn)單
• 應(yīng)用層：直接對(duì)外提供產(chǎn)品功能，例如網(wǎng)站、API接口等。應(yīng)用層不包含復(fù)雜的業(yè)務(wù)邏輯，只做呈現(xiàn)和轉(zhuǎn)換。
• 服務(wù)層：根據(jù)業(yè)務(wù)領(lǐng)域每個(gè)子域單獨(dú)一個(gè)服務(wù)，分而治之。
• 數(shù)據(jù)層：數(shù)據(jù)庫(kù)和NoSQL，文件存儲(chǔ)等。

我們先列出目前我們系統(tǒng)有哪些環(huán)節(jié),每個(gè)環(huán)節(jié)是否薄弱. 客戶端訪問(wèn)服務(wù)器端，經(jīng)過(guò)很多環(huán)節(jié)，任何環(huán)節(jié)出問(wèn)題，都不能訪問(wèn)：

接入層：

1、dns被劫持：域名是否使用https。
2、黑客攻擊：是否有弱密，服務(wù)器權(quán)限，數(shù)據(jù)庫(kù)權(quán)限
3、ddos攻擊：是否有必要使用高防IP接入流量。
4、CC攻擊：免費(fèi)和收費(fèi)版域名分開，網(wǎng)關(guān)是否有限流和防刷措施。

應(yīng)用層：

1、應(yīng)用服務(wù)器宕機(jī)。
2、應(yīng)用服務(wù)bug。
3、第三方服務(wù)不可用。

服務(wù)層：

1、服務(wù)不可用或者出現(xiàn)bug
2、第三方服務(wù)不可用。

數(shù)據(jù)層：

1、數(shù)據(jù)庫(kù)服務(wù)器磁盤損壞導(dǎo)致數(shù)據(jù)庫(kù)不可用等

三、接入層高可用設(shè)計(jì)

在接入層，這里主要是架構(gòu)運(yùn)維的高可用要求的事項(xiàng)：

1、 域名規(guī)范解析和規(guī)范化管理，應(yīng)該制定《域名規(guī)范管理說(shuō)明》，例如根據(jù)產(chǎn)品重要等級(jí)，制定使用高防ip的策略。
2、 規(guī)范API管理。
3、 明確各個(gè)API限流和防刷策略。

因此我們?cè)O(shè)計(jì)接入層架構(gòu)：

目前我們對(duì)外的接口繁多，同時(shí)不同的項(xiàng)目不同的接口，沒(méi)有一個(gè)統(tǒng)一管理的系統(tǒng)，也不方便監(jiān)控和

跟蹤 api 的健康狀況。因此搭建我們 api 網(wǎng)關(guān)，方便 api 日常管理，包括控版本管理，升級(jí)，回滾。同時(shí)提供調(diào)試工具，方便開發(fā)人員， qa 調(diào)試和測(cè)試。 更重要的是 api 網(wǎng)關(guān)起到限流防刷（CC攻擊）作用，保護(hù)后端服務(wù)。

四、應(yīng)用層高可用設(shè)計(jì)

應(yīng)用層設(shè)計(jì)主要原則：

1、可以水平擴(kuò)展：通過(guò)接入層的負(fù)載均衡，實(shí)現(xiàn)故障自動(dòng)轉(zhuǎn)移。
2、無(wú)狀態(tài)設(shè)計(jì)：無(wú)狀態(tài)的系統(tǒng)更利于水平擴(kuò)展，更利于做負(fù)載均衡。
狀態(tài)是系統(tǒng)的吞吐量、易用性、可用性、性能和可擴(kuò)展性的大敵，要盡最大可能避免。
3、回滾設(shè)計(jì)?：確保系統(tǒng)可以向后兼容，如果應(yīng)用服務(wù)上線后出現(xiàn)bug，可以緊急回滾。
4、灰度發(fā)布：結(jié)合接入層設(shè)計(jì)A/B 功能，實(shí)現(xiàn)灰度發(fā)布，比如按ip，請(qǐng)求參數(shù)等分發(fā)流量。

五、服務(wù)層高可用設(shè)計(jì)

服務(wù)層設(shè)計(jì)最主要原則：服務(wù)分級(jí)管理

線上有很多服務(wù)，每個(gè)服務(wù)的可用性要求不一樣，我們需要先這些服務(wù)做分級(jí)。

• 各級(jí)服務(wù)的部署原則：核心服務(wù)：獨(dú)立服務(wù)器且N+1部署。三級(jí)和四級(jí)服務(wù)可以共享服務(wù)器部署。
• 各級(jí)服務(wù)上線發(fā)布原則：核心和重要服務(wù)：晚上12點(diǎn)上線。，三級(jí)和四級(jí)隨時(shí)可上線
• 各級(jí)服務(wù)監(jiān)控原則

1. 一級(jí)核心服務(wù)：

定義：可用性:99.99%，極高可用性，全年53分鐘不可用。

條件：

• 服務(wù)自身可用性：99.99%。
• 依賴數(shù)據(jù)資源服務(wù)可用性要求：（應(yīng)用服務(wù)研發(fā)方自定義）。
• 依賴第三方服務(wù)可用性要求：（應(yīng)用服務(wù)研發(fā)方自定義）。
• 需要部署的服務(wù)器數(shù)：N臺(tái)。

服務(wù)設(shè)計(jì)滿足以下原則：

• 冗余N+1部署：故障自動(dòng)轉(zhuǎn)移到多部署一個(gè)節(jié)點(diǎn)，避免單點(diǎn)問(wèn)題。
• 可監(jiān)控：服務(wù)流量預(yù)警、端口存活、進(jìn)程占用的資源、服務(wù)接口功能邏輯是否正常，應(yīng)用FGC等情況。
• 可回滾、灰度：灰度部署服務(wù)，部署的服務(wù)出現(xiàn)問(wèn)題可快速回滾。
• 可獨(dú)立部署：可以直接在運(yùn)維平臺(tái)打包部署，而不需要依賴其他服務(wù)部署完成后才能部署運(yùn)行。
• 可獨(dú)立測(cè)試：可以單獨(dú)測(cè)試。
• 水平擴(kuò)展：流量激增可快速擴(kuò)容。
• 異步設(shè)計(jì)：服務(wù)需要通知第三方服務(wù)，必須通過(guò)消息隊(duì)列進(jìn)行異步方式完成。
• 冪等設(shè)計(jì)：服務(wù)可以重復(fù)調(diào)用，不影響結(jié)果。
• 可容錯(cuò)：自身有容錯(cuò)和修復(fù)能力：
  • 隔離手段：服務(wù)使用的資源（CPU、線程、IO等）隔離，使用艙壁模式；
  • 自我保護(hù)手段：快速失敗(failfast)、流控、超時(shí)、熔斷；
  • 失效轉(zhuǎn)移或恢復(fù)手段：失效檢測(cè)、重試、轉(zhuǎn)移(failover)、回退恢復(fù)（failback)；
  • 降級(jí)手段：依據(jù)依賴服務(wù)的重要性或依賴程度（強(qiáng)、弱）,同步變異步，降級(jí)開關(guān)、拒絕部分服務(wù)等。

2. 二級(jí)重要服務(wù)：

定義：可用性99.95%（故障具備自動(dòng)恢復(fù)的能力，全年260分鐘不可用）。

條件：

• 服務(wù)自身可用性：99.95%。
• 依賴數(shù)據(jù)資源服務(wù)可用性要求：（應(yīng)用服務(wù)研發(fā)方自定義）。
• 依賴第三方服務(wù)可用性要求：（應(yīng)用服務(wù)研發(fā)方自定義）。
• 需要部署的服務(wù)器數(shù)：N臺(tái)。

服務(wù)設(shè)計(jì)滿足以下原則：

• 冗余N+1部署：故障自動(dòng)轉(zhuǎn)移到多部署一個(gè)節(jié)點(diǎn)，避免單點(diǎn)問(wèn)題。
• 可監(jiān)控：監(jiān)控進(jìn)程、端口存活、進(jìn)程占用的資源，應(yīng)用FGC等。
• 可回滾、灰度：灰度部署服務(wù)，部署的服務(wù)出現(xiàn)問(wèn)題可快速回滾。
• 故障隔離：服務(wù)器只部署唯一該應(yīng)用服務(wù)，該應(yīng)用服務(wù)出現(xiàn)問(wèn)題，只影響自身服務(wù)問(wèn)題。
• 可獨(dú)立部署：可以直接在運(yùn)維平臺(tái)打包部署，而不需要依賴其他服務(wù)部署完成后才能部署運(yùn)行。
• 可獨(dú)立測(cè)試：可以單獨(dú)測(cè)試。
• 水平擴(kuò)展：流量激增可快速擴(kuò)容。
• 可容錯(cuò)：自身有容錯(cuò)和修復(fù)能力。

3. 三級(jí)一般服務(wù)：

定義：可用性99.9%（較高可用性，全年260分鐘不可用）。

條件：

• 服務(wù)自身可用性：99.95%。
• 依賴數(shù)據(jù)資源服務(wù)可用性要求：（應(yīng)用服務(wù)研發(fā)方自定義）。
• 依賴第三方服務(wù)可用性要求：（應(yīng)用服務(wù)研發(fā)方自定義）。
• 需要部署的服務(wù)器數(shù)：N臺(tái)。

服務(wù)設(shè)計(jì)滿足以下原則：

• 冗余N+1部署：可以單點(diǎn)部署。
• 可監(jiān)控：可監(jiān)控服務(wù)進(jìn)程、端口存活是否正常。
• 可回滾、灰度：灰度部署服務(wù)，部署的服務(wù)出現(xiàn)問(wèn)題可快速回滾。
• 故障隔離：一個(gè)服務(wù)器上可以部署多個(gè)應(yīng)用，但保證服務(wù)器資源充足。
• 可獨(dú)立部署：需要獨(dú)立部署。
• 可獨(dú)立測(cè)試：可以單獨(dú)測(cè)試。
• 水平擴(kuò)展：流量激增可快速擴(kuò)容。
• 可容錯(cuò)：需要具備一般的容錯(cuò)能力。

4. 四級(jí)工具服務(wù)：

定義：可用性99.9%（全年8.8小時(shí)分鐘不可用）。

條件：

• 服務(wù)自身可用性：99.9%。
• 依賴數(shù)據(jù)資源服務(wù)可用性要求：（應(yīng)用服務(wù)研發(fā)方自定義）。
• 依賴第三方服務(wù)可用性要求：（應(yīng)用服務(wù)研發(fā)方自定義）。
• 需要部署的服務(wù)器數(shù)：N臺(tái)。

服務(wù)設(shè)計(jì)滿足以下原則：

• 冗余N+1部署：可以單點(diǎn)部署，只要有個(gè)進(jìn)程存活就可以。
• 可監(jiān)控：不需要監(jiān)控。
• 可回滾、灰度：只要部署成功就可以。
• 故障隔離：哪個(gè)服務(wù)器有資源就可以部署。
• 可獨(dú)立部署：不用考慮。
• 可獨(dú)立測(cè)試：不用考慮。?
• 水平擴(kuò)展：不用考慮。
• 可容錯(cuò)：不用考慮。

六、高可用的數(shù)據(jù)庫(kù)架構(gòu)

數(shù)據(jù)架構(gòu)設(shè)計(jì)原則

七、高質(zhì)量的服務(wù)管理

1、規(guī)范服務(wù)管理：CMDB對(duì)項(xiàng)目、服務(wù)、服務(wù)器進(jìn)行統(tǒng)一管理。?
2、自動(dòng)化發(fā)布：發(fā)布不影響用戶，完善發(fā)布流程，自動(dòng)化發(fā)布，可以及時(shí)回滾??。
3、自動(dòng)化測(cè)試： 上線完成后進(jìn)行全面自動(dòng)化測(cè)試。
4、性能壓測(cè)：通過(guò)對(duì)服務(wù)壓測(cè)，了解服務(wù)可以承載并發(fā)能力，以致可以讓運(yùn)維通過(guò)預(yù)警進(jìn)行服務(wù)器擴(kuò)容?。
5、代碼控制：測(cè)試環(huán)境使用測(cè)試分支，beta環(huán)境發(fā)布tag，線上使用該tag發(fā)布。
6、發(fā)布流程：規(guī)范上線發(fā)布流程。
7、灰度發(fā)布：灰度發(fā)布服務(wù)?。
8、應(yīng)急處理機(jī)制?。

八、完善的監(jiān)控告警機(jī)制

在高可用服務(wù)設(shè)計(jì)章節(jié)提到，核心服務(wù)可以監(jiān)控：服務(wù)流量預(yù)警、端口存活、進(jìn)程占用的資源、服務(wù)接口功能邏輯是否正常，應(yīng)用FGC等情況，需要一個(gè)完善監(jiān)控告警機(jī)制，并在告警后，通過(guò)一定的策略進(jìn)行處理，以致服務(wù)可以快速恢復(fù)。例如，監(jiān)控FGC，如果在一分鐘內(nèi)存出現(xiàn)10次FGC，自動(dòng)重啟服務(wù)。

1、網(wǎng)絡(luò)流量監(jiān)控?。
2、系統(tǒng)監(jiān)控：服務(wù)器資源和網(wǎng)絡(luò)相關(guān)監(jiān)控（CPU、內(nèi)存等）?
3、日志監(jiān)控：統(tǒng)一日志收集（各個(gè)服務(wù)）監(jiān)控，跟蹤(log2)?。
4、應(yīng)用監(jiān)控：端口存活、進(jìn)程占用的資源，應(yīng)用FGC等情況
5、業(yè)務(wù)監(jiān)控 ：服務(wù)接口功能邏輯是否正常
6、立體監(jiān)控 監(jiān)控?cái)?shù)據(jù)采集后，除了用作系統(tǒng)性能評(píng)估、集群規(guī)模伸縮性預(yù)測(cè)等， 最終目標(biāo)是還可以根據(jù)實(shí)時(shí)監(jiān)控?cái)?shù)據(jù)進(jìn)行風(fēng)險(xiǎn)預(yù)警，并對(duì)服務(wù)器進(jìn)行失效轉(zhuǎn)移，自動(dòng)負(fù)載調(diào)整，最大化利用集群所有機(jī)器的資源。

九、容災(zāi)

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

十、職責(zé)

海恩法則提到：再好的技術(shù)、再完美的規(guī)章 ， 在實(shí)際操作層面也無(wú)法取代人自身的素質(zhì)和責(zé)任心 。

因此要做到高可用的架構(gòu)設(shè)計(jì)，職責(zé)也要清晰明確，要不然出現(xiàn)問(wèn)題，相互推諉，問(wèn)題解決進(jìn)度很慢，會(huì)直接影響業(yè)務(wù)服務(wù)可用性。

1. 架構(gòu)師職責(zé)：

• 高可用架構(gòu)設(shè)計(jì)：包括業(yè)務(wù)流程，模塊劃分組合，框架設(shè)計(jì)，流程紕漏，最后架構(gòu)設(shè)計(jì)，技術(shù)實(shí)現(xiàn)步驟。 系統(tǒng)性的思考，權(quán)衡利弊，綜合各種因素，設(shè)計(jì)出具有前瞻性的架構(gòu)。
• 和運(yùn)維協(xié)調(diào)溝通，提出高效的服務(wù)治理解決方案，把控服務(wù)質(zhì)量管理。
• 協(xié)調(diào)溝通：開發(fā)之間溝通，產(chǎn)品之間溝通，市場(chǎng)溝通，運(yùn)維溝通、溝通后產(chǎn)出圖形化文檔及設(shè)計(jì)。
• 規(guī)范和統(tǒng)籌：保證系統(tǒng)秩序，統(tǒng)一，規(guī)范，穩(wěn)定，高效運(yùn)行。

2. 運(yùn)維職責(zé)：

• 熟悉系統(tǒng)技術(shù)架構(gòu)，和架構(gòu)師制定各種規(guī)范化要求。- 和架構(gòu)師共同協(xié)調(diào)溝通，對(duì)系統(tǒng)架構(gòu)提出可靠性，伸縮，擴(kuò)展，數(shù)據(jù)庫(kù)切分，緩存應(yīng)用等解決方案。
• 提供監(jiān)控系統(tǒng)，自動(dòng)化發(fā)布系統(tǒng)，代碼管理，文檔平臺(tái)，自動(dòng)運(yùn)維平臺(tái)等基礎(chǔ)設(shè)施
• 制定運(yùn)維規(guī)范。
• 建立運(yùn)維安全體系。
• 建立容災(zāi)備份體系。

3. 研發(fā)職責(zé)：

• 參與架構(gòu)師的架構(gòu)師設(shè)計(jì)，并根據(jù)設(shè)計(jì)實(shí)現(xiàn)具體細(xì)節(jié)。
• 針對(duì)開發(fā)功能進(jìn)行自測(cè)，壓測(cè)。
• 開發(fā)代碼，使用工具或組件符合架構(gòu)師制定規(guī)范。 包括代碼規(guī)范、文檔規(guī)范。
• 代碼部署符合運(yùn)維部署規(guī)范要求。