微服務高級版

在過去的一年中，微服務架構風格一直是熱門話題。在最近的O'Reilly 軟體架構會議中，似乎每個議程都在談論微服務。這足以讓每個人的過度炒作警報器亮起並閃爍。這其中一個後果是，我們看到團隊過於急於採用微服務，[1]沒有意識到微服務本身會帶來複雜性。這會增加專案的成本和風險，而這通常會讓專案陷入嚴重困境。

儘管微服務的炒作令人厭煩，但我認為這是一個有用的術語，用於描述一種已經存在一段時間的架構風格，但需要一個名稱才能更輕鬆地討論它。這裡重要的是，不要對炒作感到多麼厭煩，而是它引發的架構問題：微服務架構是否適合您正在開發的系統？

對一個有趣的問題的任何體面的答案都始於「取決於...」

-- Kent Beck

「取決於」必須開始我的回答，但接下來我必須將重點轉移到它取決於哪些因素。使用或不使用微服務的關鍵在於您正在考慮的系統的複雜性。微服務方法完全在於處理複雜的系統，但為了做到這一點，這種方法引入了它自己的一組複雜性。當您使用微服務時，您必須處理自動部署、監控、處理故障、最終一致性和分布式系統引入的其他因素。有眾所周知的方法可以應對所有這些問題，但這需要額外的努力，而且我認識的軟體開發人員似乎沒有太多空閒時間。

因此我的主要指導原則是除非你的系統複雜到無法作為單體管理，否則甚至不要考慮微服務。大多數軟體系統都應該建置為單一單體應用程式。請注意單體中的良好模組化，但不要嘗試將其分為個別服務。

驅使我們採用微服務的複雜性可能來自許多來源，包括處理大型團隊[2]、多租戶、支援許多使用者互動模式、允許不同的業務功能獨立演進，以及擴充。但最大的因素是純粹的規模 - 人們發現他們有一個單體，太大而無法修改和部署。

在這個時候，我感到有些沮喪。許多歸因於單體的問題並非該樣式的本質。我聽過人們說，你必須使用微服務，因為使用單體無法進行持續交付 - 但有許多組織使用標準部署方法獲得成功：Facebook 和 Etsy 是兩個著名的範例。

我也聽過這樣的論點，隨著系統規模的增加，你必須使用微服務才能擁有容易修改和更換的零件。但沒有理由不能建立一個具有明確模組邊界的單一單體。至少在理論上沒有理由，在實務上，模組邊界似乎很容易被打破，而單體也會變得糾結且龐大。

我們也應該記住，不同微服務系統之間的服務規模有很大的差異。我見過微服務系統從擁有 20 個服務的 60 人團隊到擁有 200 個服務的 4 人團隊。服務規模在多大程度上影響溢價並不清楚。

隨著規模和其他複雜性助推器進入專案，我看到許多團隊發現微服務是一個更好的選擇。但除非你面臨這種複雜性，請記住，微服務方法會帶來高溢價，可能會大幅減緩你的開發速度。因此，如果你能讓你的系統保持足夠簡單，以避免需要微服務：請這麼做。