無代碼開發(fā)平臺(國內(nèi)無代碼開發(fā)平臺推薦)">國內(nèi)無代碼開發(fā)平臺(國內(nèi)無代碼開發(fā)平臺推薦)
919
2025-04-03
何謂系統(tǒng)穩(wěn)定性?
控制系統(tǒng)理論認為:系統(tǒng)受到某種干擾而偏離正常狀態(tài),當(dāng)干擾消除,如果系統(tǒng)的擾動能逐漸收斂并最終恢復(fù)正常狀態(tài),則系統(tǒng)是穩(wěn)定的,反之,系統(tǒng)偏離越來越大,則是不穩(wěn)定的,所以,穩(wěn)定性是系統(tǒng)抗干擾和返回平衡狀態(tài)的能力。
對于經(jīng)典的傳遞函數(shù)的軟件系統(tǒng),一般我們講的穩(wěn)定指的是BIBO穩(wěn)定,即有界輸入有界輸出穩(wěn)定。一個系統(tǒng)如果對任意有界輸入得到有界輸出,它就是BIBO穩(wěn)定的。一句話,穩(wěn)定的系統(tǒng)對于各種輸入需要有符合預(yù)期的輸出。
隨著軟件復(fù)雜性越來越高,穩(wěn)定性的保障越來越難,隨著服務(wù)規(guī)模越來越大,穩(wěn)定性的重要性越來越高。
我們的軟件需求和計劃很少考慮非功能部分,然而軟件的結(jié)構(gòu)和實現(xiàn)卻有非常大的比重服務(wù)于此,這也許是軟件項目計劃經(jīng)常延期的重要原因。
如何保障穩(wěn)定性?
雖然理論上沒有絕對穩(wěn)定的系統(tǒng),但我們依然可以有所作為,使我們設(shè)計和開發(fā)的系統(tǒng)在生產(chǎn)環(huán)境接近穩(wěn)定運行。
從大的方面講,穩(wěn)定性保障,可以分成3個部分:
制度紀律
編碼規(guī)范、代碼提交門禁
Code Review
靜態(tài)代碼掃描,動態(tài)代碼分析
Unit Test、壓測
灰度發(fā)布、Rollback、應(yīng)急預(yù)案
監(jiān)控
復(fù)盤、故障樹分析
思想之道
保持簡單、降低復(fù)雜度
不(零)信任、面向失敗設(shè)計
實踐之術(shù)
冗余設(shè)計(數(shù)據(jù)、計算、帶寬冗余)
快速恢復(fù)設(shè)計(無狀態(tài)設(shè)計)
容錯、災(zāi)備
隔離
過載保護(限流、熔斷、有損服務(wù))
錯誤重試策略,避免流量風(fēng)暴
去關(guān)鍵路徑、去中心化、避免單點故障
負載均衡(load balance)
看門狗設(shè)計
安全編碼
制度紀律
通過制度去規(guī)范操作和行為,通過紀律去約束大家在框架內(nèi)活動,被證明是保障穩(wěn)定減少出錯行之有效的方式。
紀律是關(guān)鍵,只有持之以恒的遵守制度,才能避免方法和規(guī)定淪為空談。
但制度和紀律只是劃出質(zhì)量底線,只能解決大多數(shù)穩(wěn)定性問題,難以發(fā)現(xiàn)一些隱匿的問題,需要配合思想之道和實踐之術(shù),持續(xù)改進軟件質(zhì)量,才能全面保障穩(wěn)定性。
思想之道
道是大的層面,它具有全局性的指導(dǎo)意義,我從眾多的指導(dǎo)思想里,挑選最重要的兩點:保持簡單和不信任/面向失敗設(shè)計,展開來講。
1. 保持簡單
復(fù)雜是穩(wěn)定性的天敵,保持簡單即保持穩(wěn)定。單一職責(zé),功能清晰即是踐行保持簡單。
把簡單的東西搞復(fù)雜很容易,而化繁為簡則堪稱化腐朽為神奇。所以保持簡單并不是低要求,它需要你透過表象洞悉事物本質(zhì),用最直接最土味的方式解決問題,做技術(shù)的同學(xué)有一個奇怪的癖好,喜歡把自己最近琢磨的東西用到項目中,不然總有錦衣夜行的感覺。
2. 不信任設(shè)計、面向失敗設(shè)計
不信任設(shè)計又叫零信任設(shè)計,和面向失敗的設(shè)計有相似之處,其本質(zhì)都是防御性編程思想。
不信任設(shè)計思想假設(shè)系統(tǒng)依賴的上下游都不靠譜,假設(shè)周圍都是壞人,假設(shè)攻擊無處不在。
網(wǎng)絡(luò)服務(wù)需要對客戶端請求參數(shù)做嚴格驗證,不僅檢查合法性,也要驗證NaN。游戲開發(fā)有一句名言:假設(shè)客戶端的數(shù)據(jù)都是假的。
進程內(nèi)的函數(shù)調(diào)用大多時候很安全,會有可預(yù)期的結(jié)果,但如果跨進程調(diào)用(RPC)的可靠性則會低很多,有可能超時,有可能丟包,有可能失敗,調(diào)用者必須意識并處理好各種異常情況,是重試?如果重試的話重試多少次?重試之間的間隔應(yīng)該怎么確定?請求的上下文怎么保存和恢復(fù)?
我們要正確理解不信任設(shè)計的內(nèi)涵,避免用力過猛,警惕借面向失敗設(shè)計之名行無效編程之實,比如已經(jīng)對客戶端請求數(shù)據(jù)做了嚴格校驗,在服務(wù)器處理過程中,重復(fù)檢驗,比如已經(jīng)對接口入?yún)⑴锌眨趦?nèi)部調(diào)用過程中重復(fù)判斷。這會降低代碼濃度,混入大量無效代碼,損傷可讀性和執(zhí)行效率,本質(zhì)上是違背“保持簡單”原則的。
實踐之術(shù)
術(shù)是局部層面,它是實踐經(jīng)驗,牽扯方方面面,難以盡數(shù)枚舉。
如果以文章寫作類比軟件開發(fā),謀篇布局相當(dāng)于設(shè)計層面,設(shè)計層面要致廣遠,遣詞造句相當(dāng)于實現(xiàn)層面,實現(xiàn)層面要盡精微。
所謂千里之堤潰于蟻穴,防微杜漸功德無量。
1. 冗余設(shè)計
冗余設(shè)計指留出安全余量,冗余包括數(shù)據(jù)冗余、計算冗余、帶寬冗余。
數(shù)據(jù)冗余指一份數(shù)據(jù)多個副本,一主多備。
計算冗余,比如服務(wù)實例的QPS極限是10K,但實際上我們會按5K跑,這樣,即使出現(xiàn)流量超速增長,我們依然有反應(yīng)時間。
2. 快速恢復(fù)設(shè)計(無狀態(tài)設(shè)計)
互聯(lián)網(wǎng)服務(wù)很多都是無狀態(tài)設(shè)計,服務(wù)實例只是邏輯的盒子,后面跟著分布式一致性數(shù)據(jù)庫,這樣能極大簡化設(shè)計,即使實例掛了,客戶可以很容易遷移到其他服務(wù)實例執(zhí)行,而有狀態(tài)設(shè)計則要復(fù)雜難搞得多。
3. 容錯、災(zāi)備
容錯指我們的系統(tǒng)要有一定的錯誤容忍能力,這意味錯誤發(fā)生,我們要能查錯、檢錯、避錯、甚至改錯,只要可能,我們就要吞咽錯誤。
災(zāi)備這個大家耳熟能詳,主從設(shè)計,異地備災(zāi),目標都是為了應(yīng)對各種極限情況。
4. 隔離
隔離本質(zhì)上就是說如果故障發(fā)生了,如果故障發(fā)生,而又不能吞咽,那也應(yīng)該隔離避免錯誤傳播擴散,千方百計縮小影響范圍,相當(dāng)于感染新冠要被隔離起來。容器化等技術(shù)為隔離提供良好能力支撐。
5. 過載保護
熔斷
熔斷機制不止軟件設(shè)計獨有,股市也有,我甚至懷疑軟件的熔斷機制是從股市學(xué)來的。
限流
系統(tǒng)設(shè)計要做好資源耗盡、資源不夠用的情況,如果服務(wù)請求超過服務(wù)能力,那就應(yīng)該限流,這應(yīng)該作為一種配置,或者自動執(zhí)行的策略。
這個跟地鐵限流差不多,處理不了,那就排隊。
有損服務(wù)
有損服務(wù)我印象中最先是騰訊跟海量服務(wù)的概念一起提出來的,指如果出現(xiàn)服務(wù)能力不夠,不能為所有客戶所有業(yè)務(wù)提供服務(wù)的異常情況,那系統(tǒng)有所取舍,盡可能保持業(yè)務(wù)運行,減少損失,比如在微信服務(wù)器在處理能力有限的情況下,可以優(yōu)先保消息發(fā)送,而關(guān)閉朋友圈服務(wù)能力,比如直播業(yè)務(wù)在帶寬有限的情況下,應(yīng)該降低碼率減少清晰度,而不應(yīng)該拒絕服務(wù)。
有損的意義就是有損失,有損傷的意思,它是一種思想,是退而求其次,是不得已而為之。
6. 錯誤重試策略,避免流量風(fēng)暴
如果設(shè)計一個ToC服務(wù),在客戶大規(guī)模斷連的情況下,客戶會重連,重連失敗再連,如果重連嘗試的頻率不控制好,正??蛻舳酥剡B有可能演變成對服務(wù)器的大規(guī)模攻擊,打爆一臺服務(wù)器,又去滅另一臺,這太嚇人了。
可以參考kernel TCP的重連策略,有最大嘗試次數(shù),而且重試間隔是逐漸拉大的。
7 去關(guān)鍵路徑、去中心化、避免單點故障
企業(yè)不要關(guān)鍵先生,關(guān)鍵先生會成為瓶頸,軟件也不能把寶壓到一個地方,去中心化去集中式,沒什么難理解的。
8 負載均衡
load balance其實就是分擔(dān)壓力,LB要避免傾斜,有多種LB算法,比如RR,比如一致性hash,各有利弊,有興趣可以研究下。
LB不僅限于服務(wù),進程內(nèi)的多線程可能也會需要考慮這個問題。
9 看門狗和心跳機制
可以參考kernel的watch dog,其實就是看護機制,檢測錯誤并努力掰過來。
10 安全編碼
安全編碼是一個職業(yè)程序員的基本要求,安全編碼規(guī)則很多,很細節(jié)的一些規(guī)矩。這個可能跟語言相關(guān),如果是C++相關(guān)的可以參考:C++的門門道道
C相關(guān)的規(guī)則要少一些,我順手列舉一些。
比如要注意初始化。
比如全局變量不要有構(gòu)造順序的依賴。
比如慎用強轉(zhuǎn),強轉(zhuǎn)等于接管了編譯幫你做的類型檢查。
比如理解線程安全函數(shù),理解可重入的概念,理解信號機制。
比如要避免死鎖,理解ABBA鎖理解自死鎖。
比如要謹防資源泄漏。
比如處理好內(nèi)存分配失敗的情況,理解野/懸垂指針。
比如要處理好邊界,防止越界,溢出。
比如內(nèi)存拷貝要避免內(nèi)存重疊,理解memmove的用途。
比如理解遞歸的低效和棧的大小限制,避免爆棧。
比如建議使用STD安全版本函數(shù)(_s+n)版本。
比如了解unsigned? < 0導(dǎo)致死循環(huán)的情況。
比如了解浮點數(shù)跟0比較的問題。
比如理解整型數(shù)據(jù)溢出和反轉(zhuǎn)。
比如不要返回臨時變量的引用或者指針,理解棧幀動態(tài)伸縮的原理。
比如理解做好把關(guān)檢查的必要性,包括系統(tǒng)把關(guān)和模塊把關(guān)。
小結(jié)
最后來讀段經(jīng)典:《系統(tǒng)化思維導(dǎo)論》一書中引用馮諾依曼的話寫道:如果你觀察一些自動裝置,不論它們是人類設(shè)計的還是自然界本來就存在的,你通常會發(fā)現(xiàn),它們的結(jié)構(gòu)很大程度上受控于它們可能失效的方式,以及針對失效所采取的防御性措施(多少有些效果),說它們能預(yù)防失效有點夸張,它們不是能預(yù)防失效的,只是被設(shè)計成試圖達到這種狀態(tài),這樣至少大部分失效都不會是毀滅性的。所以,根本談不上消除失效,或完全消除失效帶來的影響。我們能嘗試的只是設(shè)計一種自動裝置,在大部分失效發(fā)生時仍能繼續(xù)工作,這種裝置減輕了失效的后果,而不是治愈失效,大部分人造的和自然界存在的自動裝置,其內(nèi)部原理都是如此。
軟件開發(fā)
版權(quán)聲明:本文內(nèi)容由網(wǎng)絡(luò)用戶投稿,版權(quán)歸原作者所有,本站不擁有其著作權(quán),亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容,請聯(lián)系我們jiasou666@gmail.com 處理,核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。
版權(quán)聲明:本文內(nèi)容由網(wǎng)絡(luò)用戶投稿,版權(quán)歸原作者所有,本站不擁有其著作權(quán),亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容,請聯(lián)系我們jiasou666@gmail.com 處理,核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。