在过去，我曾经是IBM Integration Bus（IIB）（当时称为IBM WebSphere Message Broker）的开发人员。我将开发消息流来连接各种输入，输出和处理节点。当然，这种开发风格也适用于其他ESB供应商。因此，这个问题不会失去普遍性。
IIB的消息传递引擎是WebSphere MQ（WMQ），它以队列中的消息形式或作为主题提供通信。节点与IIB中的内部逻辑一起互相通信，传递消息。 典型的IIB / WMQ也具有详细记录的HA安装机制。此外，如果消息流暴露了HTTP（S）端点，它也可以在负载均衡器后面进行暴露。
类似地，人们可以谈论构成SOA时代的其他技术。因此，我的问题是，如果我
那么，除了“基于纯容器的体系结构”之外，我还需要Istio做什么？
答案 0 :(得分：0)
Istio实现了与每个微服务耦合的小车模式。微服务（不一定但通常）部署在允许弹性伸缩的基础架构中，在该基础架构中，委派了系统以配置的伸缩策略为基础来调整每个微服务的实例数的任务。这意味着在任何给定的时刻，容器的数量是可以预测的，而短期内却是未知的。
Istio解决了将微服务从纯粹的基础结构任务中抽象出来并使它们仅专注于功能平面的问题，同时它能够与它所连接的容器一起弹性伸缩。
将这项任务委派给ESB并非没有可能，但是我认为这会引入相当高的复杂性因素。也许您已经找到了商机；-）
答案 1 :(得分：0)
IIB以前具有整体架构，因此提供的与IIB相关的链接将有助于创建高可用性架构。 ESB（任何供应商）的最新产品是将ESB部署为微服务。具体而言，对于IIB，我们可以将每个执行组（集成服务器）作为容器运行。有了它，您将拥有微服务架构的各种优势。当然，如上所述，您也可以使用这些ESB微服务进行编排。
但是对于任何在其各种应用程序中具有基于微服务的体系结构的企业，而不仅仅是将ESB作为容器的企业，都很难管理，保护，观察等。特别是当微服务随着企业中成千上万的运行而持续增长时。这就是Istio可以提供帮助的地方。
答案 2 :(得分：0)
TLDR的答案是istio更灵活，并且不试图使微服务完全依赖于istio，而IIB堆栈主要是“一旦进入，就没有迁移项目就无法退出”。 >