微服務與分布式物件的第一法則

當我撰寫 企業應用程式架構模式 時，我創造了一個我稱之為分布式物件設計的第一法則：「不要分布你的物件」。最近幾個月，微服務 引起許多人的興趣，這導致一些人詢問微服務是否違反了這條法則，如果是，為什麼我支持微服務？

在這個第一法則陳述中，我使用「分布式物件」這個詞彙，這反映了在 90 年代後期到 00 年代初期相當流行的一個想法，但自此之後（正確地）不受歡迎。分布式物件的想法是，你可以設計物件，並選擇在處理程序內或遠端使用這些相同的物件，其中遠端可能表示同一台機器中的另一個處理程序，或在不同的機器上。精明的中間軟體，例如 DCOM 或 CORBA 實作，將處理處理程序內/遠端區別，因此你的系統可以撰寫，而且你可以將其分解成處理程序，而與應用程式的設計方式無關。

我反對分布式物件概念的原因是，儘管你可以封裝許多物件邊界背後的事物，你無法封裝遠端/處理程序內區別。處理程序內函數呼叫快速且總是成功（因為任何例外都是因為應用程式，而不是因為呼叫本身）。然而，遠端呼叫的數量級較慢，而且由於遠端處理程序或連線故障，呼叫總是有可能失敗。

這個差異的後果是，你的 API 指南不同。如果需要 100 個產品價格和可用性，處理程序內呼叫可以很精細，你可以放心地對產品價格函數進行 100 次呼叫，並對可用性進行另外 100 次呼叫。但是，如果該函數是遠端呼叫，通常最好將所有這些批次處理成一次呼叫，一次要求所有 100 個價格和可用性。結果是你的產品物件有一個非常不同的介面。因此，你無法採用相同的類別（主要與介面有關），並在處理程序內或遠端方式中透明地使用它。

我交談過的微服務倡導者非常清楚這個區別，而且我沒有聽過他們中的任何一位談論處理程序內/遠端透明性。因此，他們並未嘗試執行分布式物件嘗試執行的任務，因此不會違反第一法則。相反，他們提倡透過 HTTP 或輕量級訊息傳遞與文件進行粗粒度互動。

因此，基本上，我對分布式物件的看法與微服務倡導者之間沒有矛盾。儘管有這種本質上的非衝突，但現在有一個問題亟待提出。微服務意味著小型分布式單元，它們透過遠端連線進行通訊，遠遠超過一個整體會執行的任務。即使它滿足了第一法則的文字，這是否違反了第一法則的精神？

雖然我接受為許多系統進行分散式設計有其正當理由，但我認為分散式設計會增加複雜性。較粗略的 API 比細緻的 API 還要笨拙。您需要決定如何處理遠端呼叫失敗，以及對一致性和可用性的影響。即使透過通訊協定設計將遠端呼叫降到最低，您仍然必須更深入思考與其相關的效能問題。在設計單體時，您必須擔心模組之間的責任分配，而分散式系統則必須擔心模組之間的責任分配和分散式因素。

雖然小型微服務當然比較容易理解，但我擔心這會將複雜性轉移到服務之間的互連，而這會降低明確定義，因此當出現問題時會更難找出原因。當您必須跨越遠端界線時，重構會變得更加困難。微服務倡導者宣傳非同步通訊所帶來的耦合減少，但非同步性是另一個複雜性提升因素。Cookie-cutter scaling 讓您可以在不增加分散式複雜性的情況下處理大量的流量。

因此，我對分散式設計持謹慎態度，我預設傾向於偏好單體設計。有鑑於此，為什麼我花費大量心力描述微服務並支持倡導微服務的同事？答案是因為我知道自己的直覺並不總是正確的。我無法否認許多團隊採用微服務方法並獲得成功，無論是像 Netflix 和（可能）Amazon 等眾所周知的公開案例，或是我在 Thoughtworks 內外交談過的各種團隊。我天生就是一位經驗主義者，相信經驗證據勝過理論，即使該理論比我的直覺更完善。

我不是認為此事已解決。在軟體交付中，成功是一個很難辨識的東西。儘管像 Netflix 和 Spotify 等組織宣揚他們早期使用微服務的成功，但也有像 Etsy 或 Facebook 等成功使用更單體架構的範例。一個團隊可能認為自己使用微服務很成功，但唯一真正的比較是反事實比較 - 如果使用單體架構，他們會不會做得更好？微服務方法只存在了一段相對較短的時間，因此我們沒有來自十年歷史的微服務架構的證據，可以與我們如此不喜歡的那些老舊單體架構進行比較。而且可能有一些我們尚未辨識的因素，表示在某些情況下單體架構較好，而在其他情況下微服務較好。由於在軟體開發中收集證據很困難，因此即使過了許多年的時間，也不太可能對其中之一做出令人信服的決定。

由於這種不確定性，像我這樣的寫作者能做的最重要的事情，就是盡可能清楚地傳達我們認為已學到的教訓，即使它們是矛盾的。讀者會做出自己的決定，我們作為寫作者的工作是確保這些決定是明智的，無論他們屬於架構線的哪一側。

---