对于研究应用程序架构仍然很陌生，并且难以消化一本关于微服务的书中的一些想法。在我的阅读中，我遇到了 ESB（企业服务总线）的旧概念及其在协调新服务和旧应用程序之间的消息中的作用。 ESB 被吹捧为解决点对点集成问题的解决方案。微服务似乎是新公司采用的方法，作为创建敏捷、可扩展和有弹性的应用程序的事实上的标准。但是微服务不是使用点对点集成吗？从微服务构建的应用程序中的每个节点都直接与其他节点通信，对吗？我觉得我正在连接一些不应该连接的点。非常感谢任何帮助，在此先感谢。
【问题讨论】：
标签： architecture microservices esb
ESB 是许多公司已实施的解决方案，以确保应用程序的互操作性和可追溯性。但是，它们是不允许水平扩展的重型解决方案，通常 ESB 采用两个节点的配置，主动-主动或主动-被动。
另一方面，ESB 中的服务通常不会单独部署，而是与其他服务一起部署在部署包中，这使得交付管理和测试更加复杂。
微服务旨在单独开发和部署，因此在云基础架构内可以轻松横向扩展，动态增加实例数量。
目前，应用程序之间的互操作性已进入后台，因为如今通过 Web 服务进行的通信几乎司空见惯，尽管在一些非常古老的基础架构中可能仍需要一些解决连接问题的中间件。
【讨论】：
微服务不一定严格依赖点对点集成。
与直接通信相关的问题通常在使用消息代理的微服务架构中进行管理。如果通信可以异步完成——“即发即弃”——发送消息的应用程序不会在接收器出现故障时变得无法操作。当接收服务恢复时，消息仍然存在。
如果微服务通过 REST 集成，调用者确实需要知道在其他服务没有响应时如何做出反应。由于在跨系统（即分布式事务）保存数据时这会变得很麻烦，因此我喜欢仅将 REST 用于数据检索 API。并根据消息进行所有保存。
重要的是要注意，ESB 不仅仅是消息传递。 See more on that in the answer here.
【讨论】：
这两种方法都不需要排他性。微服务可以使用消息中间件（kafka、AMQP、Akka actor、JMS...）而不是直接的 http 通道进行通信。这取决于您的约束（主要是一致性）和部署策略。
每个选择都有自己的长处和短处，我个人建议不要将自己局限于一种方法，而是两种方法都使用，并根据情况进行选择
见Microservices: REST vs Messaging和https://capgemini.github.io/architecture/is-rest-best-microservices/
【讨论】：
微服务不能替代 ESB。
微服务 是一个后端系统开发的概念，包括它的API。与微服务方法相反的是单体。如果 API 被消费系统直接消费，我们就来点对点（意大利面条）集成。如果消费者使用中间件，通常称为 API 网关，我们可以拥有集中的可见性、安全性和跟踪（与 ESB 一样）。 API 网关比 ESB 更简单，因此更适合水平扩展。 API 网关不应包含额外的业务/集成逻辑。
ESB 与 API 网关（充当代理）的作用相同，但还允许包含业务逻辑，将多个服务组合成一个和其他高级功能。 ESB 通常会发展成为繁重的解决方案，开销很大，附加值很少，这就是他们被讨厌的原因。
结论
ESB 可以和微服务架构一起使用，有很多公司把 ESB 保持简单，几乎等同于所谓的 API 网关。
我的看法
API 网关正在引入新功能并且变得更加复杂，更接近 ESB。
【讨论】：