實體服務是一種反模式

在微服務架構中，最重要的是要保持服務間的隔離。實體服務（Entity Service）是被廣泛應用於微服務架構上的一種模式，但其實它是一種反模式，因為它背離了服務隔離的原則。Michael Nygard在他的微服務系列部落格中提到了這一點。

\\

Nygard是“Release It!”的作者，他說實體服務被用於解決一個非常常見的問題，在微軟的一本關於微服務架構的電子書中和Spring的兩個教程中均用到了這種模式。

\\

在Nygard看來，反模式只會讓事情變得更糟。為了說明實體服務是一種反模式，他使用一個大型的遺留單體作為例子。這個應用程式有多個例項，每個例項都包含了所有特性：

\\

\\

根據Spring的教程，使用微服務架構對這個應用程式進行重構，將特性分解到單獨的服務中。但Nygard說，大部分特性仍然需要多個實體，這樣就會在多個實體之間形成依賴。比如，計算購物車的價錢需要所有服務的介入：

\\

\\

Nygard認為，這些依賴會造成耦合，從而影響可用性、效能和容量。他還強調說，這些依賴導致語義上的耦合，一個服務的變更會波及到其他服務。在最糟糕的情況下，這樣會導致一個服務需要與不同版本的服務打交道。

\\

Nygard總結了在微服務架構中使用實體服務將會產生的結果：

\\

• 團隊仍然可以按照他們的節奏釋出服務。\\\t
• 語義上的耦合導致了跨團隊的協商。\\\t
• 大量請求需要呼叫實體服務，增加了流量負載。\\\t
• 整體的可用性取決於更多的服務。\

基於以上幾點，Nygard認為實體服務是一種反模式。

\\

來自Fourth.com的首席架構師Ben Morris在另一篇博文中引用了Nygard的文章，他說，在微服務架構中使用實體服務比單體架構還要糟糕。Morris認為，微服務的優勢之一就是它的自治性，但細粒度的服務越多，它們之間的耦合就越大，從而降低了自治性。他強調說，流程的變更會變得很困難，因為困難涉及到大量的服務，而如果服務是由不同的開發團隊進行維護的，那麼變更會變得更加困難。使用大量小型耦合服務的另一個風險在於，一個服務發生故障會產生級聯效應，影響到更多的服務。

\\

Nygard的博文引發了長時間的討論。微軟那本電子書的作者說，他們在書中已經針對使用HTTP呼叫來耦合微服務這樣的做法提供了警告。他也強調，正確使用領域模型可以提升微服務的自治性。

\\

在Nygard後續的博文中，他將會介紹實體服務的替代方案。

\\

檢視英文原文：Entity Services is an Antipattern