系統健壯性的思考


一、概述最近系統有兩個故障都跟系統健壯有很大的關系。為此,我們不得不進行思考,如何提高系統的健壯性。系統在經過功能測試后,對於正常的業務數據處理往往沒有任何的問題,但是對於一些異常的數據、異常的業務處理就會出現系統集群不可用等災難性的問題。
  • 異常的數據一般是因為系統的數據修正引起,往往在存儲方面就不符合業務一致性約束。對於一些有年代的系統,數據修正又不可少,在我就職的部門中,每天都在進行着數據修正。如果有位開發因為數據修正,導致整個集群掛掉了,這是很悲劇的。有人說,一切都是數據修正的錯,如果沒有數據修正,系統能很好的運行,但是現實的問題是,每天必須得數據修正。
  • 另一個是異常的業務,其實也是一個修正,我們認為業務部門沒有按照要求來使用我們的系統,業務方亂來,或者是開發又一個不經意的業務修正。
他們說,你這個系統這么不健壯,但是現實的問題是,我們經常是被業務牽着走,那有時間關心系統的健壯性,能實現功能就萬事大吉了。先不管時間問題,系統還是應該考慮健壯性的,我們在設計系統的時候就需要考慮一些常見的不可忽視的問題。二、一些基本的措施我認為,提高健壯性需要從幾個方面入手:業務壓力、架構設計、程序編碼、監控反饋。
  • 業務壓力,我們需要團隊來評估好業務的壓力,未來一定的時間內,有多少的流量。如上次做了一個發票系統,業務給出的評估是每天1w不到的發票量,不到10w的api調用。那么我可以認為目前財務系統的架構完全能勝任,不用加任何機器,甚至不用特別的優化,當然所有的頁面請求都必須走上索引。
  • 架構設計,這個范圍很大,一般我們對於不是特別實時的業務采取用時間換取性能、以空間換性能等方案。如:把一些數據先存在數據庫中,待半夜壓力小的時候,再處理;對於一些有峰值的業務,我們一般采用異步消息的方案,讓MQ來做緩沖;對於查詢多,讀多寫少,我們一般采取CQRS的方案,針對讀取可能還用到了搜索引擎的技術;為了協調多個系統變更,我們往往不使用分布式事務,經常采取的是補償機制等等。
  • 程序編碼,代碼才是最終剩下的看得見的。程序員最起碼需要能寫好代碼,也要寫出健壯性的代碼。對於字符串的空值判斷;及時回收對象;對於大數據量處理要真分頁;不要寫死循環來做sleep;不寫出可能出現的死循環;不要吃掉異常;知道有異常后要有補救措施等。編寫代碼的時候,注意的點還是非常多的,此時需要借助一些靜態工具,如:sonar、findbugs、PMD等。
  • 監控反饋,當程序出現異常后,要及時報警,要有補救措施。報警可以發送給人,也可以發送給系統自動處理,如:服務降級、自動重啟等。人為處理的時候,一定要想清楚了,是否會引起連環效應。
三、重點突出我認為,一般突出的問題有:空指針異常數據修正危機
  • 有對象的地方就有空指針,有對象的地方就有字符串。在寫代碼的時候,都要做空對象的驗證。沒有誰能保證你用的對象不為空。這句話很極端,但就是讓開發知道空指針隨時存在,需好好處理。
  • 數據修正危機,大部分情況是,平時基本查詢更新都是有幾條數據,但是突然變成了幾十萬條數據的查詢與更新。對於查詢,一會就出現服務器內存暴漲,一段時間后,服務一般是處於要死不死的狀態。對於更新,基本是超時,數據庫壓力變大,此時就危險了。引起數據暴漲的情況有很多,大部分是數據修正引起。此時我們一般在數據映射的底層做好限制,當查詢、更新超過一定數目就拋出異常,此舉可以保護應用或者數據庫。
四、后言以上談了一些系統健壯性問題,可能遠遠不足。我也吃一塹長一智,遇到了故障及時解決,再總結教訓即可。以上是一些思考,歡迎指出不足。

注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2021 ITdaan.com