第一章 可靠性、可擴展性、可維護性

數據系統

首先講述了大多數應用都是數據密集型而非 計算密集型,更多的問題來自於 數據量、數據變更速度,列舉一些通用組件

  • 數據庫系統:存儲數據;
  • 緩存系統:提升讀取速度;
  • 搜索索引:按照關鍵字搜索,以及過濾;
  • 批處理:定期處理大量的數據
  • 流處理:向其他進程發送消息,進行異步處理

這些系統都面臨着以下這些共同的問題

可靠性

是指系統在困境中也可以正常工作,講包括故障失效

故障

指系統的一部分狀態偏離其標準

  • 硬件故障:磁盤可以提供 RAID;雙路電源;熱插拔 CPU 等等可以解決
  • 軟件故障:系統錯誤,特定輸入引起的 BUG,依賴的服務不可用,響應變慢或者響應錯誤,級聯故障;針對這些錯誤,作者說仍然有很多小辦法,例如仔細考慮系統的假設和交互, 徹底的測試,進程隔離,監控分析生產系統的行爲;那麼在系統 運行期間就可以不斷自檢,在出現偏差時報警
  • 人爲錯誤:作者說人是不可靠的,但是我們可以精心設計 抽象,制定合理的 API;提供沙箱環境模擬真實場景,使用自動化測試覆蓋邊緣 case,快速回滾機制,詳細的配置和明確的監控。這些可以檢查系統哪些地方是否違反了假設和約束。
失效

系統作爲一個整體停止向用戶提供服務

容錯性

防止故障後導致系統失效。作者提到可以故意製造錯誤(Chaos Monkey)來不斷檢驗系統的容錯機制;對於安全問題最好是提前預防;其他的常見容錯方式有,壓測限流降級熔斷都可以看做容錯的一部分

可靠性的重要性,電商網站意味着聲譽和虧損,其他的工業例如核電站、空中管制意味着災難和法律風險;我們都有過軟件響應慢、數據丟失而氣急敗壞的情況。我們是清楚的知道不可靠的影響,所以當我們偷工減料的時候應當清楚自己在做什麼

可擴展性

  • 描述負載

    作者用了一個推特的發佈推文的例子,一個大 V 在發佈一篇推文後,其衆多粉絲都可以在自己的時間線主頁看見大 V 的推文,所以應該是在大 V 發佈推文後,將大 V 的推文推送併合併到其每個粉絲自己的時間線主頁,這樣在讀多寫少的場景下,寫入的時候多做一些事情,讀取的時候就會更容易寫。

  • 描述性能

    性能指標就是我們常見的吞吐量延遲響應時間百分位點百分位點是一個很重要的指標,一般公司會要求 99.99%,針對 0.01%請求的優化成本通常都很高,但是作者又提醒到,通常響應最慢的客戶往往是數據最多的用戶,也可以說是最有價值的用戶,就看在成本和收益之間怎麼取捨。

    排隊延時:通常是響應時間長的很大一部分。描述的是由於服務器每次只能並行處理少量請求,剩下的請求就會在隊列中排隊等待,那麼只要最開始的請求處理的很慢(這被稱爲頭部阻塞),即使後面的請求處理的很快,客戶端看到的總體響應時間也會是緩慢的。

  • 應對負載的方法

    縱向擴展(垂直擴展):更好的機器

    橫向擴展(水平擴展):無狀態的服務擴展很簡單。

    還有系統的彈性擴展,在負載高時,增加一些機器,負載低時,減少機器,負載有時很難預測,手動擴展的意外更少。

    但是將帶狀態的數據系統變爲分佈式的系統則會帶來許多額外的複雜性,後面的章節則會着重討論這些分佈式系統的原理和模式。

可維護性

作者說軟件的大部分開銷都是在持續的維護階段,漏洞修復,排查故障,修復失效,適配新的平臺,擴展新的場景,償還技術債等等。維護一個遺留系統會讓人很不爽。我們可以做的就是在設計之初就儘量考慮維護期的痛苦,避免自己的系統成爲一個遺留系統。

但是真的深思熟慮過可維護性嗎,不,大部分情況下沒有,臨時堆砌的功能,開發時間的緊迫,沒有單測,沒有集成,沒有文檔,匆忙上線,期望稍後修復上述問題,然後又是下一個需求,下一個循環…

作者整理了如下三個設計原則:

  • 可操作性

    Make it easy for operations teams to keep the system running smoothly

  • 簡單性

    Make it easy for new engineers to understand the system, by removing as much
    complexity as possible from the system. (Note this is not the same as simplicity
    of the user interface.)

  • 可演化性

    Make it easy for engineers to make changes to the system in the future, adapting
    it for unanticipated use cases as requirements change. Also known as extensibil‐
    ity, modifiability, or plasticity.

作者還補充了許多細節關於這三個設計原則達成所需要的職責,這裏就不再囉嗦。

雖然目前這些問題沒有簡單的解決方案,但是作爲工程師仍然要常常思考operability,simplicity,evolvability。

Gitbook中文翻譯版 :https://vonng.gitbooks.io/ddia-cn/content/preface.html
Github:https://github.com/hyhlinux/DDIA
英文版:鏈接:https://pan.baidu.com/s/1WsSrshLDuSuwmG60kpqdEg 密碼:ipul
有能力的還是買下書吧,也不貴。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章