工作十年，談談我的高可用架構和系統設計經驗

　　本文從研發規範層面、應用服務層面、儲存層面、產品層面、運維部署層面、異常應急層面這六大層面去剖析一個高可用的系統需要有哪些關鍵的設計和考慮。　　

　 　一、高可用架構和系統設計思想

　　1.可用性和高可用概念

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

　　高可用（High Availability）的定義：（From 維基百科）是 IT 術語，指系統無中斷地執行其功能的能力，代表系統的可用性程度，是進行系統設計時的準則之一。

　　服務不可能 100% 可用，因此要提高我們的高可用設計，就要盡最大可能去增加我們服務的可用性，提高可用性指標。一句話來表述就是：高可用就是讓我們的服務在任何情況下都盡最大可能能夠對外提供服務。

　　2.高可用系統設計思想

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

　　做好研發規範，系統都是研發人員設計和編碼寫出來的，因此首先要對研發層面有一個規範和標準

　　做好容量規劃和評估，主要是讓開發人員對系統要扛住的量級有一個基本認知，方便進行合理的架構設計和演進。

　　做好服務層面的高可用，主要是負載均衡、彈性擴縮容、非同步解耦、故障容錯、過載保護等。

　　做好儲存層面的高可用，主要是冗餘備份（熱備、冷備）、失效轉移（確認，轉移，恢復）等。

　　做好運維層面的高可用，主要是釋出測試、監控告警、容災、故障演練等。

　　做好產品層面的高可用，主要是兜底策略。

　　做好應急預案，主要是在出現問題後怎麼快速恢復，不至於讓我們的異常事態擴大。

　　 二、研發規範層面

　　1.方案設計和編碼規範

　　研發規範層面這個是大家容易忽視的一個點，但是，我們所有的設計，都是研發人員來完成的，包括從設計文件到編碼到釋出上線，因此，研發層面也是有一個規範流程和套路，來讓我們更好的去研發和維護一個高可用的系統：

　　1）設計階段

　　規範好相關方案設計文件的模板和提綱，讓團隊內部保持統一，可以參考我的文章《技術方案設計模板》。

　　方案設計後一定要進行評審，在我們團隊中，新專案一定要評審，重構專案一定要評審，大的系統最佳化或者升級一定要評審，其他的一般研發工作量超過一週的建議要評審的。

　　2）編碼階段

　　不要隨便打日誌；

　　要接入遠端日誌；

　　要能夠分散式鏈路追蹤；

　　程式碼編寫完需要有一定的單測來保證程式碼的健壯性，同時也能保障我們後續調整邏輯或者最佳化的時候可以保證程式碼的穩定；

　　包括增量覆蓋率、全量覆蓋率，具體的覆蓋率要達到多少可以根據團隊內部的實際情況來定，在我們團隊，定的規則是 50% 的覆蓋率；

　　工程的 layout 目錄結構規範，團隊內部保持統一，儘量簡潔；

　　遵循團隊內部的程式碼規範，一般公司都有對應語言的規範，如果沒有則參考官方的規範，程式碼規範可以大大減少 bug 並且提高可用性；

　　執行程式碼規範；

　　單測覆蓋率；

　　日誌規範。

　　3）釋出上線階段，參考下面運維部署層面那一章節的灰度釋出和介面測試相關說明

　　2.容量規劃和評估

　　容量評估，是指我們需要評估好，我們這個系統，是為了應對一個什麼體量的業務，這個業務請求量的平均值、高峰的峰值大概都在一個什麼級別。如果是新系統，那麼就需要根據產品和運營同學對業務有一個大體的預估，然後開發同學根據產品給的資料再進行詳細的評估。如果是老系統，那麼就可以根據歷史資料來評估。評估的時候，要從一個整體角度來看全域性的量級，然後再細化到每個子業務模組要承載的量級。

　　容量規劃，是指我們系統在設計的時候，就要能夠初步規劃好我們的系統大致能夠抗多少的量級，比如是十萬還是百萬級別的請求量，或者更多。不同的量級對應的系統架構的設計會完全不一樣，尤其到了千萬、億級別的量級的時候，架構的設計會有很多的考量。當然這裡需要注意的是，我們不需要一上來就設計出遠超於我們當前業務真實流量的系統，要根據業務實際情況來設計。

　　同時，容量規劃還涉及到，我們系統上下游的各個模組、依賴的儲存、依賴的三方服務，分別需要多少資源，需要有一個相對可以量化的資料出來。容量規劃階段，更多是要依靠自身和團隊的經驗，比如要了解我們的 log 的效能、redis 的效能、rpc 介面的效能、服務化框架的效能等等，然後根據各種元件的效能來綜合評估自己設計的系統的整體效能情況。

　　容量評估和容量規劃之後，我們還需要做一件事情，就是效能壓測，最好是能夠做到全鏈路壓測。效能壓測的目的是為了確保你的容量規劃是準確的，比如我設計的這個系統，我規劃的是能夠抗千萬級別的請求，那麼實際上，真的能夠抗住嗎 ？這個在上線之前，首先要根據經驗來判斷，然後是一定要經過效能壓測得出準確結論的。

　　效能壓測要關注的指標很多，但是重點要關注是兩個指標，一個是 QPS、一個是響應耗時，要確保壓測的結果符合預期。壓測的步驟可以先分模組單獨壓測，最後如果情況允許，那麼最好執行全鏈路壓測。

　　3.QPS 預估（漏斗型）

　　QPS 預估（漏斗型），指的是一個真實的請求過來後，從接入層開始，分別經過了我們整個系統的哪些層級、哪些模組，然後每一個層級的 QPS 的量級分別有多少，從請求鏈路上來看，層級越往下，那麼下游層級的量級應該會逐步減少的，因為每經過一個層級，都有可能會被各種條件過濾掉的一部分請求。

　　比如說進入活動頁後檢視商品詳情然後下單這個例子，首先進入活動頁，所有的請求都會進入訪問；然後只會有部分使用者查詢商品詳情；最後檢視商品詳情的這些使用者又只會有部分使用者會下單，因此這裡就會有一個漏斗，從上層模組到下層模組的量級一定是逐步減少的。

　　QPS 預估（漏斗型）就是需要我們按照請求的層面和模組來構建我們的預估漏斗模型，然後預估好每一個層級的量級，包括但不限於從服務、介面、分散式快取等各個層面來預估，最後構成我們完整的 QPS 漏斗模型。

　　 三、應用服務層面

　　1.無狀態和負載均衡設計

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

　　如果我們的業務服務使用的是各種微服務框架來開發的，那麼大機率在這個微服務框架裡面就會包含了服務發現和負載均衡的能力。這是一整套流程，包括服務註冊和發現、負載均衡、健康狀態檢查和自動剔除。當我們的任何一個服務例項出現故障後會被自動剔除掉，當我們有新增一個服務例項後會自動新增進來提供服務。

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

　　2.彈性擴縮容設計

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

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

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

　　3.非同步解耦和削峰設計（訊息佇列）

　　要想我們的系統能夠高可用，那麼從架構層面來說，要做到分層、分模組來設計，而分層分模組之後，那麼各個模組之間，還可以進行非同步處理、解耦處理。目的是為了不相互影響，透過非同步和解耦可以使我們的架構大大提升可用性。

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

　　非同步解耦：採用訊息佇列之後，可以把同步的流程轉換為非同步的流程，訊息生成者和消費者都只需要和訊息佇列進行互動，這樣不僅做了非同步處理，還將訊息生成者和消費者進行了隔離。

　　非同步處理的優勢在於，不管訊息的後續處理的業務服務是否 ok，只要訊息佇列還沒滿，那麼就可以執行對外提供服務，而消費方則可以根據自身處理能力來消費訊息後進行處理。

　　解耦的優勢在於，如果消費方異常，那麼並不影響生產方，依然可以對外提供服務，訊息消費者恢復後可以繼續從訊息佇列裡面消費資料後執行業務邏輯

　　削峰：採用訊息佇列之後，還可以做到削峰的作用，當併發較高的時候，甚至是流量突發的時候，只要訊息生產者能夠將訊息寫入到訊息佇列中，那麼這個訊息就不會丟，後續處理邏輯可以慢慢的去訊息佇列裡面消費這些突發的流量資料。這樣就不會因為有突發流量而把整個系統打垮。

　　4.故障和容錯設計

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

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

　　遵循 fail fast 原則。Fail fast 原則是說，當我們的主流程的任何一步出現問題的時候，應該快速合理地結束整個流程，儘快返回錯誤，而不是等到出現負面影響才處理。

　　具備自我保護的能力。當我們依賴的其他服務出現問題的時候，要儘快的進行降級、兜底等各種異常保護措施，要避免出現連鎖反應導致整個服務完全不可用。比如當我們依賴的資料儲存出現問題，我們不能一直重試從而導致資料完全不可用。

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

　　系統無法高可用的一個重要原因就在於，我們的系統經常會有突發的流量過來，導致我們的服務超載執行，這個時候，首先要做的當然是快速擴容，並且我們事先就要預留好一定的冗餘。

　　另外一個情況下，就算我們擴容了，但是還是會超載，比如超過了下游依賴的儲存的最大容量、或者超過了下游依賴的三方服務的最大容量。那麼這個時候，我們就需要執行我們的過載保護策略了，主要包括限流、熔斷、降級，過載保護是為了保證服務部分可用從而不至於整個服務完全不可用。

　　1）限流

　　限流是指對進入系統的請求進行限流處理，如果請求量超過了我們系統最大處理能力或者超過了我們指定的處理能力，那麼直接拒絕請求，透過這種丟棄部分請求的方式可以保證整個系統有一定的可用性，從而不至於讓整個系統完全不可用。怎麼判別超過最大處理能力呢？一般就是針對 QPS 來判別，如果 QPS 超過閾值，那麼就直接拒絕請求。

　　限流有很多細節的策略，比如針對介面限流、針對服務限流、針對使用者限流。

　　2）熔斷

　　熔斷，斷路（開路）的價值在於限制故障影響範圍。我們希望控制、減少或中斷和故障系統之間的通訊，從而降低故障系統的負載，有利於系統的恢復。一般我們的服務都會有很多下游依賴，如果下游依賴的服務出現問題，比如開始超時甚至響應非常慢的情況下，如果我們不做任何處理，那麼會導致我們的整個請求都被卡住從而超時，那麼我們的業務服務對外就無法提供任何正常的功能了。

　　為此，熔斷策略就可以解決這個問題，熔斷就是當我們依賴的下游服務出現問題的時候，可以快速對其進行熔斷（不發起請求），這樣我們的業務服務至少可以提供部分功能。熔斷的設計至少需要包括 熔斷請求判斷機制演算法、熔斷恢復、熔斷告警 三部分。

　　3）降級

　　降級是指我們劃分好系統的核心功能和非核心功能，然後當我們的系統超過最大處理能力之後，直接關閉掉非核心的功能，從而保障核心功能的可用。關閉掉非核心的功能後可以使我們的系統釋放部分資源，從而可以有資源來處理核心功能。

　　熔斷和降級這兩個策略，看著比較像，字面的意思上來看都是要快速拒絕掉請求。但是他們是兩個維度的設計，降級的目的是應對系統自身的故障，而熔斷的目的是應對我們系統依賴的外部服務故障的情況。

　　 四、儲存層面

　　在當前的網際網路時代，應用服務基本都是無狀態的，因此應用服務的高可用相對會比較簡單，但是對於資料儲存的高可用，相對來說，會複雜很多，因為資料是有狀態的，那具體我們要怎麼保障資料儲存的高可用，我們來分析下。

　　儲存層面的高可用方案的本質都是透過透過資料冗餘的方式來實現高可用，將資料複製到多個儲存介質裡面，可以有效的避免資料丟失，同時還可以提高併發能力，因為資料是有狀態的，因此，這裡會比服務的高可用要複雜很多，主要體現在如下幾個方面：

　　資料如何複製？

　　各個節點的職責是什麼？

　　如何應對複製延遲？

　　如何應對複製中斷？

　　常見的解決儲存高可用的方案有兩種：叢集儲存和分散式儲存。業界大多是圍繞這些來構建，或者是做相關衍生和擴充套件。

　　1.叢集儲存（集中式儲存）

　　叢集就是邏輯上處理同一任務的機器集合，可以屬於同一機房，也可分屬不同的機房。叢集儲存，就是把多臺機器上的儲存資料組合在一起對外形成一套統一的系統。叢集儲存適合業務儲存量規模一般的場景，常規的業務資料儲存一般都是叢集儲存方式就足夠了。現在我們一般對於業務資料儲存的使用，預設都是叢集方式，比如 Redis、MySQL 等儲存型別，一般中大型網際網路公司，預設肯定都是叢集儲存的方式。

　　叢集儲存就是我們常說的 1 主多備或者 1 主多從的架構，寫資料透過主機，讀資料一般透過從機。叢集儲存主要需要考慮如下幾個問題：

　　1）主機如何將資料複製給備機（從機）

　　資料的寫入都是透過主機，因此資料同步到備機（從機），就是要透過主機進行資料複製到備機（從機）。

　　還需要考慮主備同步的時間延遲問題。

　　2）備機（從機）如何檢測主機狀態

　　3）主機故障後，備機（從機）怎麼切換為主機

　　主從架構中，如果主機故障，可直接將備機（從機）切換為主機。

　　①主備複製

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

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

　　②主從複製

　　主從複製和主備複製雖然只有一字之差，但是兩者是不一樣的設計思路，“從”意思是“隨從、僕從”，“備”的意思是備份。”從“ 的機制是要幹活的，因此是承擔資料的“讀”操作的，一般就是主機負責讀寫操作，從機只負責讀操作，不負責寫操作。

　　③主從切換

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

　　主機故障後，無法進行寫操作。

　　如果主機無法恢復，需要人工指定新的主機角色。

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

　　④主主複製

　　主主複製指的是兩臺機器都是主機，互相將資料複製給對方，客戶端可以任意挑選其中一臺機器進行讀寫操作，如果採取主主複製架構，必須保證資料能夠雙向複製。這個相對來說，要求較高。

　　2.分散式儲存

　　叢集指的是將幾臺伺服器集中在一起，實現同一業務。而分散式是指將不同的業務分佈在不同的地方，分散式中的每一個節點，都可以做叢集。

　　分散式儲存就是透過網路使用企業中的每臺機器上的磁碟空間，並將這些分散的儲存資源構成一個虛擬的儲存裝置，資料分散的儲存在企業的各個角落。

　　分散式儲存中的每臺伺服器都可以處理讀寫請求，因此不存在集中式儲存中負責寫的主機那樣的角色。但在分散式儲存中，必須有一個角色來負責執行資料分配演算法，這個角色可以是獨立的一臺伺服器，也可以是叢集自己選舉出的一臺伺服器。

　　分散式儲存適合非常大規模的資料儲存，業務資料量巨大的場景可以採用這種方式。常見的分散式儲存比如 Hadoop(HDFS)、HBase、Elasticsearch 等。

　　 五、產品層面

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

　　比如，當我們的頁面獲取不到資料的時候，或者無法訪問的時候，要如何友好地告知使用者，比如【稍後重試】之類的。

　　比如，當我們的真實的頁面無法訪問的時候，那麼需要產品提供一個預設頁面，如果後端無法獲真實資料，那麼直接渲染預設頁面。

　　比如伺服器需要停機維護，那麼產品層面給一個停機頁面，所有使用者只會彈出這個停機頁面，不會請求後端服務。

　　比如抽獎商品給一個預設兜底商品。

　　...

　　 六、運維部署層面

　　1.開發階段-灰度釋出、介面測試設計

　　灰度釋出、介面測試、介面撥測系列設計包括但不限於：

　　灰度釋出，我們服務釋出上線的時候，要有一個灰度的過程，先灰度 1-2 個服務例項，然後逐步放量觀察，如果一切 ok，再逐步灰度，直到所有例項釋出完畢。

　　介面測試，每次服務釋出上線的時候，服務提供的各種介面，都要有介面測試用例，介面測試用例跑過之後，服務才能釋出上線，目的是為了檢視我們對外提供的介面是否能夠正常，避免服務釋出上線後才發現有問題。

　　灰度釋出和介面測試，一般在大公司裡面會有相關的 DevOps 流程來保證。

　　2.開發階段-監控告警設計

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

　　1）監控系統

　　一般在監控系統這方面的開源解決方案包括但不限於這些：

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

　　Prometheus 監控收集：可以監控各種系統層面的指標，包括自定義的一些業務指標。

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

　　OpenTelemetry 可觀測系統標準：最新的標準，大一統，集合了跟蹤資料（Traces），指標資料（Metrics），日誌資料（Logs）來觀測分散式系統狀態的能力。

　　我們會依託開源系統進行自建或者擴充套件，甚至直接使用都行，然後我們的監控的指標一般會包括：

　　基礎設施層的監控：主要是針對網路、交換機、路由器等低層基礎裝置，這些裝置如果出現問題，那麼依託其執行的業務服務肯定就無法穩定的提供服務，我們常見的核心監控指標包括網路流量(入和出)、網路丟包情況、網路連線數等。

　　作業系統層的監控：這裡需要包含物理機和容器。常見的核心指標監控包括 CPU 使用率、記憶體佔用率、磁碟 IO 和網路頻寬等。

　　應用服務層的監控：這裡的指標會比較多，核心的比如主調請求量、被調請求量、介面成功率、介面失敗率、響應時間（平均值、P99、P95 等）等。

　　業務內部的自定義監控：每個業務服務自己的一些自定義的監控指標。比如電商系統這裡的：瀏覽、支付、發貨等各種情況的業務指標。

　　端使用者層的監控：前面的監控更多的都是內部系統層面的，但是使用者真正訪問到頁面，中間還有外網的情況，使用者真正獲取到資料的耗時、開啟頁面的耗時等這些資訊也是非常重要的，但是這個一般就是需要客戶端或者前端去進行統計了。

　　2）告警系統

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

　　實時性：實現秒級監控；

　　全面性：覆蓋所有系統業務；

　　實用性：預警分為多個級別，監控人員可以方便實用地根據預警嚴重程度做出精確的決策；

　　多樣性：預警方式提供推拉模式，包括簡訊，郵件，視覺化介面，方便監控人員及時發現問題。

　　3.開發階段-安全性、防攻擊設計

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

　　在公司級別的流量入口做好統一的防刷和鑑權的能力，比如再統一接入層做好封裝；

　　在業務服務內部，做好相關的業務鑑權，比如登入態資訊、比如增加業務鑑權的邏輯。

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

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

　　服務的多機房部署，這個比較容易，因為我們的服務都是無狀態的，因此只要名字服務能夠發現不同機房的服務，就可以實現呼叫，這裡需要注意的是名字服務（或者說負載均衡服務）要能夠有就近訪問的能力。

　　儲存的多機房部署，這個會比較難搞一點，因為儲存是有狀態的，部署在不同的機房就涉及到儲存的同步和複製問題。

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

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

　　故障演練在大公司是一個常見的手段；在業界，Netflix 早在 2010 年就構建了混沌實驗工具 Chaos Monkey，混沌實驗工程對於提升複雜分散式系統的健壯性和可靠性發揮了重要作用。

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

　　6.線上執行階段-介面撥測系列設計

　　介面撥測，和巡檢類似，就是服務上線後，每隔一個固定時間（比如 5s）呼叫後端的各種介面，如果介面異常則進行告警

　　針對介面撥測，一般也會有相關配套設施來提供相關的能力去實現，如果沒有提供，那麼我們可以自己寫一個介面撥測（巡檢）的服務，定期去呼叫重要的介面。

　　 七、異常應急層面

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

　　應急預案就是我們需要事先規劃好，我們業務系統在各個層級出現問題後，我們需要第一時間怎麼恢復，制定好相關規則和流程。當出現異常狀況後可以按照既有的流程去執行，這樣避免出現問題後手忙腳亂導致事態擴大。