爲什麼微服務架構不基於企業服務總線？

Question

在構建遵循微服務體系結構的整體服務（http://martinfowler.com/articles/microservices.html）時，針對（或要求）使用企業服務總線功能的原因是什麼？爲什麼我們應該使用啞管道和智能端點，而不是使用更智能的管道，並且能夠開發更簡單的服務？

Answer 1

術語ESB已經被重載，主要是在Java世界中，意味着一個龐大而複雜的基礎架構，最終在一箇中心位置託管一堆執行不力的邏輯。

像Apache Caml或NServiceBus這樣的輕量級技術並不鼓勵這種方法，並且確實遵循從一開始就充當互聯網骨幹的「啞管道/智能端點」方法。

NServiceBus特別關注於提供比大多數消息傳遞庫更高級別的框架，以便通過更深入地支持一次性和一次性消息處理來更輕鬆地構建更可靠的智能端點。

完全披露 - 我是NServiceBus的創始人。

Answer 2

ESB如何使用的問題是它通過在ESB中構建一些業務邏輯來創建ESB和服務之間的耦合。這將使得單獨部署單一服務變得更加困難，並且越來越使ESB更加複雜且難以維護。

Answer 3

這是一個巨大的問題，可能無法在SO的Q &格式中有效回答。

這取決於你在做什麼。

如果你正在構建一個單獨的產品，它包含許多可以被認爲是獨立的小部分功能，那麼微服務可能是一條可行的路。

如果您是一家大型企業組織，IT不是董事會主要考慮的競爭優勢，而且您在嚴格規範的行業工作，新標準必須應用於具有自己的IT的全球分佈式項目部門，有些來自新收購，您無法集中控制組織內的所有端點和應用程序，那麼您可能需要一個ESB。

我不想被指責試圖列出全部這兩種方法的優點在這裏，因爲它們不完整，可能會過時。

說了這麼多，在努力成爲有用的OP：

如果你看到了Spotify和Netflix的怎麼辦微服務，你可以找到自己喜歡的方式很多事情，包括但不限於：緩解部署個別服務的藍/綠部署，解耦團隊結構以及隔離失敗。

ESB允許您集中管理和執行策略，如法律要求，在一個地方審覈所有內容，而不是希望每個團隊都能夠記錄所有事情，提供有關負載和正常運行時間的全球統計信息以及其他許多事情。 ESB從大型企業發展而來，驅動程序不是客戶在網站上的響應時間和創新速度（除其他外），而是服務水平協議，成本效益和法規（等等）。

這兩種方法都有很多價值。目前正在撰寫微服務，就像10到15年前的ESB一樣。也許這是一種進步，也許這只是一種改變，也許只是消費品公司需要推銷自己，大型企業希望保持私密。我們可能會在10年後發現。目前，這很大程度上取決於你在做什麼。與編程中的大多數事情一樣，我會從簡單的開始，如果需要的話，只會轉向更復雜的解決方案。

Answer 4

由於服務被隔離並且管道被重新使用。

微服務的核心思想是隔離 - 系統的任何部分都可以被替換而不影響其他服務。智能管道意味着他們有配置，他們有狀態，他們有複雜（通常意味着難以預測）的行爲。因此，隨着時間的推移，智能管道不太可能保持其確切的行爲。

但是 - 管道更改會影響每個附加服務，而服務更改僅影響使用它的其他服務。