architecture - 为什么 ESB 在微服务架构中被认为不好

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.

4年前关闭。




Improve this question




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

低耦合

高凝聚力

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

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

Answer 1

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

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

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

正如您所指出的，微服务架构的重点是启用 自主运营不只是为了服务，而是也为其团队 .这可以实现快速更改。理想情况下，这意味着:

避免与其他团队的任何同步点，无论是用于测试、推出、配置还是操作(即您必须跨职能并进行 DevOps 等)

避免与其他服务同步点运行时。这意味着无论技术如何都要避免同步调用。你应该只做即发即弃，永远不要请求响应，即使响应在稍后的时间点出现。

避免依赖其他团队。这意味着避免代码共享(具有业务逻辑或业务相关对象的代码)

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

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