導語 | 本文從研發(fā)規(guī)范層面、應用服務層面、存儲層面、產(chǎn)品層面、運維部署層面、異常應急層面這六大層面去剖析一個高可用架構和系統(tǒng)需要有哪些關鍵的設計和考慮。

10年積累的成都網(wǎng)站設計、成都網(wǎng)站制作經(jīng)驗，可以快速應對客戶對網(wǎng)站的新想法和需求。提供各種問題對應的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡服務。我雖然不認識你，你也不認識我。但先網(wǎng)站制作后付款的網(wǎng)站建設流程，更有尖山免費網(wǎng)站建設讓你可以放心的選擇與我們合作。

一、高可用系統(tǒng)架構設計思想 1-1、可用性和高可用概念

可用性是一個可以量化的指標，計算的公式在維基百科中是這樣描述的：根據(jù)系統(tǒng)損害、無法使用的時間，以及由無法運作恢復到可運作狀況的時間，與系統(tǒng)總運作時間的比較。行業(yè)內(nèi)一般用幾個9表示可用性指標，對應用的可用性程度一般衡量標準有三個9到五個9；一般我們的系統(tǒng)至少要到 4 個 9（99.99%）的可用性才能談得上高可用。

高可用（High Availability）的定義：（From 維基百科）是 IT 術語，指系統(tǒng)無中斷地執(zhí)行其功能的能力，代表系統(tǒng)的可用性程度，是進行系統(tǒng)設計時的準則之一。服務不可能 100% 可用，因此要提高我們的高可用設計，就要盡大可能的去增加我們服務的可用性，提高可用性指標。一句話來表述就是：高可用就是讓我們的服務在任何情況下都盡大可能能夠?qū)ν馓峁┓铡?/p>1-2、高可用系統(tǒng)設計思想

高可用系統(tǒng)的設計，需要有一套比較科學的工程管理套路，要從產(chǎn)品、開發(fā)、運維、基建等全方位去考量和設計，高可用系統(tǒng)的設計思想包括但不限于：

• 做好研發(fā)規(guī)范，系統(tǒng)都是研發(fā)人員設計和編碼寫出來的，因此首先要對研發(fā)層面有一個規(guī)范和標準
• 做好容量規(guī)劃和評估，主要是讓開發(fā)人員對系統(tǒng)要抗住的量級有一個基本認知，方便進行合理的架構設計和演進。
• 做好服務層面的高可用，主要是負載均衡、彈性擴縮容、異步解耦、故障容錯、過載保護等。
• 做好存儲層面的高可用，主要是冗余備份（熱備、冷備）、失效轉(zhuǎn)移（確認，轉(zhuǎn)移，恢復）等。
• 做好運維層面的高可用，主要是發(fā)布測試、監(jiān)控告警、容災、故障演練等。
• 做好產(chǎn)品層面的高可用，主要是兜底策略。
• 做好應急預案，主要是在出現(xiàn)問題后怎么快速恢復，不至于讓我們的異常事態(tài)擴大。

二、研發(fā)規(guī)范層面 方案設計和編碼規(guī)范

研發(fā)規(guī)范層面這個是大家容易忽視的一個點，但是，我們所有的設計，都是研發(fā)人員來完成的，包括從設計文檔到編碼到發(fā)布上線，因此，研發(fā)層面也是有一個規(guī)范流程和套路，來讓我們更好的去研發(fā)和維護一個高可用的系統(tǒng)：

• 設計階段
  • 規(guī)范好相關方案設計文檔的模板和提綱，讓團隊內(nèi)部保持統(tǒng)一，可以參考我的文章《技術方案設計模板》
  • 方案設計后一定要進行評審，在我們團隊中，新項目一定要評審，重構項目一定要評審，大的系統(tǒng)優(yōu)化或者升級一定要評審，其他的一般研發(fā)工作量超過一周的建議要評審的。
• 編碼階段
  • 執(zhí)行代碼規(guī)范
    • 工程的 layout 目錄結構規(guī)范，團隊內(nèi)部保持統(tǒng)一，盡量簡潔
    • 遵循團隊內(nèi)部的代碼規(guī)范，一般公司都有對應語言的規(guī)范，如果沒有則參考官方的規(guī)范，代碼規(guī)范可以大大減少 bug 并且提高可用性。

• • 單測覆蓋率
    • 代碼編寫完需要有一定的單測來保證代碼的健壯性，同時也能保障我們后續(xù)調(diào)整邏輯或者優(yōu)化的時候可以保證代碼的穩(wěn)定
    • 包括增量覆蓋率、全量覆蓋率，具體的覆蓋率要達到多少可以根據(jù)團隊內(nèi)部的實際情況來定，在我們團隊，定的規(guī)則是 50% 的覆蓋率。

• • 日志規(guī)范
    • 不要隨便打日志
    • 要接入遠程日志
    • 要能夠分布式鏈路追蹤
• 發(fā)布上線階段，參考下面運維部署層面那一章節(jié)的灰度發(fā)布和接口測試相關說明

容量規(guī)劃和評估

容量評估，是指我們需要評估好，我們這個系統(tǒng)，是為了應對一個什么體量的業(yè)務，這個業(yè)務請求量的平均值、高峰的峰值大概都在一個什么級別。如果是新系統(tǒng)，那么就需要根據(jù)產(chǎn)品和運營同學對業(yè)務有一個大體的預估，然后開發(fā)同學根據(jù)產(chǎn)品給的數(shù)據(jù)再進行詳細的評估。如果是老系統(tǒng)，那么就可以根據(jù)歷史數(shù)據(jù)來評估。評估的時候，要從一個整體角度來看全局的量級，然后再細化到每個子業(yè)務模塊要承載的量級。

資料領取直通車：大廠面試題錦集+視頻教程

Linux服務器學習網(wǎng)站：C/C++Linux服務器開發(fā)/后臺架構師

容量規(guī)劃，是指我們系統(tǒng)在設計的時候，就要能夠初步規(guī)劃好我們的系統(tǒng)大致能夠抗多少的量級，比如是十萬還是百萬級別的請求量，或者更多。不同的量級對應的系統(tǒng)架構的設計會完全不一樣，尤其到了千萬、億級別的量級的時候，架構的設計會有很多的考量。當然這里需要注意的是，我們不需要一上來就設計出遠超于我們當前業(yè)務真實流量的系統(tǒng)，要根據(jù)業(yè)務實際情況來設計。同時，容量規(guī)劃還涉及到，我們系統(tǒng)上下游的各個模塊、依賴的存儲、依賴的三方服務，分別需要多少資源，需要有一個相對可以量化的數(shù)據(jù)出來。容量規(guī)劃階段，更多是要依靠自身和團隊的經(jīng)驗，比如要了解我們的 log 的性能、redis 的性能、rpc 接口的性能、服務化框架的性能等等，然后根據(jù)各種組件的性能來綜合評估自己設計的系統(tǒng)的整體性能情況。

容量評估和容量規(guī)劃之后，我們還需要做一件事情，就是性能壓測，最好是能夠做到全鏈路壓測。性能壓測的目的是為了確保你的容量規(guī)劃是準確的，比如我設計的這個系統(tǒng)，我規(guī)劃的是能夠抗千萬級別的請求，那么實際上，真的能夠抗住嗎 ？這個在上線之前，首先要根據(jù)經(jīng)驗來判斷，然后是一定要經(jīng)過性能壓測得出準確結論的。性能壓測要關注的指標很多，但是重點要關注是兩個指標，一個是 QPS、一個是響應耗時，要確保壓測的結果符合預期。壓測的步驟可以先分模塊單獨壓測，最后如果情況允許，那么最好執(zhí)行全鏈路壓測。

QPS 預估（漏斗型）

QPS 預估（漏斗型），指的是一個真實的請求過來后，從接入層開始，分別經(jīng)過了我們整個系統(tǒng)的哪些層級、哪些模塊，然后每一個層級的 QPS 的量級分別有多少，從請求鏈路上來看，層級越往下，那么下游層級的量級應該會逐步減少的，因為每經(jīng)過一個層級，都有可能會被各種條件過濾掉的一部分請求。比如說進入活動頁后查看商品詳情然后下單這個例子，首先進入活動頁，所有的請求都會進入訪問；然后只會有部分用戶查詢商品詳情；最后查看商品詳情的這些用戶又只會有部分用戶會下單，因此這里就會有一個漏斗，從上層模塊到下層模塊的量級一定是逐步減少的。

QPS 預估（漏斗型）就是需要我們按照請求的層面和模塊來構建我們的預估漏斗模型，然后預估好每一個層級的量級，包括但不限于從服務、接口、分布式緩存等各個層面來預估，最后構成我們完整的 QPS 漏斗模型。

三、應用服務層面 無狀態(tài)和負載均衡設計

一般要做到系統(tǒng)的高可用，我們的應用服務的常規(guī)設計都是無狀態(tài)的，這也就意味著，我們可以部署多個實例來提高我們系統(tǒng)的可用性，而這多個實例之間的流量分配，就需要依賴我們的負載均衡能力。無狀態(tài) + 負載均衡 既可以讓我們的系統(tǒng)提高并發(fā)能力，也可以提高我們系統(tǒng)的可用性。

如果我們的業(yè)務服務使用的是各種微服務框架來開發(fā)的，那么大概率在這個微服務框架里面就會包含了服務發(fā)現(xiàn)和負載均衡的能力。這是一整套流程，包括服務注冊和發(fā)現(xiàn)、負載均衡、健康狀態(tài)檢查和自動剔除。當我們的任何一個服務實例出現(xiàn)故障后會被自動剔除掉，當我們有新增一個服務實例后會自動添加進來提供服務。

如果我們不是使用的微服務框架來開發(fā)的，那么就需要依賴負載均衡的代理服務，比如 LVS、Nginx 來幫我們實現(xiàn)負載均衡。

彈性擴縮容設計

彈性擴縮容設計是應對突峰流量的非常有效的手段之一，同時也是保障我們服務可用性的必要手段。彈性擴縮容針對的是我們的無狀態(tài)的應用服務而言的，因為服務是無狀態(tài)的，因此可以隨時根據(jù)請求量的大小來進行擴縮容，流量大就擴容來應對大量請求，流量小的時候就縮容減少資源占用。

怎么實現(xiàn)彈性擴縮容呢？現(xiàn)階段都是云原生時代，大部分的公司都是采用容器化（K8s）部署，那么基于這個情況的話，彈性擴縮容就非常容易了，只需要配置好 K8s 的彈性條件就能自動根據(jù) CPU 的使用率來實現(xiàn)。

如果不是容器化部署，是物理機部署的方式，那么要做到彈性擴縮容，必須要有一個公司內(nèi)部的基礎建設能力，能夠在運營平臺上針對服務的 CPU 或者 QPS 進行監(jiān)控，如果超過一定的比例就自動擴縮容，和 K8s 的彈性原理是一樣的，只是需要自行實現(xiàn)。

異步解耦和削峰設計（消息隊列）

要想我們的系統(tǒng)能夠高可用，那么從架構層面來說，要做到分層、分模塊來設計，而分層分模塊之后，那么各個模塊之間，還可以進行異步處理、解耦處理。目的是為了不相互影響，通過異步和解耦可以使我們的架構大大的提升可用性。

架構層面的異步解耦的方式就是采用消息隊列（比如常見的 Kafka），并且同時消息隊列還有削峰的作用，這兩者都可以提高我們的架構可用性：

• 異步解耦：采用消息隊列之后，可以把同步的流程轉(zhuǎn)換為異步的流程，消息生成者和消費者都只需要和消息隊列進行交互，這樣不僅做了異步處理，還講消息生成者和消費者進行了隔離。異步處理的優(yōu)勢在于，不管消息的后續(xù)處理的業(yè)務服務是否 ok，只要消息隊列還沒滿，那么就可以執(zhí)行對外提供服務，而消費方則可以根據(jù)自身處理能力來消費消息后進行處理。解耦的優(yōu)勢在于，如果消費方異常，那么并不影響生產(chǎn)方，依然可以對外提供服務，消息消費者恢復后可以繼續(xù)從消息隊列里面消費數(shù)據(jù)后執(zhí)行業(yè)務邏輯
• 削峰：采用消息隊列之后，還可以做到削峰的作用，當并發(fā)較高的時候，甚至是流量突發(fā)的時候，只要消息生產(chǎn)者能夠?qū)⑾懭氲较㈥犃兄校敲催@個消息就不會丟，后續(xù)處理邏輯可以慢慢的去消息隊列里面消費這些突發(fā)的流量數(shù)據(jù)。這樣就不會因為有突發(fā)流量而把整個系統(tǒng)打垮。

故障和容錯設計

任何服務，一定會存在失敗的情況，不可能有 100% 的可用，服務在線上運行過程中，總會遇到各種各樣意想不到的問題會讓你的服務出現(xiàn)狀況，因此業(yè)界來評價可用性 SLA 都是說多少個 9，比如 4 個 9(99.99%)的可用性。

為此，我們的設計建議遵循"design for failure"的設計原則，設計出一套可容錯的系統(tǒng)，需要做到盡早返回、自動修復，細節(jié)如下

• 遵循 fail fast 原則，F(xiàn)ail fast 原則是說，當我們的主流程的任何一步出現(xiàn)問題的時候，應該快速合理地結束整個流程，盡快返回錯誤，而不是等到出現(xiàn)負面影響才處理。
• 具備自我保護的能力。當我們依賴的其他服務出現(xiàn)問題的時候，要盡快的進行降級、兜底等各種異常保護措施，要避免出現(xiàn)連鎖反應導致整個服務完全不可用。比如當我們依賴的數(shù)據(jù)存儲出現(xiàn)問題，我們不能一直重試從而導致數(shù)據(jù)完全不可用。

過載保護設計（限流、熔斷、降級）

系統(tǒng)無法高可用的一個重要原因就在于，我們的系統(tǒng)經(jīng)常會有突發(fā)的流量過來，導致我們的服務超載運行，這個時候，首先要做的當然是快速擴容，并且我們事先就要預留好一定的冗余。另外一個情況下，就算我們擴容了，但是還是會超載，比如超過了下游依賴的存儲的大容量、或者超過了下游依賴的三方服務的大容量。那么這個時候，我們就需要執(zhí)行我們的過載保護策略了，主要包括限流、熔斷、降級，過載保護是為了保證服務部分可用從而不至于整個服務完全不可用。

• 限流。限流是指對進入系統(tǒng)的請求進行限流處理，如果請求量超過了我們系統(tǒng)大處理能力或者超過了我們指定的處理能力，那么直接拒絕請求，通過這種丟棄部分請求的方式可以保證整個系統(tǒng)有一定的可用性，從而不至于讓整個系統(tǒng)完全不可用。怎么判別超過大處理能力呢？ 一般就是針對 QPS 來判別，如果 QPS 超過閾值，那么就直接拒絕請求。
  • 限流有很多細節(jié)的策略，比如針對接口限流、針對服務限流、針對用戶限流。
• 熔斷。熔斷，斷路（開路）的價值在于限制故障影響范圍。我們希望控制、減少或中斷和故障系統(tǒng)之間的通信，從而降低故障系統(tǒng)的負載，有利于系統(tǒng)的恢復。一般我們的服務都會有很多下游依賴，如果下游依賴的服務出現(xiàn)問題，比如開始超時甚至響應非常慢的情況下，如果我們不做任何處理，那么會導致我們的整個請求都被卡住從而超時，那么我們的業(yè)務服務對外就無法提供任何正常的功能了。為此，熔斷策略就可以解決這個問題，熔斷就是當我們依賴的下游服務出現(xiàn)問題的時候，可以快速對其進行熔斷（不發(fā)起請求），這樣我們的業(yè)務服務至少可以提供部分功能。熔斷的設計至少需要包括 熔斷請求判斷機制算法、熔斷恢復、熔斷告警 三部分
• 降級。降級是指我們劃分好系統(tǒng)的核心功能和非核心功能，然后當我們的系統(tǒng)超過大處理能力之后，直接關閉掉非核心的功能，從而包裝核心功能的可用。關閉掉非核心的功能后可以使我們的系統(tǒng)釋放部分資源，從而可以有資源來處理核心功能。
  • 熔斷和降級這兩個策略，看著比較像，字面的意思上來看都是要快速拒絕掉請求。但是他們是兩個維度的設計，降級的目的是應對系統(tǒng)自身的故障，而熔斷的目的是應對我們系統(tǒng)依賴的外部服務故障的情況。

四、存儲層面

在當前的互聯(lián)網(wǎng)時代，應用服務基本都是無狀態(tài)的，因此應用服務的高可用相對會比較簡單，但是對于數(shù)據(jù)存儲的高可用，相對來說，會復雜很多，因為數(shù)據(jù)是有狀態(tài)的，那具體我們要怎么保障數(shù)據(jù)存儲的高可用，我們來分析下。

存儲層面的高可用方案的本質(zhì)都是通過通過數(shù)據(jù)冗余的方式來實現(xiàn)高可用，將數(shù)據(jù)復制到多個存儲介質(zhì)里面，可以有效的避免數(shù)據(jù)丟失，同時還可以提高并發(fā)能力，因為數(shù)據(jù)是有狀態(tài)的，因此，這里會比服務的高可用要復雜很多，主要體現(xiàn)在如下幾個方面

• 數(shù)據(jù)如何復制？
• 各個節(jié)點的職責是什么？
• 如何應對復制延遲？
• 如何應對復制中斷？

常見的解決存儲高可用的方案有兩種：集群存儲和分布式存儲。業(yè)界大多是圍繞這些來構建，或者是做相關衍生和擴展。

集群存儲（集中式存儲）

集群就是邏輯上處理同一任務的機器集合，可以屬于同一機房，也可分屬不同的機房。集群存儲，就是把多臺機器上的存儲數(shù)據(jù)組合在一起對外形成一套統(tǒng)一的系統(tǒng)。集群存儲適合業(yè)務存儲量規(guī)模一般的場景，常規(guī)的業(yè)務數(shù)據(jù)存儲一般都是集群存儲方式就足夠了?，F(xiàn)在我們一般對于業(yè)務數(shù)據(jù)存儲的使用，默認都是集群方式，比如 Redis、MySQL 等存儲類型，一般中大型互聯(lián)網(wǎng)公司，默認肯定都是集群存儲的方式。

集群存儲就是我們常說的 1 主多備或者 1 主多從的架構，寫數(shù)據(jù)通過主機，讀數(shù)據(jù)一般通過從機。集群存儲主要需要考慮如下幾個問題：

• 主機如何將數(shù)據(jù)復制給備機（從機）
  • 數(shù)據(jù)的寫入都是通過主機，因此數(shù)據(jù)同步到備機（從機），就是要通過主機進行數(shù)據(jù)復制到備機（從機）。
  • 還需要考慮主備同步的時間延遲問題。
• 備機（從機）如何檢測主機狀態(tài)
• 主機故障后，備機（從機）怎么切換為主機
  • 主從架構中，如果主機故障，可直接將備機（從機）切換為主機

1，主備復制

主備復制是最常見也是最簡單的一種存儲高可用方案，幾乎所有的存儲系統(tǒng)都提供了主備復制的功能，例如 MySQL、Redis、MongoDB 等。

主備架構中的“備機”主要還是起到一個備份作用，并不承擔實際的業(yè)務讀寫操作，如果要把備機改為主機，需要人工操作。因此一般使用場景都是在一些內(nèi)部的后臺管理系統(tǒng)中使用。

2，主從復制

主從復制和主備復制雖然只有一字之差，但是兩者是不一樣的設計思路，“從”意思是“隨從、仆從”，“備”的意思是備份?！睆摹?的機制是要干活的，因此是承擔數(shù)據(jù)的“讀”操作的，一般就是主機負責讀寫操作，從機只負責讀操作，不負責寫操作。

3，主從切換

主備復制和主從復制方案存在兩個共性的問題：

• 主機故障后，無法進行寫操作。
• 如果主機無法恢復，需要人工指定新的主機角色。

主從切換（主備切換）就是為了解決這兩個問題而產(chǎn)生的，具體的設計就是在原有方案的基礎上增加“自動切換”的能力，當主機異常后，經(jīng)過系統(tǒng)檢測并且自動將備機或者從機切換為主機。這個是實際應用中比較多的一個方案之一，因為我們一定能夠有機制保證主機異常后從機能夠自動切換為主機。

4，主主復制

主主復制指的是兩臺機器都是主機，互相將數(shù)據(jù)復制給對方，客戶端可以任意挑選其中一臺機器進行讀寫操作，如果采取主主復制架構，必須保證數(shù)據(jù)能夠雙向復制。這個相對來說，要求較高。

分布式存儲

集群指的是將幾臺服務器集中在一起，實現(xiàn)同一業(yè)務。而分布式是指將不同的業(yè)務分布在不同的地方，分布式中的每一個節(jié)點，都可以做集群。

分布式存儲就是通過網(wǎng)絡使用企業(yè)中的每臺機器上的磁盤空間，并將這些分散的存儲資源構成一個虛擬的存儲設備，數(shù)據(jù)分散的存儲在企業(yè)的各個角落。分布式存儲中的每臺服務器都可以處理讀寫請求，因此不存在集中式存儲中負責寫的主機那樣的角色。但在分布式存儲中，必須有一個角色來負責執(zhí)行數(shù)據(jù)分配算法，這個角色可以是獨立的一臺服務器，也可以是集群自己選舉出的一臺服務器。分布式存儲適合非常大規(guī)模的數(shù)據(jù)存儲，業(yè)務數(shù)據(jù)量巨大的場景可以采用這種方式。常見的分布式存儲比如 Hadoop(HDFS)、HBase、Elasticsearch 等。

五、產(chǎn)品層面

產(chǎn)品層面的高可用架構解決方案，基本上就是指我們的兜底產(chǎn)品策略。降級/限流的策略，更多的是從后端的業(yè)務服務和架構上的設計來考慮相關解決方案。這里說的兜底策略，也可叫做柔性降級策略，更多則是通過產(chǎn)品層面上來考慮。

• 比如，當我們的頁面獲取不到數(shù)據(jù)的時候，或者無法訪問的時候，要如何友好的告知用戶，比如【稍后重試】之類的。
• 比如 當我們的真實的頁面無法訪問的時候，那么需要產(chǎn)品提供一個默認頁面，如果后端無法獲取真實數(shù)據(jù)，那么直接渲染默認頁面。
• 比如服務器需要停機維護，那么產(chǎn)品層面給一個停機頁面，所有用戶只會彈出這個停機頁面，不會請求后端服務
• 比如抽獎商品給一個默認兜底商品
• ...

六、運維部署層面 開發(fā)階段-灰度發(fā)布、接口測試設計

灰度發(fā)布、接口測試、接口撥測系列設計包括但不限于：

• 灰度發(fā)布，我們服務發(fā)布上線的時候，要有一個灰度的過程，先灰度 1-2 個服務實例，然后逐步放量觀察，如果一切 ok，再逐步灰度，直到所有實例發(fā)布完畢
• 接口測試，每次服務發(fā)布上線的時候，服務提供的各種接口，都要有接口測試用例，接口測試用例跑過之后，服務才能發(fā)布上線，目的是為了查看我們對外提供的接口是否能夠正常，避免服務發(fā)布上線后才發(fā)現(xiàn)有問題

灰度發(fā)布和接口測試，一般在大公司里面會有相關的 DevOps 流程來保證。

開發(fā)階段-監(jiān)控告警設計

監(jiān)控告警的設計，在大公司來說，根本不是問題，因為一定會有比較專門一撥人去做這種基礎能力的建設，會有對應的配套系統(tǒng)，業(yè)務開發(fā)的同學只需要配置或使用即可。那如果說公司內(nèi)部沒有相關基礎建設，那么就需要自己分別來接入對應的系統(tǒng)了。

監(jiān)控系統(tǒng)

一般在監(jiān)控系統(tǒng)這方面的開源解決方案包括但不限于這些：

• ELK (Elasticsearch、Logstash、Kibana) 日志收集和分析
  • 我們的日志記錄不能都本地存儲，因為微服務化后，日志散落在很多機器上，因此必須要有一個遠程日志記錄的系統(tǒng)，ELK 是不二人選

• Prometheus 監(jiān)控收集
  • 可以監(jiān)控各種系統(tǒng)層面的指標，包括自定義的一些業(yè)務指標

• OpenTracing 分布式全鏈路追蹤
  • 一個請求的上下游這么多服務，怎么能夠把一個請求的上下游全部串起來，那么就要依靠 OpenTracing，可以把一個請求下的所有鏈路都串起來并且有詳細的記錄

• OpenTelemetry 可觀測系統(tǒng)標準
  • 最新的標準，大一統(tǒng)，集合了跟蹤數(shù)據(jù)（Traces），指標數(shù)據(jù)（Metrics），日志數(shù)據(jù)（Logs）來觀測分布式系統(tǒng)狀態(tài)的能力

我們會依托開源系統(tǒng)進行自建或者擴展，甚至直接使用都行，然后我們的監(jiān)控的指標一般會包括：

• 基礎設施層的監(jiān)控：主要是針對網(wǎng)絡、交換機、路由器等低層基礎設備，這些設備如果出現(xiàn)問題，那么依托其運行的業(yè)務服務肯定就無法穩(wěn)定的提供服務，我們常見的核心監(jiān)控指標包括網(wǎng)絡流量(入和出)、網(wǎng)絡丟包情況、網(wǎng)絡連接數(shù)等。
• 操作系統(tǒng)層的監(jiān)控：這里需要包含物理機和容器。常見的核心指標監(jiān)控包括 CPU 使用率、內(nèi)存占用率、磁盤 IO 和網(wǎng)絡帶寬等。
• 應用服務層的監(jiān)控：這里的指標會比較多，核心的比如主調(diào)請求量、被調(diào)請求量、接口成功率、接口失敗率、響應時間（平均值、P99、P95 等）等。
• 業(yè)務內(nèi)部的自定義監(jiān)控：每個業(yè)務服務自己的一些自定義的監(jiān)控指標。比如電商系統(tǒng)這里的：瀏覽、支付、發(fā)貨等各種情況的業(yè)務指標
• 端用戶層的監(jiān)控：前面的監(jiān)控更多的都是內(nèi)部系統(tǒng)層面的，但是用戶真正訪問到頁面，中間還有外網(wǎng)的情況，用戶真正獲取到數(shù)據(jù)的耗時、打開頁面的耗時等這些信息也是非常重要的，但是這個一般就是需要客戶端或者前端去進行統(tǒng)計了。

告警系統(tǒng)

這些系統(tǒng)接入完了之后，還只是做到監(jiān)控和統(tǒng)計，當出現(xiàn)問題的時候，還需要進行實時告警，因此還要有一個實時告警系統(tǒng)，如果沒有實時報警，系統(tǒng)運行異常后我們就無法快速感知，這樣就無法快速處理，就會給我們的業(yè)務帶來重大故障和災難。告警設計需要包括：

• 實時性：實現(xiàn)秒級監(jiān)控；
• 全面性：覆蓋所有系統(tǒng)業(yè)務；
• 實用性：預警分為多個級別，監(jiān)控人員可以方便實用地根據(jù)預警嚴重程度做出精確的決策；
• 多樣性：預警方式提供推拉模式，包括短信，郵件，可視化界面，方便監(jiān)控人員及時發(fā)現(xiàn)問題

開發(fā)階段-安全性、防攻擊設計

安全性、防攻擊設計的目的是為了防刷、防黑產(chǎn)、防黑客，避免被外部惡意攻擊，這個一般有幾個策略：

• 在公司級別的流量入口做好統(tǒng)一的防刷和鑒權的能力，比如再統(tǒng)一接入層做好封裝
• 在業(yè)務服務內(nèi)部，做好相關的業(yè)務鑒權，比如登錄態(tài)信息、比如增加業(yè)務鑒權的邏輯

部署階段-多機房部署（容災設計）

一般的高可用策略，都是針對一個機房內(nèi)來服務層面來設計的，但是如果整個機房都不可用了，比如地震、火災、光纖挖斷等。。。。那么這個情況怎么辦？這就需要我們的服務和存儲都能夠進行容災了，容災的一個常見方案就是多機房部署了。

• 服務的多機房部署，這個比較容易，因為我們的服務都是無狀態(tài)的，因此只要名字服務能夠發(fā)現(xiàn)不同機房的服務，就可以實現(xiàn)調(diào)用，這里需要注意的是名字服務（或者說負載均衡服務）要能夠有就近訪問的能力。
• 存儲的多機房部署，這個會比較難搞一點，因為存儲是有狀態(tài)的，部署在不同的機房就涉及到存儲的同步和復制問題。

條件不允許的情況下，我們保證多機房部署業(yè)務服務就可以了。

線上運行階段-故障演練（混沌實驗）

故障演練在大公司是一個常見的手段；在業(yè)界，Netflix 早在 2010 年就構建了混沌實驗工具 Chaos Monkey，混沌實驗工程對于提升復雜分布式系統(tǒng)的健壯性和可靠性發(fā)揮了重要作用。

簡單的故障演練就是模擬機房斷電、斷網(wǎng)、服務掛掉等場景，然后看我們的整個系統(tǒng)運行是否正常。系統(tǒng)的就要參考混沌實驗工程來進行詳細的規(guī)劃和設計，這個是一個相對比較大的工程，效果挺好，但是需要有大量人力去開發(fā)這種基礎建設。

線上運行階段-接口撥測系列設計

接口撥測，和巡檢類似，就是服務上線后，每隔一個固定時間（比如 5s）調(diào)用后端的各種接口，如果接口異常則進行告警

針對接口撥測，一般也會有相關配套設施來提供相關的能力去實現(xiàn)，如果沒有提供，那么我們可以自己寫一個接口撥測（巡檢）的服務，定期去調(diào)用重要的接口。

七、異常應急層面

前面做了這么多保障，但是終究架不住線上的各種異常情況，如果真出問題了，讓我們的服務異常，無法提供服務后，我們還需要最后一根救命稻草，那就是應急預案，將服務異常的損失降低到最小。

應急預案就是我們需要事先規(guī)劃好，我們業(yè)務系統(tǒng)在各個層級出現(xiàn)問題后，我們需要第一時間怎么恢復，制定好相關規(guī)則和流程，當出現(xiàn)異常狀況后可以按照既有的流程去執(zhí)行，這樣避免出現(xiàn)問題后手忙腳亂導致事態(tài)擴大。

你是否還在尋找穩(wěn)定的海外服務器提供商？創(chuàng)新互聯(lián)www.cdcxhl.cn海外機房具備T級流量清洗系統(tǒng)配攻擊溯源，準確流量調(diào)度確保服務器高可用性，企業(yè)級服務器適合批量采購，新人活動首月15元起，快前往官網(wǎng)查看詳情吧

文章標題：高可用架構和系統(tǒng)設計經(jīng)驗-創(chuàng)新互聯(lián)
網(wǎng)站URL：http://weahome.cn/article/ecjsc.html