为什么 ESB 在微服务架构中被认为不好 [关闭]

Question

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

• 低耦合
• 高凝聚力

这使得持续部署、细粒度扩展、快速技术适应、可重用性、可审计性等更多，当然以更高的复杂性为代价。

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

Answer 1

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

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

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

正如您所指出的，微服务架构的重点是启用自主操作，不仅适用于服务，也适用于其团队。这可以实现快速更改。理想情况下，这意味着：

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

基本上，即使公司其他人关闭并休假，您也应该能够继续运行您的微服务（并推出新版本）。

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