單體優先

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

1. 幾乎所有成功的微服務故事都始於一個變得過於龐大而被拆分的單體。
2. 在我聽說過的案例中，幾乎所有從頭開始建構為微服務系統的系統最後都遇到了嚴重的問題。

這個模式讓我的許多同事認為：即使你確定你的應用程式會大到值得這麼做，你也不能用微服務開始一個新專案。

微服務是一個有用的架構，但即使是它們的擁護者也表示，使用它們會產生顯著的 微服務溢價，這表示它們只適用於更複雜的系統。這個溢價，基本上是管理一組服務的成本，會減緩團隊的速度，讓單體更適合較簡單的應用程式。這為單體優先策略提供了有力的論據，即使你認為它很可能會從後來的微服務架構中受益，你也應該先將新的應用程式建構為單體。

這樣做的第一個原因是經典的 Yagni。當你開始一個新的應用程式時，你有多確定它對你的使用者是有用的？擴充設計不良但成功的軟體系統可能很困難，但這仍然比它的反面好。正如我們現在所認知的，找出軟體構想是否實用的最佳方法通常是建構它的簡化版本，看看它的運作狀況如何。在此第一階段，你需要優先考慮速度（以及回饋的週期時間），因此微服務的溢價是你應該避免的拖累。

開始使用微服務的第二個問題是，它們只有在您想出服務之間良好、穩定的界線時才能發揮作用 - 這基本上是繪製正確的 BoundedContexts 的任務。在服務之間重構功能比在單體中難得多。但是，即使是在熟悉領域工作的經驗豐富的架構師，在開始時也很難正確地確定界線。透過先建立一個單體，您可以在微服務設計在它們上塗上一層糖漿之前，找出正確的界線。它也讓您有時間開發您需要更細緻服務的 MicroservicePrerequisites。

我聽過執行單體優先策略的不同方法。合乎邏輯的方法是仔細設計單體，注意軟體中的模組化，無論是在 API 界線或資料儲存方式上。做好這件事，轉移到微服務就會相對簡單。然而，如果我聽過大量以這種方式成功的故事，我會對這種方法感到更自在。[1]

更常見的方法是從單體開始，並逐漸剝離邊緣的微服務。這種方法可能會在微服務架構的核心留下一個實質性的單體，但大多數新開發都發生在微服務中，而單體相對靜止。

另一種常見的方法是直接完全取代單體。很少人將此視為一種值得驕傲的方法，但將單體建構為 SacrificialArchitecture 有一些優點。不要害怕建立一個您將會捨棄的單體，特別是如果單體能讓您快速進入市場。

我遇到的另一條路線是從僅有幾個粗粒度服務開始，比你預期最終會有的服務更大。使用這些粗粒度服務來習慣於使用多個服務，同時享受這樣粗粒度會減少你必須執行的服務間重構的量。然後，當邊界穩定後，再分解成更細粒度的服務。 [2]

雖然我大部分的聯絡人傾向於單體優先的方法，但這絕非一致的意見。反論說從微服務開始，可以讓你習慣於在微服務環境中開發的節奏。以足夠模組化的方式建構單體需要大量的紀律，甚至過多的紀律，才能輕鬆地將其分解成微服務。從微服務開始，你可以讓每個人從一開始就習慣於在獨立的小團隊中開發，而且讓團隊以服務邊界分開，當你需要時，可以更容易地擴大開發工作。對於系統替換來說，這特別可行，因為你更有機會在早期提出足夠穩定的邊界。儘管證據稀少，但我認為除非團隊有建構微服務系統的合理經驗，否則不應該從微服務開始。

我認為我還沒有足夠的軼事來掌握如何決定是否使用單體優先策略。這些是微服務的早期階段，而且可以學習的軼事相對較少。因此，任何人在這些主題上的建議都必須視為暫定的，無論他們如何自信地爭論。