微服務架構模式是一種將單一應用程式開發為一組小型服務的方法，每個服務都在自己的程序中執行，並透過輕量級機制（通常是 HTTP 資源 API）進行通訊。這些服務建構於業務功能之上，並可由全自動化部署機制獨立部署。這些服務的集中管理非常少，它們可能使用不同的程式語言和不同的資料儲存技術撰寫。儘管它們的優點讓它們在過去幾年非常流行，但它們也伴隨著增加的分布、減弱的一致性，並需要運作管理的成熟度。

「微服務架構」一詞在過去幾年中出現，用來描述一種特定的軟體應用程式設計方式，作為獨立部署服務的套件。儘管沒有對這種架構風格的精確定義，但有一些共同特徵圍繞著業務功能組織、自動化部署、端點中的智慧和語言與資料的分散控制。

與任何新的架構術語一樣，很難對微服務有一個明確的定義，因此這場演講從探討這個問題開始，根據 James 和我撰寫的、有助於激發興趣的文章。然後我將微服務與 SOA 進行比較，將架構與更單一的方法進行比較，並概述在部署微服務應用程式之前必須做對的重要事項。

隨著單體系統變得過於龐大，許多企業開始將它們拆解成微服務架構樣式。這是一趟值得的旅程，但並不容易。我們了解到，要順利完成這項工作，我們需要從一個簡單的服務開始，然後再根據對業務而言重要的垂直功能和頻繁變更的內容，繪製出服務。這些服務一開始應該規模較大，而且最好不依賴於其餘的單體應用程式。我們應該確保遷移的每一步都代表整體架構的原子化改進。

goto 會議要求我針對 Sam Newman 的著作：「從單體應用程式到微服務」進行訪談。這變成了一場關於微服務以及何時使用微服務的對話。Sam 認為微服務有三大主要原因：獨立部署、資料隔離以及反映組織結構。我比較懷疑第一個原因，但認為資料和人員是軟體開發中複雜的部分。

分散式系統對程式設計提出了特殊的挑戰。它們通常要求我們擁有資料的複本，而且這些資料需要保持同步。然而，我們無法依賴處理節點可靠地運作，而且網路延遲很容易導致不一致。儘管如此，許多組織依賴於一系列核心分散式軟體來處理資料儲存、訊息傳遞、系統管理和運算能力。這些系統會遇到常見的問題，而它們會使用類似的解決方案來解決這些問題。2020 年，Unmesh Joshi 開始將這些解決方案收集成模式，並在他開發這些模式時將它們發布到這個網站上。2023 年，這些模式在《分散式系統模式》一書中出版。此頁面連結到每個模式的簡要摘要，並提供深入連結到 oreilly.com 上線上電子書出版品的相關章節

在將巨石應用程式拆分為較小的服務時，最困難的部分實際上是拆分存在於巨石應用程式資料庫中的資料。若要萃取資料豐富的服務，遵循一系列步驟很有用，這些步驟會隨時保留資料的單一寫入副本。這些步驟從在現有的巨石應用程式中進行邏輯分離開始：將服務行為拆分為一個單獨的模組，然後將資料拆分為一個單獨的表格。這些元素可以單獨移到一個新的自主服務中。

良好的前端開發很困難。擴充前端開發，讓許多團隊可以同時處理大型且複雜的產品，甚至更困難。在本文中，我們將說明將前端巨石應用程式拆分為許多較小、更易於管理的區塊的最新趨勢，以及這種架構如何提高處理前端程式碼的團隊的效能和效率。除了討論各種好處和成本之外，我們還將介紹一些可用的實作選項，並深入探討一個展示此技術的完整範例應用程式。

許多開發團隊發現微服務架構風格是優於巨石架構的方法。但其他團隊發現它們會降低生產力。與任何架構風格一樣，微服務會帶來成本和好處。若要做出明智的選擇，您必須了解這些成本和好處，並將它們應用到您的特定情境中。

在過去幾年中，服務基礎架構已轉向較小、更專注的「微型」服務。這種方法有很多好處，例如能夠獨立部署、擴充和維護每個元件，以及在多個團隊之間並行開發。但是，一旦引入了這些額外的網路分割，就需要重新考慮適用於巨石應用程式的測試策略。在這裡，我們計畫討論許多方法，用於管理多個獨立可部署元件的額外測試複雜性，以及如何讓測試和應用程式保持正確，儘管有多個團隊各自擔任不同服務的守護者。

我在 EAA 的 P 中說「不要散佈你的物件」。這個建議是否與我對微服務的興趣相矛盾？

在過去幾個月，我反覆聽聞，要達成成功的微服務架構，唯一的方法是先從單體開始。用 Simon Brown 的話來說：如果你無法建構一個結構良好的單體，你憑什麼認為你可以建構一組結構良好的微服務？最近一次——而且一如往常地——令人信服地闡述這個論點的是 Martin Fowler 在這個網站上。由於我有機會評論較早的草稿，所以我有一些時間思考這件事。我確實思考了，特別是因為我通常認同他的觀點，而且一些我通常認同其觀點的人似乎也認同他的觀點。

我堅信從單體開始通常是完全錯誤的做法。

康威定律（由 Melvin Conway 於 1968 年提出）指出，系統的設計受到其設計人員的溝通模式的限制。Birgitta、Mike、James 和我討論了這個原則的意義，以及我們在職業生涯中看到它的運作方式。我們討論了它對微服務概念的影響，與業務功能保持一致的重要性，以及反向康威策略的角色。

基礎架構即程式碼是一種透過原始碼定義運算和網路基礎架構的方法，然後可以像任何軟體系統一樣處理。此類程式碼可以保留在原始碼控管中，以允許稽核和可重製建置，受測試實務和持續傳遞的完整規範約束。這是一種在過去十年中用於處理不斷成長的雲端運算平台的方法，並將成為未來處理運算基礎架構的主流方式。

微服務架構樣式在去年一直是熱門話題。在最近的O'Reilly 軟體架構研討會中，似乎每個場次都在討論微服務。足以讓每個人的過度炒作騙局偵測器啟動並發出警示。這造成的一個後果是，我們看到團隊過於急於採用微服務，卻沒有意識到微服務會自行引入複雜性。這會增加專案的成本和風險，而這通常會讓專案陷入嚴重困境。

當我與人討論使用微服務架構樣式時，我聽到很多樂觀的說法。開發人員喜歡使用較小的單元，並期望比單體架構有更好的模組化。但與任何架構決策一樣，都有利弊取捨。特別是微服務對營運有嚴重的影響，因為營運現在必須處理小型服務的生態系統，而不是單一且定義良好的單體架構。因此，如果您沒有某些基本能力，就不應該考慮使用微服務樣式。

當我聽到團隊使用微服務架構的故事時，我注意到一個常見的模式。

1. 幾乎所有成功的微服務案例都是從一個變得過大的單體架構開始，然後被拆分
2. 我聽說幾乎所有從頭開始建置為微服務系統的案例，最後都陷入嚴重的困境。

這種模式已導致許多同事主張：即使你確定你的應用程式夠大，值得這麼做，你也不應該使用微服務啟動新專案。。