如何比较Istio和Docker Swarm？
阅读有关Istio的文档我带着这个问题来。
Istio和Docker Swarm的工作原理是一样的？
另外，在不同的情况下哪个更好？
这是一个苹果比较在许多方面的橙子。 Istio（现在）运行在像Docker Swarm这样的容器pipe理员Kubernetes 之上 。
诚然，Istio和Docker Swarm的描述都提到了“服务网格”这个术语。
然而，Docker Swarm中的服务网格与Kubernetes中的服务模型更相似，两个协调器通常都可以比较每个人拥有的大多数function。 在这两个协调人的服务路由只涉及networking层，并没有例如HTTP协议的可见性。
请注意，Kubernetes Ingress API应单独考虑，它实际上位于服务模型之上，实际上是由外部控制器（如Traefik或HAProxy）实现的，实际上Istio带来了另一个入口控制器的实现。
虽然Istio比pipe弦乐队高了一级，但现在它只能在Kubernetes上运行，但它很可能在将来支持Docker Swarm和其他stream行的pipe弦乐队。
更具体地说，Istio的服务网格比Docker Swarm提供的服务网格（以及类比，Kubernetes Services提供的服务）要先进得多，例如它可以实现故障注入，以及透明的TLS等众多function。
Docker引擎群集模式可以轻松发布服务端口，使其可以在群集外的资源上使用。 所有节点都参与入口路由网格。 路由网格使群体中的每个节点都可以接受群集中运行的任何服务的已发布端口上的连接，即使节点上没有运行任何任务。 路由网格将所有传入请求路由到可用节点上的已发布端口以激活容器。
Istio是一个连接，pipe理和保护服务的开放式平台。 本质上，它是一个开放的服务网格，我们希望开发人员和操作人员不必担心如何连接服务，如何考虑如何使它们具有弹性，如何保护它们以及如何pipe理运行时。 我们希望Istio能够为所有环境和云环境中的开发人员和运营商做到这一点。 而且，当我说services真的是各种服务不一定是微观的。 它可能就像你正在build立MySQL API服务一样，这是你的应用程序中的一个非常小的微服务，可以用任何语言进行付款或购物。 所以，istio采取了与polygot环境一起工作的方法。 您知道，不pipe您使用哪种语言编写服务和部署，Istio都希望在应用程序和networking之间为您提供统一的基础架构，从而可以充分利用服务之间的连接性和服务之间的弹性。 因此，弹性包括重试，故障转移，所有好东西以及保证服务的分布式系统等。 我们认为，内部服务应该像外部一样安全，所以默认安全。 而且，在所有服务中，从L3到L7都具有完整的可观测度和可见度。
基本上想一下层（有人称之为L5），它基本上是你的应用程序和networking之间的一个层。 而且，当你考虑这个问题时，你基本上正在创build，我们正在为每个服务旁边注入一个代理。 而且，那些处于所有服务到服务通信的数据path中。 它们都是互联的，也连接到一个共同的控制平面。 而且，与每个服务相邻的代理服务器的相互关联的集合通常被称为Service Mesh （ Service Mesh其原因如此有趣的是，一旦将网格看作像networking一样存在的层，您可以应用程序层可以减轻连接性，弹性，对该层的可见性。 所以，历史上你可以在任何一个应用程序库中这样做，就好像你正在用java，python构build，或者在这些语言中可以导入一大堆库，然后在其中编写一个逻辑。 或者你可以做三层安全和政策，如IP白名单，防火墙规则设置，VPNnetworking，VPN对等等。 所以，我们认为服务网格是两者之间的一个空间，它可以从L7中减less一些东西，并给予策略驱动的合约来操作你的networking。 所以，Istio服务网格比Docker Swarm服务网格要好得多。