微服務（microservices）近來已成為描述多節點分散式軟體架構的流行語：系統由許多不同元件組成，各自跑在不同的行程中、透過定義好的 API 通訊。與之相對的是單體式系統（monolithic systems）——傾向把服務的所有功能放在單一、緊密協調的應用程式裡。

微服務的好處#

微服務的好處大多圍繞著可靠性與敏捷性：

• 小而聚焦的團隊：微服務把應用拆成小塊，每塊專注提供單一服務。縮小的範圍讓每個服務可以由一個「兩個披薩」團隊（two-pizza team）建構與維護；團隊小，維持聚焦與方向一致的成本也低。
• 正式 API 帶來解耦：微服務之間的正式 API 讓團隊彼此解耦，並在服務之間提供可靠的契約（contract）——提供 API 的團隊清楚知道要保持穩定的介面範圍，消費 API 的團隊則能依賴穩定的服務而不必操心其細節。團隊得以獨立管理程式碼與釋出時程，迭代與改進的能力隨之提升。
• 更好的擴展：每個元件獨立成服務後可以獨立擴展。大型應用內的各服務很少以同樣的速率成長、用同樣的方式擴展——有的無狀態（stateless）、水平擴展即可；有的有狀態（state），需要分片等做法。各服務拆開後，才能各自採用最適合的擴展方式；全部綁在單體裡就不可能。

微服務的代價#

微服務取向有兩大缺點：

• 除錯顯著更困難：系統變得鬆耦合後，你再也不能把單一應用載入除錯器找出問題。任何錯誤都是大量系統（常跑在不同機器上）交互作用的副產物，這種環境極難在除錯器中重現。
• 設計與架構更困難：微服務系統使用多種服務間通訊方法、多種模式（同步、非同步、訊息傳遞等），以及多種服務間協調與控制的模式。

這正是分散式模式存在的理由#

如果微服務架構是由廣為人知的模式組成的：

• 設計更容易——許多設計實務已由模式規範好了。
• 除錯更容易——開發者能把從其他使用相同模式的系統中學到的教訓，套用到眼前的系統上。

本部接下來介紹一系列建構分散式系統的多節點模式。這些模式並不互斥——任何真實世界的系統，都是由多個模式協同運作、組合成單一更高階應用的。