一、前言
高并發、高可用、高性能被稱為網際網路三高架構，這三者都是工程師和架構師在系統架構設計中必須考慮的因素之一。今天我們就來聊一聊三H中的高可用，也是我們常說的系統穩定性。
\> 本篇文章隻聊思路，沒有太多的深入細節。閱讀全文大概需要5~10分鐘。
二、高可用的定義
業界常用 N 個 9 來量化一個系統可用性程度，可以直接映射到網站正常運作時間的百分比上。
可用性的計算公式：
大部分公司的要求是4個9，也就是年度當機時長不能超過53分鐘，實際要達到這個目标還是非常困難的，需要各個子子產品互相配合。
要想提升一個系統的可用性，首先需要知道影響系統穩定性的因素有哪些。
三、影響穩定性的因素
首先我們先梳理一下影響系統穩定性的一些常見的問題場景，大緻可分為三類：
- 人為因素 不合理的變更、外部攻擊等等
- 軟體因素 代碼bug、設計漏洞、GC問題、線程池異常、上下遊異常
- 硬體因素 網絡故障、機器故障等
下面就是對症下藥，首先是故障前的預防，其次是故障後的快速恢複能力，下面我們就聊聊幾種常見的解決思路。
四、提升穩定性的幾種思路
4.1 系統拆分
拆分不是以減少不可用時間為目的，而是以減少故障影響面為目的。因為一個大的系統拆分成了幾個小的獨立子產品，一個子產品出了問題不會影響到其他的子產品，進而降低故障的影響面。系統拆分又包括接入層拆分、服務拆分、資料庫拆分。
- 接入層&服務層 一般是按照業務子產品、重要程度、變更頻次等次元拆分。
- 資料層 一般先按照業務拆分後，如果有需要還可以做垂直拆分也就是資料分片、讀寫分離、資料冷熱分離等。
::: hljs-center
4.2 解耦
:::
系統進行拆分之後，會分成多個子產品。子產品之間的依賴有強弱之分。如果是強依賴的，那麼如果依賴方出問題了，也會受到牽連出問題。這時可以梳理整個流程的調用關系，做成弱依賴調用。弱依賴調用可以用MQ的方式來實作解耦。即使下遊出現問題，也不會影響目前子產品。
4.3 技術選型
可以在适用性、優缺點、産品口碑、社群活躍度、實戰案例、擴充性等多個方面進行全量評估，挑選出适合目前業務場景的中間件&資料庫。前期的調研一定要充分，先對比、測試、研究，再決定，磨刀不誤砍柴工。
4.4 備援部署&故障自動轉移
服務層的備援部署很好了解，一個服務部署多個節點，有了備援之後還不夠，每次出現故障需要人工介入恢複勢必會增加系統的不可服務時間。是以，又往往是通過“自動故障轉移”來實作系統的高可用。即某個節點當機後需要能自動摘除上遊流量，這些能力基本上都可以通過負載均衡的探活機制來實作。
涉及到資料層就比較複雜了，但是一般都有成熟的方案可以做參考。一般分為一主一從、一主多從、多主多從。不過大緻的原理都是資料同步實作多從，資料分片實作多主，故障轉移時都是通過選舉算法選出新的主節點後在對外提供服務（這裡如果寫入的時候不做強一緻同步，故障轉移時會丢失一部分資料）。具體可以參考Redis Cluster、ZK、Kafka等叢集架構。
4.5 容量評估
在系統上線前需要對整個服務用到的機器、DB、cache都要做容量評估，機器容量的容量可以采用以下方式評估：
- 明确預期流量名額-QPS；
- 明确可接受的時延和安全水位名額（比如CPU%≤40%，核心鍊路RT≤50ms）；
- 通過壓測評估單機在安全水位以下能支援的最高QPS（建議通過混合場景來驗證，比如按照預估流量配比同時壓測多個核心接口）；
- 最後就可以估算出具體的機器數量了。
DB和cache評估除了QPS之外還需要評估資料量，方法大緻相同，等到系統上線後就可以根據監控名額做擴縮容了。
4.6 服務快速擴容能力&洩洪能力
現階段不論是容器還是ECS，單純的節點複制擴容是很容易的，擴容的重點需要評估的是服務本身是不是無狀态的，比如：
- 下遊DB的連接配接數最多支援目前服務擴容幾台？
- 擴容後緩存是否需要預熱？
- 放量政策
這些因素都是需要提前做好準備，整理出完備的SOP文檔，當然最好的方式是進行演練，實際上手操作，有備無患。
洩洪能力一般是指備援部署的情況下，選擇幾個節點作為備用節點，平時承擔很小一部分流量，當流量洪峰來臨時，通過調整流量路由政策把熱節點的一部分流量轉移到備用節點上。
對比擴容方案這種成本相對較高，但是好處就是響應快，風險小。
4.7 流量整形&熔斷降級
流量整形也就是常說的限流，主要是防止超過預期外的流量把服務打垮，熔斷則是為了自身元件或者依賴下遊故障時，可以快速失敗防止長期阻塞導緻雪崩。關于限流熔斷的能力，開源元件Sentinel基本上都具備了，用起來也很簡單友善，但是有一些點需要注意。
- 限流門檻值一般是配置為服務的某個資源能支撐的最高水位，這個需要通過壓測摸底來評估。随着系統的疊代，這個值可能是需要持續調整的。如果配置的過高，會導緻系統崩潰時還沒觸發保護，配置的過低會導緻誤傷。
- 熔斷降級-某個接口或者某個資源熔斷後，要根據業務場景跟熔斷資源的重要程度來評估應該抛出異常還是傳回一個兜底結果。比如下單場景如果扣減庫存接口發生熔斷，由于扣減庫存在下單接口是必要條件，是以熔斷後隻能抛出異常讓整個鍊路失敗復原，如果是擷取商品評論相關的接口發生熔斷，那麼可以選擇傳回一個空，不影響整個鍊路。
4.8資源隔離
如果一個服務的多個下遊同時出現阻塞，單個下遊接口一直達不到熔斷标準（比如異常比例跟慢請求比例沒達到門檻值），那麼将會導緻整個服務的吞吐量下降和更多的線程數占用，極端情況下甚至導緻線程池耗盡。引入資源隔離後，可以限制單個下遊接口可使用的最大線程資源，確定在未熔斷前盡可能小的影響整個服務的吞吐量。
說到隔離機制，這裡可以擴充說一下，由于每個接口的流量跟RT都不一樣，很難去設定一個比較合理的可用最大線程數，并且随着業務疊代，這個門檻值也難以維護。這裡可以采用共享加獨占來解決這個問題，每個接口有自己的獨占線程資源，當獨占資源占滿後，使用共享資源，共享池在達到一定水位後，強制使用獨占資源，排隊等待。這種機制優點比較明顯就是可以在資源利用最大化的同時保證隔離性。
這裡的線程數隻是資源的一種，資源也可以是連接配接數、記憶體等等。
4.9系統性保護
系統性保護是一種無差别限流，一句話概念就是在系統快要崩潰之前對所有流量入口進行無差别限流，當系統恢複到健康水位後停止限流。具體一點就是結合應用的 Load、總體平均 RT、入口 QPS 和線程數等幾個次元的監控名額，讓系統的入口流量和系統的負載達到一個平衡，讓系統盡可能跑在最大吞吐量的同時保證系統整體的穩定性。
4.10 可觀測性&告警
當系統出現故障時，我們首先需找到故障的原因，然後才是解決問題，最後讓系統恢複。排障的速度很大程度上決定了整個故障恢複的時長，而可觀測性的最大價值在于快速排障。其次基于Metrics、Traces、Logs三大支柱配置告警規則，可以提前發現系統可能存在的風險&問題，避免故障的發生。
4.11 變更流程三闆斧
變更是可用性最大的敵人，99%的故障都是來自于變更，可能是配置變更，代碼變更，機器變更等等。那麼如何減少變更帶來的故障呢？
- 可灰階 用小比例的一部分流量來驗證變更後的内容，減小影響使用者群。
- 可復原 出現問題後，能有有效的復原機制。涉及到資料修改的，釋出後會引起髒資料的寫入，需要有可靠的復原流程，保證髒資料的清除。
- 可觀測 通過觀察變更前後的名額變化，很大程度上可以提前發現問題。
除了以上三闆斧外，還應該在其他開發流程上做規範，比如代碼控制，內建編譯、自動化測試、靜态代碼掃描等。
五、總結
對于一個動态演進的系統而言，我們沒有辦法将故障發生的機率降為0，能做的隻有盡可能的預防和縮短故障時的恢複時間。當然我們也不用一味的追求可用性，畢竟提升穩定性的同時，維護成本、機器成本等也會跟着上漲，是以需要結合系統的業務SLO要求，适合的才是最好的。
如何做好穩定性和高可用保障是一個很龐大的命題，本篇文章沒有太多的深入細節，隻聊了整體的一些思路，主要是為了大家在以後的系統高可用建設過程中，有一套系統的架構可以參考。最後感謝耐心看完的同學。
文/新一
線下活動推薦：
時間： 2023年6月10日（周六） 14:00-18:00主題： 得物技術沙龍總第18期-無線技術第4期地點： 杭州·西湖區學院路77号得物杭州研發中心12樓教育訓練教室（地鐵10号線&19号線文三路站G口出）
活動亮點： 本次無線沙龍聚焦于最新的技術趨勢和實踐，将在杭州/線上為你帶來四個令人期待的演講話題，包括：《抖音創作工具-iOS功耗監控與優化》、《得物隐私合規平台建設實踐》、《網易雲音樂-用戶端大流量活動的日常化保障方案實踐》、《得物Android編譯優化》。相信這些話題将對你的工作和學習有所幫助，我們期待着與你共同探讨這些令人興奮的技術内容！
點選報名： 無線沙龍報名
本文屬得物技術原創，來源于：得物技術官網
未經得物技術許可嚴禁轉載，否則依法追究法律責任！