“五一”五天假期可夠長了，閑暇之際，想想寫點東西。我負責的社區和一些平臺項目，對系統的穩定性要求特別高（去年也是出了幾次小的事故），今天總結下近一年的穩定性這塊工作。
宏觀上，從研發的流程上去看穩定性。
穩定性.png
整體思路是這樣，分別就幾個階段談一下痛點和心得。
架構階段
- 異地容災 實現了機房級的容災。目前只做到讀多活，寫還未支持（存儲方案還不成熟）
- 異構降級 對于非常重要的功能，防止空窗，可以考慮異構實現去降級，比如把整個請求kv存起來。對大多數互聯網業務是能滿足基本體驗要求的。
- 異步化結合前端效果對系統的可用性有非常大的提升。首先異步化的前提條件當然是不要求強一致，在涉及金錢等業務可能不適合。舉個例子，發評論依賴內容過濾、依賴主庫，那么異步化后可以滿足延遲寫入但不丟失。前端提交后本地顯示，用戶無感。這里要注意異步消費的冪等設計，另外，出現Error后的重試和補償機制也要注意。
- 隔離性往往容易被忽視，真正當出了大問題才會被引起重視。重要的業務要在資源、部署上做物理隔離
- 避免單點，往往要求service服務做到無狀態，有狀態的要靠中間件（中間件比業務的穩定性要好很多）
編碼階段
- 最最重要的一點是，“對95%的研發同學來說，能不要自己實現的，盡量走統一的框架或者lib”。我們實現了很多通用的lib或者sdk，比如緩存代碼、并發調用、job merge等等。當然這里如果有必要是需要提供新的service服務的。
- 分布式限流 對于網關來說，一般做到按業務去配限流額度。對于資源的限流控制粒度有時候比較繁瑣，比如mysql的訪問，如果要做到sql級限流是比較麻煩的。
- 依賴治理也是個挑戰，Everything fails。這塊一般會非常業務，需要項目研發owner主動去梳理并且理解業務。套用老板的一句話，“別人都炸了你要還能活下來”，這樣的標準去思考、去治理依賴、去容錯。
- 熔斷 熔斷是指下游依賴業務出現系統負載，應對減少訪問流量、慢慢恢復流量，避免雪崩。不然系統很容易被“打”的起不來。
- 超時 之前的文章也提到過，合理的超時配置配合降級，才能不容易出現“木桶短板”
