对ESB作为点对点集成的解决方案感到困惑

Question

对于研究应用程序架构仍然很陌生，并且在一本关于微服务的书中很难接受一些想法。在我的阅读中，我遇到了ESB（企业服务总线）的旧思想及其在新服务和遗留应用程序之间协调消息的作用。ESB 被吹捧为点对点集成带来的问题的解决方案。微服务似乎是新公司采取的方法，作为创建敏捷、可扩展和弹性应用程序的事实标准。但是微服务不是使用点对点集成吗？从微服务构建的应用程序中的每个节点都直接与其他节点通信，对吗？我觉得我正在连接一些不应该连接的点。非常感谢任何帮助，提前感谢。

Answer 1

这两种方法都不是必要的排他性。微服务可以使用消息中间件（kafka、AMQP、Akka actor、JMS…）而不是直接的http通道进行通信。这取决于您的约束（主要是一致性）和部署策略。

每个选择都有他的优点和缺点，我个人建议不要将自己局限于一种方法，而是同时使用两种方法并根据每种情况进行选择

请参阅微服务：REST与消息和https://capgemini.github.io/architecture/is-rest-best-microservices/

Answer 2

微服务不一定严格依赖点对点集成。

与直接通信相关的问题通常使用消息代理在微服务体系结构中进行管理。如果通信可以异步完成 - “即发即弃” - 则发送消息的应用程序在接收器关闭时不会变得无法运行。当接收服务恢复时，消息仍将存在。

如果微服务在REST上集成，那么调用者需要知道如果其他服务没有响应，该如何反应。由于当您跨系统保存数据（即分布式事务）时，这会变得很麻烦，所以我只喜欢将REST用于数据检索API。并根据消息进行所有保存。

重要的是要注意，ESB不仅仅是消息传递，还有很多其他功能。在这里的答案中查看更多信息。

Answer 3

ESB是许多公司已经实施的解决方案，以确保应用程序的互操作性和可追溯性。然而，它们是不允许水平扩展的重型解决方案，通常ESB采用两个节点的配置，主动-主动或主动-被动。

另一方面，ESB中的服务通常不是单独部署的，而是与其他服务一起部署在部署包中，这使得交付管理和测试更加复杂。

微服务旨在单独开发和部署，因此在云基础架构中可以轻松地横向扩展，动态增加实例数量。

应用程序之间的互操作性目前已经进入了后台，因为今天通过web服务的通信实际上已经很普遍了，尽管在一些非常旧的基础设施中可能仍然需要一些解决连接性的中间件。