服务网格与 2010 年 ESB 解决方案(例如 IBM IIB 或 Oracle ESB)有何不同

cog*_*sum 5 soa containers esb istio

过去,我曾经是一名 IBM Integration Bus (IIB)(当时称为 IBM WebSphere Message Broker)开发人员。我将开发消息流来连接各种输入、输出和处理节点。当然,这种开发风格也适用于其他 ESB 供应商;所以,这个问题不失一般性。

IIB 的消息传递引擎是 WebSphere MQ (WMQ),它以队列消息或主题的形式提供通信。与 IIB 中的内部逻辑一起,节点之间通过消息进行通信。典型的 IIB/WMQ 也有详细记录的 HA 安装机制。此外,如果消息流公开 HTTP(S) 端点,它也可以在负载均衡器后面这样做。

同样,我们还可以谈论构成 SOA 时代的其他技术。因此,我的问题是,如果我

  • 开发与 WMQ 等通信的微服务
  • 将每个微服务部署到容器中
  • 使用 ESB 来编排这些微服务
  • 依赖 ESB(及其辅助技术)进行访问控制、流量管理等。

那么,除了“基于纯容器的架构”之外,我还需要 Istio 做什么?

https://developer.ibm.com/integration/blog/2014/07/02/ibm-integration-bus-high-availability-overview/

https://developer.ibm.com/integration/docs/ibm-integration-bus/learn-play/an-introduction-to-ibm-integration-bus/

jmh*_*let 2

Istio 实现了 sidecar 模式来耦合到每个微服务。微服务(不一定但通常)部署在允许弹性扩展的基础设施中,其中系统被委托负责根据配置的扩展策略调整每个微服务的实例数量。这意味着任何给定时刻的集装箱数量都是可预测的,同时在短期内是未知的。

Istio 解决了将微服务从纯粹的基础设施任务中抽象出来并让它们仅关注功能平面的问题,同时它能够与其所附加的容器一起弹性扩展。

将这项任务委托给 ESB 并非不可能,但我认为这会带来相当高的复杂性因素。也许您已经找到了商机;-)