DDIA Chap1 - HackMD

# DDIA Chap1 筆記  slide: https://hackmd.io/@1Kezo-H9RB6wHOY5b2AqAg/S1dBKDF0u --- 第一章主要講我們在設計系統的時候會關注的三大要點，尤其在當今這種微服務和分散式系統當道的時代： 1. **Reliability**: 即使系統發生(局部)錯誤，仍然可以正常運作 2. **Scalability**: 即使 load 增加，系統仍舊維持好的 performance 3. **Maintainability**: 讓工程和運維團隊更容易的演進這個系統以下分別看一下這幾點的一些 key points --- ## Reliability (可靠性) - Fault 和 Failure 是不同的: Fault 指的是系統局部元件出錯，Failure 則是系統運作不正常 - 可靠系統通常具備 fault-tolerant/resilient 的特性 - Fault 大致可以分為 Hardware/Software/Human - Redundency 是最主要的手段 - 怎麼做到高可靠的技術細節不在此展開，重點要關注對於系統的 assumption，Fault 經常就是因為 assumption 因為某種原因 (異常流量, 非預期的輸入, 等等...) 使 assumption 不再成立所導致 --- ## Scalibility (擴展性) - 先定義**負載 (Load)**: 不同場景有不同的負載面向，例：Twitter 在"發文"和 "Timeline view" 兩個不同功能上，對負載就有不同解釋。"發文" 講求 fanout 的能力；"Timeline view" 講求查詢的能力。 - 再描述**性能 (Performance)**: 所謂擴展，有兩個方式來量測 1. 負載 :arrow_double_up:，資源耗用不變下，Perf 下降多少 2. 負載 :arrow_double_up:，Perf 不變下，資源耗用上升多少 - 這兩種方式，都需要對 Perf 有一量化的描述 - 以 batch 來說，throughput (每秒處理的量) 是合適的量化指標 - 以 online system 來說，response time 是常用的指標 - 注意 "latency" 和 "response time" 的區別："response time" 說的使用戶端的感知；"latency" 講的是系統內部服務的延遲 - Percentile 是比較好的 response time 指標 (比算數平均更能體現出群體數量的特性) - 要再進一步優化 high percentile 的表現通常是昂貴的，不過這些群體通常也是最有優化價值的一群人 (例：高端消費者，有巨量的交易歷史紀錄) - 系統內的 latency 也可以用 percentile 量測，不過不能只量測系統內而忽略用戶端整體，因為系統是有**排隊效應**的。雖然單看 component 每個執行的 percentile 都很低，**但系統資源有限，單看 component 的 percentile 會忽略掉排隊等待資源的時間** - **Tail latency amplification**: 當一個 request 需要多個 component 協作完成，那麼 percentile 會被最慢的那個 dominate --- ## Maintainability (易維護性) - **Operability**: "Good operability means making routine tasks easy" - **Simplicity**: - Accidental complexity: 非源自 problem domain 而是 implementation domain 的複雜度是應該盡力避免的 - 最好的工具就是 abstraction，然而找到好的抽象是困難的，這本書接下來就是要介紹一些常見的 patterns，讓我們可以利用這些經驗去構建一個好的抽象 - **Evolvability**: 就是 Agile development 那些概念 ~ --- ### Wrap up - 第一章講述了這本書主要希望達成的目標 - 看下來就是一些軟體工程本來就很注重的東西，不過經過他有系統的整理，又對這些特性有更深的理解 --- ### Thank you! :sheep: You can find me on - [GitHub](https://github.com/browny) - [Twitter](https://twitter.com/brownylin)