詳解軟件系統穩定性的三大秘密

Posted on by

何謂系統穩定性？

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

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

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

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

如何保障穩定性？

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

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

制度紀律：

  • 編碼規范、代碼提交門禁
  • Code Review
  • 靜態代碼掃描，動態代碼分析
  • Unit Test、壓測
  • 灰度發佈、Rollback、應急預案
  • 監控
  • 復盤、故障樹分析

思想之道：

  • 保持簡單、降低復雜度
  • 不（零）信任、面向失敗設計

實踐之術：

  • 冗餘設計（數據、計算、帶寬冗餘）
  • 快速恢復設計（無狀態設計）
  • 容錯、災備
  • 隔離
  • 過載保護（限流、熔斷、有損服務）
  • 錯誤重試策略，避免流量風暴
  • 去關鍵路徑、去中心化、避免單點故障
  • 負載均衡（load balance）
  • 看門狗設計
  • 安全編碼

制度紀律

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

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

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

思想之道

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

1. 保持簡單

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

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

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

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

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

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

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

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

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

實踐之術

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

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

所謂千裡之堤潰於蟻穴，防微杜漸功德無量。

1. 冗餘設計

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

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

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

2. 快速恢復設計（無狀態設計）

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

3. 容錯、災備

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

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

4. 隔離

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

5. 過載保護熔斷

熔斷：

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

限流：

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

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

有損服務：

有損服務我印象中最先是騰訊跟海量服務的概念一起提出來的，指如果出現服務能力不夠，不能為所有客戶所有業務提供服務的異常情況，那系統有所取舍，盡可能保持業務運行，減少損失，比如在微信服務器在處理能力有限的情況下，可以優先保消息發送，而關閉朋友圈服務能力，比如直播業務在帶寬有限的情況下，應該降低碼率減少清晰度，而不應該拒絕服務。

有損的意義就是有損失，有損傷的意思，它是一種思想，是退而求其次，是不得已而為之。

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

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

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

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

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

8.負載均衡

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

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

9.看門狗和心跳機制

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

10.安全編碼

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

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

小結

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

以上就是詳解軟件系統穩定性的三大秘密的詳細內容，更多關於軟件系統穩定性的三大秘密的資料請關註WalkonNet其它相關文章！

推薦閱讀：