在微服务架构中，自治业务服务应该直接相互通信。通信可以是同步（编排）或基于事件（编排）。 API网关可以聚合客户端的API（前端的后端）。通过微服务，我们正在寻求两个最终目标
这使得持续部署，细粒度扩展，快速技术适应，可重用性，可审计性更高，当然还有更高复杂性的价格。
但是，强烈建议不要使用ESB（企业服务总线）或其他中间件。微服务和ESB通常被视为竞争对手的解决方案。为什么ESB看起来如此糟糕？只要它仅用作具有一些额外监视和认证层（没有业务逻辑）的冥想通道，在微服务架构中使用它有什么问题？
答案 0 :(得分：18)
我见证了两个ESB在不同公司的推出，在这两种情况下都有相同的崇高目标，只是帮助进行一些监控和认证，提供更好的＆＃34;访问遗留系统。在这两种情况下，仅仅1 - 2年，ESB就成为单点故障，成为变革的瓶颈，并且通常是所有项目的障碍。
ESB太方便不使用它们。首先，您只需为要发送到某个系统的消息添加一些特殊路由，然后您就可以快速解决将某些xml消息转换为其他格式的问题，因为您可以。然后，您需要添加更多XSLT或其他任何内容，以便在客户端系统中修复太昂贵的版本更新。等等...
不久之后，将在那里拥有业务逻辑。所有团队都必须与ESB团队协调所有部署，新消息甚至消息格式的更改。 会扼杀你团队的独立性（低耦合）。
正如您所指出的，微服务架构的目的是启用自主操作，不仅针对服务，还针对其团队 。这样可以快速更改。理想情况下，这意味着：
基本上，你应该能够继续操作你的微服务（并推出新版本），即使公司的其他人关闭他们并去休假。
当然，这是一个理想化的＆＃34;场景，但ESB绝对违背了上述所有目标。它是一个同步点，是运行时和组织上的集中依赖。