微服務指南

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

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

1. 幾乎所有成功的微服務故事都是從一個過於龐大而被拆分的巨石開始的
2. 幾乎所有我聽說從頭開始作為微服務系統建立的系統案例，最終都遇到了嚴重問題。

這種模式導致我的許多同事主張，即使你確定你的應用程式夠大，值得這樣做，你也不能用微服務開始一個新專案。

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

我堅信，從巨石開始通常完全是錯誤的做法。

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

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

goto 會議邀請我訪問山姆·紐曼，談談他的著作：「從巨石到微服務」。這變成了一場關於微服務以及何時使用它們的對話。山姆認為微服務有三個主要原因：獨立部署、資料隔離和反映組織結構。我對第一個原因比較懷疑，但認為資料和人員是軟體開發中複雜的部分。

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

隨著巨石系統變得過於龐大而難以處理，許多企業開始將它們拆解成微服務架構樣式。這是一趟值得的旅程，但並不容易。我們了解到，要做好這件事，我們需要從一個簡單的服務開始，然後畫出基於垂直功能的服務，這些功能對業務很重要，而且容易經常變更。這些服務一開始應該很大，而且最好不依賴於其餘的巨石架構。我們應該確保遷移的每一步都代表對整體架構的原子化改進。

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

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

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

敏捷軟體開發已打破需求分析、測試和開發之間的一些隔閡。部署、操作和維護是其他活動，它們與軟體開發流程的其他部分遭受類似的隔離。DevOps 運動旨在移除這些隔閡，並鼓勵開發和操作之間的合作。

軟體系統通常會對執行於不同程序中的軟體進行遠端呼叫，這些軟體可能位於網路上的不同機器上。記憶體內呼叫和遠端呼叫之間最大的差異之一，在於遠端呼叫可能會失敗，或在達到某個逾時限制之前一直處於掛起狀態，沒有回應。更糟的是，如果一個沒有回應的供應商上有許多呼叫者，那麼您可能會耗盡關鍵資源，導致多個系統發生連鎖故障。在邁克爾·奈加德的優秀著作《釋放它》中，他推廣了斷路器模式，以防止這種災難性的連鎖反應。

斷路器的基本原理非常簡單。您將受保護的函數呼叫包裝在斷路器物件中，該物件會監控故障。一旦故障達到某個閾值，斷路器就會跳閘，並且對斷路器的所有後續呼叫都會返回錯誤，而不會執行受保護的呼叫。通常，您還希望在斷路器跳閘時收到某種監控警報。