重點摘要#
- 理想的系統屬性往往三者不可兼得，接受約束反而可能帶來更好的架構
- CAP 定理是經典範例：一致性、可用性、分區容錯性只能選其二
- 不要把系統屬性當作不可侵犯的教條，而要問「為什麼」和「何時」需要
- 接受取捨的必然性，往往能激發更有創意的解決方案
詳細內容#
有時候接受一個約束或放棄某個屬性，反而能帶來一個更好的架構——更容易建構和運行。理想的屬性往往三個一組出現，試圖建構一個同時支援三者的系統，結果往往是什麼都做不好。
CAP 定理#
一個經典的例子是 Brewer 猜想，也稱為 CAP 定理（Consistency, Availability, Partitioning）：
- 一致性（Consistency）
- 可用性（Availability）
- 分區容錯性（Partition Tolerance）
在分散式系統中，這三個屬性不可能同時完全達成。試圖三者兼得只會大幅增加工程成本和複雜性，卻無法真正達到預期的效果或商業目標。
教條主義的危險#
人們常常將某些屬性視為不可侵犯的：資料不能有重複、所有寫入必須是交易式的、系統必須 100% 可用、不能有單點故障、一切都必須可擴展……
將屬性當作宗教教條來對待，會阻止你思考手頭的問題。我們開始談論「架構偏差」而非「有原則的設計」，混淆了教條主義和良好治理。
正確的態度#
應該問的是：
- 為什麼這些屬性必須成立？
- 這樣做有什麼好處？
- 何時這些屬性是可取的？
- 如何打破系統以獲得更好的結果？
取捨的必然性是軟體開發中最難接受的事情之一。但我們應該珍惜取捨，因為它遠比擁有無限選擇要好——接受取捨往往能激發出創意和發明。
— By Bill de hOra