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

Question

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

Answer 1

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

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

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

目前，应用程序之间的互操作性已经进入后台，因为今天的Web服务通信几乎是司空见惯的，尽管在一些非常古老的基础架构中仍然可能需要一些解决连接的中间件。

Answer 2

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

与直接通信相关的问题通常使用消息代理在微服务架构中进行管理。如果可以异步进行沟通 - ＆＃34;火灾和忘记＆＃34; - 如果接收器发生故障，发送消息的应用程序不会无法运行。当接收服务恢复时，消息仍然存在。

如果微服务通过REST集成，则调用者确实需要知道如果其他服务没有响应则如何做出反应。由于当您跨系统保存数据（即分布式事务）时，这会变得毛茸茸，我喜欢仅将REST用于数据检索API。并且根据消息进行所有保存。

值得注意的是，ESB不仅仅是消息传递，还有很多其他功能。 See more on that in the answer here

Answer 3

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

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

请参阅Microservices: REST vs Messaging和https://capgemini.github.io/architecture/is-rest-best-microservices/

Answer 4

微服务不能替代ESB。

<强>微服务 是后端系统开发的概念，包括它的API。与微服务方法相反的是整体结构。如果API由消费系统直接使用，我们就会进行点对点（意大利面条）集成。如果消费者使用通常称为API网关的中间件，我们可以拥有集中的可见性，安全性和跟踪（与ESB一样）。 API网关比ESB更简单，因此更适合水平扩展。 API网关不应包含其他业务/集成逻辑。

ESB 与API网关（充当代理）相同，但此外还允许包含业务逻辑，将多个服务组合成一个和其他高级功能。 ESB经常变成繁琐的解决方案，开销很大，只有很少的附加价值，这就是为什么它们变得讨厌。

<强>结论

ESB可以与微服务架构一起使用，有许多公司保持ESB简单，几乎等同于所谓的API网关。

我的意见

API网关正在引入新的功能，并且越来越复杂，越来越接近ESB。