ESB 是 SOA 解决方案中用于路由、消息转换、协议桥接等的传统中间件。现在有几家供应商提供了一种称为 API 网关的新型中间件解决方案。这些解决方案通常被描述为访问组织公开提供的 REST 和 SOAP 服务的中心点。但是，API Gateway 解决方案似乎提供了典型 ESB 功能的一个子集。
那么，ESB 和 API Gateway 有什么区别呢？我什么时候应该使用其中一种？
问问题
34493 次
6 回答
15
API 网关是为客户端提供的代理。无论内部系统发生任何变化，网关都会为客户端提供一致的接口。它允许在不影响客户端的情况下更改内部系统。API 网关还可以提供一致的横切关注点，例如安全日志记录、报告和 API 分析。
ESB（企业服务总线）提供了一种服务到服务通信的方法。使用这种技术，服务不需要相互通信，减少了耦合。ESB 通常使用有保证的消息传递来进行服务间通信。
如今，Service Mesh 模式已经在微服务中流行起来。Service Mesh 实现可以提供 API 网关和服务到服务的通信，以及负载平衡、安全性和许多其他功能。
有很多变体和实现细节，但这是高级别的区别。
于 2019-04-23T21:01:45.077 回答
6
两者都可以执行服务的中介和聚合。主要区别在于API网关暴露了一组服务来消费，并负责代理服务的一些其他功能；比如限速。
另一方面，ESB 提供双向关系，因此提供者和消费者（服务）都可以参与以获得所需的结果。换句话说，ESB 允许计算实体既是服务又是运行中的消费者。API-gateway 将服务限制为具有单一行为。
于 2020-05-09T12:31:11.907 回答
6
API 网关通常充当 Web 服务的代理并提供有趣的价值，例如：日志记录、使 SOAP 服务像 REST 服务一样可调用、调试帮助、跟踪等……因为 API 网关介于两者之间消费者和您的服务，它可以轻松捕获流量并执行此类操作。
企业服务总线（如 nServiceBus）被设计为位于消息传递协议（如 RabbitMQ）之上，为它提供基本消息传递或发布订阅所不具备的功能（或难以实现的功能），例如：数据库存储的持久消息、重试逻辑、侦听器封装、更简单的消息订阅方式和 sagas。您可以在不使用 ESB 的情况下使用消息传递协议，但反之则不行。例如，您可以在不使用nServiceBus的情况下使用RabbitMQ。
于 2016-01-26T14:41:50.733 回答
4
由于 API 网关和 ESB 都能够为服务代理提供服务，因此如果只考虑这两种工具的中介和转换功能，它们可能看起来是相同的。对我来说，API 网关的主要区别在于它的特定目的。API 网关除了提供转换和一些路由功能外，还应该能够充当其前面的资源的入口点。此外，他们应该能够将访问控制和限制方面委托给其他专门的组件，利用它们应该能够保证所需的行为。由于 API 网关将作为 API 管理解决方案的一部分，所有这些功能都将支持 OOTB。
使用 ESB 和其他外部组件或软件可能会为服务代理实现类似的行为。但是，由于 ESB 旨在用于满足更广泛的集成需求，并且不是专门用于 API 管理用例，因此实现它们将更加困难。
于 2017-05-03T06:34:23.863 回答
0
阅读这些意见很有趣。不幸的是，它们中的大多数反映作者熟悉 API 网关而不熟悉 ESB。
ESB 提供的 VERTOS，它解决...
> 验证
> 增强
> 路由
> 转换
> 操作监控
> 安全映射
AWS API Gateway 功能是 Oracle SOA Suite 的 12c ESB 等提供的功能的一个子集。一般来说，不同之处在于 SOA Suite 的功能 (VERTOS) 集成度非常好，而 API Gateway 已将其中一些功能拆分为单独的模块。因此，您有时必须自己将其中一些模块粘合在一起，才能获得与 SOA Suite 提供的 OOTB 相同级别的功能。
我会选择 SOA 套件而不是 API 网关吗？没有。AWS API Gateway 在与整个 AWS 开发技术堆栈集成方面提供的优势使其成为现代系统的正确选择。
于 2022-02-24T18:59:05.113 回答
0
我同意其他答案，但我想补充一点，一个非常重要的区别是网关不应该包含任何业务逻辑。
它们都在验证、转换和路由等服务之间做一些中介，但例如在网关验证的情况下，应该只验证数据的格式。
另外，我认为 ESB 可以让我更多地了解来自多个服务的数据的聚合，并且如果不引入业务逻辑就很难进行任何聚合。
于 2020-05-09T11:57:53.370 回答