服务网格与2010年的ESB解决方案（如IBM IIB或Oracle ESB）有何不同？

Question

在过去，我曾经是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/

- cogitoergosum

Answer 1

Istio实现了side-car模式，与每个微服务耦合。这些微服务（不一定但通常）部署在允许弹性扩展的基础架构中，系统根据配置的扩展策略调整每个微服务实例的数量。这意味着任何时刻容器数量是可预测的，同时在短期内是未知的。

Istio解决了将微服务从纯基础设施任务中抽象出来，使它们仅关注功能层面的问题，并且与其附加的容器一起弹性地扩展。

将此任务委托给ESB并非不可能，但在我的观点中，这会引入相当高的复杂性因素。也许你已经找到了一个商业机会;-)

原始答案: "最初的回答"

- jmhostalet

Answer 2

IIB之前采用的是单片式架构，您提供的IIB相关链接将有助于创建高可用性架构。最近ESB（任何供应商）的新产品是将ESB部署为微服务。特别是对于IIB而言，我们可以将每个执行组（集成服务器）作为一个容器来运行。这样，您就可以获得微服务架构的各种优势。当然，正如提到的那样，您也可以使用这些ESB微服务来进行编排。

但是对于任何企业来说，如果其各种应用程序都基于微服务架构而不仅仅是ESB容器，那么管理、安全、观测等方面将非常困难，尤其是当微服务数量不断增长，达到数千个在企业中同时运行时。这就是Istio发挥作用的地方。

https://istio.io/docs/concepts/what-is-istio/

- Rohan

---

使用IIB执行组作为容器，谁来进行编排？是IIB本身吗？ - cogitoergosum

是的，IIB将继续执行其所做的操作，只是运行方式发生了变化，它不再作为一个大型单体运行，而是作为微服务运行。以下是更多详细信息链接: https://developer.ibm.com/integration/blog/2018/01/12/iib-mq-micro-services-builder-ibm-cloud-private/ - Rohan

Answer 3

TLDR的答案是，Istio更加灵活，并且不会试图让微服务完全依赖于istio，而IIB堆栈大多是“一旦进入，就不能在没有迁移项目的情况下退出”。

- Raul Lapeira Herrero