本文主要依據微服務，從 "防範穩定性風險" 和 "降低故障影響" 兩個方面簡單介紹了穩定性建面臨的常見問題。
1. 防範穩定性風險#
微服務架構讓微服務的功能更加內聚，迭代速度更快，但是增加了服務依賴複雜性，進而增大了穩定性建設難度。儘管其依賴關係複雜，但可抽象為上游服務、自身服務、下游服務三者的關係，穩定性風險防範的主要思路是防範三者的風險。
1.1 防範上游風險#
限流，輸入校驗。
防範上游風險常見的是防範 **"流量增加"和"輸入錯誤"** 風險。預期的流量增加可以提前容量評估並做好相關應對方案；對於非預期的流量增加，依賴提前設置好的限流預案。
限流的目的是自保或隔離影響，核心流量限流後可評估影響後擴容或臨時調整限流閥值。
"輸入錯誤" 常見的是範圍參數沒有限制，比如預期只查詢 1 天的數據，但請求參數傳了查詢 1 個月，因為接口沒有限制，導致數據庫抗不住壓力而 down 機。
1.2 防範下游風險#
解除強依賴，降級、放火驗證弱依賴，切流預案。
業內定義，** 異常發生時，不影響核心業務流程，不影響系統可用性的依賴稱作弱依賴，反之為強依賴。** 解除下游風險最直接的方法就是解除下游強依賴。
- 在系統設計時要全面分析系統的強弱依賴關係，在系統上線後可以通過工具采集線上流量進一步分析依賴關係。
- 需要對歷史業務進行改造，並在功能、體驗和穩定性方面進行取捨。為了保障穩定性，實現最小化強依賴下游的系統，非核心功能在下游依賴故障時進行功能裁剪，確保核心功能一直可用。
弱依賴需要建設降級預案。可以使用 Sentinel 等多種開源流量治理組件。為了保障預案的執行效率，更推薦的做法是業務代碼容錯 + 自動熔斷功能。
降級方式的選擇與業務降級影響相關性較大，一般降級之後影響較大的使用手動降級，而對於降級之後影響較小或後期能快速自動修復的功能可考慮自動降級。
需要經常去驗證強弱依賴治理情況。如果接口、服務等比較簡單，可以使用單測方式進行驗證。如果服務多且複雜的話，需要通過故障演練定期排查。
對於無法解除的強依賴，我們可以考慮一些降低風險的方法，提高穩定性，保障不出大事。
- mysql 可以增加足夠多的分片來降低單個分片掛掉帶來的影響。
- 制定良好的應急預案進行兜底，同時應該提供良好的用戶體驗。
- 單機房故障優先考慮切流止損。
1.3 防範自身風險#
架構風險、容量風險，切流預案，線上變更規範，研發和測試質量保障。
比較基本的是通過冗余佈署、多活切流來規避單點故障；使用彈性雲、自動擴容來減少容量風險。週期性的哨兵壓測、全鏈路壓測、模塊級的壓測進行容量評估。
從經常引發線上事故的原因中，代碼變更和配置變動占極大多數；因此提高研發和測試質量，嚴守線上變更規範是防範自身風險的重點。
提高研發質量，這裡主要是從穩定性角度看，需要研發的同學有寫自動化 case 的意識；雖然短期來看寫 case 會增加研發的時間成本，但是 case 可以大大提高後期迭代的測試效率和代碼質量；對於核心業務系統，不斷迭代是必然的，因此從長遠來看寫 case 的成本應該是可接受的。
2. 降低故障影響#
是人就會犯錯，因此故障是不可避免的。我們除了防範風險外，還需要一些措施來降低故障帶來的影響。
2.1 自身接口降級#
理清核心鏈路的上游依賴，接口能力降級。
作為業務鏈路的一部分，需要明確我們的服務在上游核心鏈路的強弱依賴關係。若上游弱依賴我們的服務，我們需要保障被依賴的接口支持接口能力降級；若上游強依賴我們的服務，則需要考慮推動上游解除對我們服務的強依賴關係，若不能解除的，則需要考慮建設備用的通道或其他能降低上游影響的方案，比如面向用戶的故障引導文案、公告等。
總之，我們不僅需要關注自身服務的穩定性，還需要關注上游對我們服務的依賴關係並建設預案，以此來降低自身服務故障對上游的影響。請注意，這裡的接口能力降級與上文的依賴降級是不同的，此處的接口能力降級是自身服務能力降級，目的是減少對上游服務影響；而上文的依賴降級是熔斷下游降級，目的是減少自身服務受下游故障影響，這是服務處於不同層級時的不同預案。
2.2 故障感知和定位#
監控報警，故障根因定位，應急響應流程。
核心的服務指標、業務指標的監控和報警盡量 100% 覆蓋，覆蓋率是一方面，報警的時效和準確性也是非常關建的。做好鏈路可觀測、日誌可追溯、伺服器性能可視化，都是故障感知和根因定位的有效工具。
建設指標時，可以考慮 metric 指標標準化，其不但能降低理解成本，提高問題定位效率。
在提高核心指標的報警時效和準確性方面，可以考慮從某一個方向重點監控，減少維護的成本，推薦從業務結果指標進行監控（過程指標可用於協助定位問題）。其原因是，業務過程指標多且變更頻繁，還可能跨多個系統，較為分散，而其結果往往是收斂的。