Architecture 为什么ESB在微服务体系结构中被认为是不好的

在微服务体系结构中，自治业务服务应该彼此直接对话。通信可以是同步的（编排）或基于事件的（编排）。API网关可以聚合客户端的API（后端用于前端）。借助微服务，我们正在寻求两个最终目标

• 低耦合
• 高内聚

这使得连续部署、细粒度扩展、快速技术适应、可重用性和可审计性得到了更大的提高，当然代价是更高的复杂性

---

但是，强烈建议不要使用ESB（企业服务总线）或其他中间件。微服务和ESB通常被视为一种竞争解决方案。为什么ESB看起来如此糟糕？只要它只是作为一个带有一些附加监视和身份验证层（没有业务逻辑）的冥想通道使用，那么在微服务体系结构中使用它有什么问题？

我在不同的公司看到了两个ESB的推出，在这两种情况下，都有相同的崇高目标，即帮助进行一些监视和身份验证，提供对遗留系统的“更好”访问。在这两种情况下，仅1-2年内，ESB就成为了单点故障、变革的瓶颈，并且通常成为所有项目的障碍

ESB非常方便，不使用它们是不行的。首先，您只需为要发送到某个系统的消息添加一些特殊路由，然后快速解决将一些xml消息转换为另一种格式的问题，因为您可以。然后添加更多的XSLT或其他内容，以便在客户端系统中修复成本过高的版本更新。等等

不久，您将拥有业务逻辑。所有团队都必须与ESB团队协调所有的展开、新消息甚至消息格式的更改。它将扼杀团队的独立性（低耦合）

正如您所指出的，微服务体系结构的要点是，不仅为服务，而且为其团队启用自主操作。这样可以实现快速更改。理想情况下，这意味着：

• 避免与其他团队的任何同步点，无论是测试、推出、配置还是操作（即，您必须进行跨职能和DevOps等）
• 避免在运行时与其他服务同步。这意味着无论采用何种技术，都要避免同步调用。您应该只执行fire and forget，永远不要请求响应，即使响应是在稍后的时间点出现的
• 避免依赖其他团队。这意味着避免代码共享（具有业务逻辑或业务相关对象的代码）

基本上，你应该能够继续运行你的微服务（并推出新版本），即使公司的其他人关闭了他们的微服务并去度假

---

当然，这是一个“理想化”的场景，但ESB肯定与上述所有目标背道而驰。它是一个同步点，在运行时和组织上都是一个集中的依赖关系。

“通信可能是同步的（编排）或基于事件的（编排）”-这不是真的，同步/基于事件与编排/编排正交您的意思是什么？我的意思是，您可以使用基于事件的体系结构进行编排。没有看到任何消息来源说ESB对于基于微服务的体系结构是个坏主意。这个问题在ESB的“坏方面”方面没有任何特别的观点@TuomasToivonen是否有关于特定人物/文章的链接？“非常不鼓励……”：需要引用。