何謂系統穩定性?

控制系統理論認為：系統受到某種干擾而偏離正常狀態，當干擾消除，如果系統的擾動能逐漸收斂并最終恢復正常狀態，則系統是穩定的，反之，系統偏離越來越大，則是不穩定的，所以，穩定性是系統抗干擾和返回平衡狀態的能力。

對于經典的傳遞函數的軟件系統，一般我們講的穩定指的是BIBO穩定，即有界輸入有界輸出穩定。一個系統如果對任意有界輸入得到有界輸出，它就是BIBO穩定的。一句話，穩定的系統對于各種輸入需要有符合預期的輸出。

隨著軟件復雜性越來越高，穩定性的保障越來越難，隨著服務規模越來越大，穩定性的重要性越來越高。阿里行癲把穩定性比喻成木桶的底板，如果穩定性出問題，則滴水不留，所以，工程師在設計和開發軟件的時候，要堅持底板思維。

但我們的軟件需求和計劃很少考慮非功能部分，然而軟件的結構和實現卻有非常大的比重服務于此，這也許是軟件項目計劃經常延期的重要原因。

如何保障穩定性?

雖然理論上沒有絕對穩定的系統，但我們依然可以有所作為，使我們設計和開發的系統在生產環境接近穩定運行。

從大的方面講，穩定性保障，可以分成3個部分：

制度紀律

編碼規范、代碼提交門禁

Code Review

靜態代碼掃描，動態代碼分析

Unit Test、壓測

灰度發布、Rollback、應急預案

監控

復盤、故障樹分析

思想之道

保持簡單、降低復雜度

不(零)信任、面向失敗設計

實踐之術

冗余設計(數據、計算、帶寬冗余)

快速恢復設計(無狀態設計)

容錯、災備

熔斷、隔離

限流

有損服務

錯誤重試策略，避免流量風暴

去關鍵路徑、去中心化、避免單點故障

負載均衡(load balance)

避免驚群效應

看門狗設計

安全編碼

制度紀律

通過制度去規范操作和行為，通過紀律去約束大家在框架內活動，被證明是保障穩定減少出錯行之有效的方式。

紀律是關鍵，只有持之以恒的遵守制度，才能避免方法和規定淪為空談。

但制度和紀律只是劃出質量底線，只能解決大多數穩定性問題，難以發現一些隱匿的問題，需要配合思想之道和實踐之術，才能持續改進軟件質量，從而更全面的保障穩定性。

思想之道

道是大的層面，它具有全局性的指導意義，我從眾多的指導思想里，挑選最重要的兩點：保持簡單和不信任/面向失敗設計，展開來講。

1. 保持簡單

復雜是穩定性的天敵，保持簡單即保持穩定。單一職責，功能清晰就是踐行保持簡單。

把簡單的東西搞復雜很容易，而化繁為簡則堪稱化腐朽為神奇。所以保持簡單并不是低要求，它需要你透過表象洞悉事物本質，用最直接最土味的方式解決問題，做技術的同學有一個奇怪的癖好，喜歡把自己最近琢磨的東西用到項目中，不然總有錦衣夜行的感覺。

我的建議是“學深用淺”。引入復雜性，一方面要權衡收益，另一方面要警惕損傷，要理解項目開發很多時候是團隊合作，任何復雜性的引入都會對合作者提出更高要求，嚴以律人是危險的，低門檻才是符合人性的。

2. 不信任設計、面向失敗設計

不信任設計又叫零信任設計，和面向失敗的設計有相似之處，其本質都是防御性編程思想。

不信任設計思想假設系統依賴的上下游都不可靠，假設周圍都是壞人，假設攻擊無處不在。

網絡服務需要對客戶端請求參數做嚴格驗證，不僅檢查合法性，也要驗證NaN。游戲開發有一句名言：假設客戶端的數據都是假的。

進程內的函數調用大多時候很安全，會有可預期的結果，但如果跨進程調用(RPC)的可靠性則會低很多，有可能超時，有可能丟包，有可能失敗，調用者必須意識并處理好各種異常情況，是重試?如果重試的話重試多少次?重試之間的間隔應該怎么確定?請求的上下文怎么保存和恢復?

我們要正確理解不信任設計的內涵，避免用力過猛，警惕借面向失敗設計之名行無效編程之實，比如已經對客戶端請求數據做了嚴格校驗，在服務器處理過程中，重復檢驗，比如已經對接口入參判空，在內部調用過程中重復判斷。這會降低代碼濃度，混入大量無效代碼，損傷可讀性和執行效率，本質上是違背“保持簡單”原則的。

實踐之術

術是局部層面，它是實踐經驗，牽扯方方面面，難以盡數枚舉。

如果以文章寫作類比軟件開發，謀篇布局相當于設計層面，設計層面要致廣遠，遣詞造句相當于實現層面，實現層面要盡精微。

所謂千里之堤潰于蟻穴，防微杜漸尤其重要。

1. 冗余設計

冗余設計指留出安全余量，冗余包括數據冗余、計算冗余、帶寬冗余。

數據冗余指一份數據多個副本，一主多備。

計算冗余，比如服務實例的QPS極限是10K，但實際上我們會按5K跑，這樣，即使出現流量超速增長，我們依然有反應時間。

2. 快速恢復設計(無狀態設計)

互聯網服務很多都是無狀態設計，服務實例只是邏輯的盒子，后面跟著分布式一致性數據庫，這樣能極大簡化設計，即使實例掛了，客戶可以很容易遷移到其他服務實例執行，而有狀態設計則要復雜難搞得多。

3. 容錯、災備

容錯指我們的系統要有一定的錯誤容忍能力，這意味錯誤發生，我們要能查錯、檢錯、避錯、甚至改錯，只要可能，我們就要吞咽錯誤。

災備這個大家耳熟能詳，主從設計，異地備災，目標都是為了應對各種極限情況。

4. 熔斷、隔離

熔斷機制不止軟件設計獨有，股市也有，我甚至懷疑軟件的熔斷機制是從股市學來的。

隔離本質上就是說如果故障發生了，如果故障發生，而又不能吞咽，那也應該隔離避免錯誤傳播擴散，千方百計縮小影響范圍，相當于感染新冠要被隔離起來。容器化等技術為隔離提供良好能力支撐。

5. 限流

系統設計要做好資源耗盡、資源不夠用的情況，如果服務請求超過服務能力，那就應該限流，這應該作為一種配置，或者自動執行的策略。

這個跟地鐵限流差不多，處理不了，那就排隊。

6. 有損服務

有損服務我印象中最先是騰訊提出來的，指如果出現服務能力不夠，不能為所有客戶提供服務的異常情況，那系統應該確保已有客戶的服務請求得到滿足，而不能讓新增客戶拉已有客戶一起死。

有損的意義就是有損失，有損傷的意思，已有客戶不受干擾，新增客戶淪為代價，這不也是沒辦法的辦法嘛。

7. 錯誤重試策略，避免流量風暴

如果設計一個ToC服務，在客戶大規模斷連的情況下，客戶會重連，重連失敗再連，如果重連嘗試的頻率不控制好，正常客戶端重連有可能演變成對服務器的大規模攻擊，打爆一臺服務器，又去滅另一臺，這太嚇人了。

可以參考kernel TCP的重連策略，有最大嘗試次數，而且重試間隔是逐漸拉大的。

8. 去關鍵路徑、去中心化、避免單點故障

企業不要關鍵先生，關鍵先生會成為瓶頸，軟件也不能把寶壓到一個地方，去中心化去集中式，沒什么難理解的。

9. 負載均衡

load balance其實就是分擔壓力，LB要避免傾斜，有多種LB算法，比如RR，比如一致性hash，各有利弊，有興趣可以研究下。

LB不僅限于服務，進程內的多線程可能也會需要考慮這個問題。

10. 避免驚群效應

一只鳥被驚擾起飛，然后一群鳥全部受驚起飛，畫面感是不是很強?有點破窗效應的味道，可以參考nginx對驚群效應的處理策略。

11. 看門狗和心跳機制

可以參考kernel的watch dog，其實就是看護機制，檢測錯誤并努力掰過來。

12. 安全編碼

安全編碼是一個職業程序員的基本要求，安全編碼規則很多，很細節的一些規矩。這個可能跟語言相關，如果是C++相關的可以參考：C++的門門道道

C相關的規則要少一些，我順手列舉一些。

比如要注意初始化。 比如全局變量不要有構造順序的依賴。 比如慎用強轉，強轉等于接管了編譯幫你做的類型檢查。 比如理解線程安全函數，理解可重入的概念，理解信號機制。 比如要避免死鎖，理解ABBA鎖理解自死鎖。 比如要謹防資源泄漏。 比如處理好內存分配失敗的情況，理解野/懸垂指針。 比如要處理好邊界，防止越界，溢出。 比如內存拷貝要避免內存重疊，理解memmove的用途。 比如理解遞歸的低效和棧的大小限制，避免爆棧。 比如建議使用STD安全版本函數(_s+n)版本。 比如了解unsigned < 0導致死循環的情況。 比如了解浮點數跟0比較的問題。 比如理解整型數據溢出和反轉。 比如不要返回臨時變量的引用或者指針，理解棧幀動態伸縮的原理。 比如理解做好把關檢查的必要性，包括系統把關和模塊把關。

小結

最后來讀段經典：《系統化思維導論》一書中引用馮諾依曼的話寫道：如果你觀察一些自動裝置，不論它們是人類設計的還是自然界本來就存在的，你通常會發現，它們的結構很大程度上受控于它們可能失效的方式，以及針對失效所采取的防御性措施(多少有些效果)，說它們能預防失效有點夸張，它們不是能預防失效的，只是被設計成試圖達到這種狀態，這樣至少大部分失效都不會是毀滅性的。所以，根本談不上消除失效，或完全消除失效帶來的影響。我們能嘗試的只是設計一種自動裝置，在大部分失效發生時仍能繼續工作，這種裝置減輕了失效的后果，而不是治愈失效，大部分人造的和自然界存在的自動裝置，其內部原理都是如此。