Consul vs Istio

原文：Consul vs Istio

Istio 是一个开源平台，可以为微服务提供连接、管理和加密功能。

要启用 Istio 的全部功能，必须部署多个服务。控制面包括了 Pilot、Mixer 以及 Citadel 这几个必要组件，数据面的 Envoy Sidecar 也是必不可少的。另外 Istio 需要第三方的服务发现支持，例如 Kubernetes、Consul、Eureka 或者其他别的什么。最后 Istio 需要一个外部系统用来进行存储，通常是 ETCD。换句话说，Istio 需要至少三个独立的服务，以及至少一个分布式系统才算完整。

Istio 在七层提供了基于路径的路由、流量整形、负载均衡以及遥测功能。Istio 还基于服务认证功能提供了访问控制的支持，能使用七层和四层的属性对访问、路由进行控制。

Consul 是一个单一的二进制文件，同时提供了服务器和客户端的能力，并自带全部的服务发现、配置、TLS、认证等功能。无需安装额外的系统即可使用，同时还为 Vault 之类的外部系统提供了可选支持，从而进行功能扩展。这一架构让 Consul 能够轻松的安装在任何平台上，也包括物理机。

Consule 是一个基于 Agent 的模型，集群中的每个节点都需要运行一个 Consul 客户端。客户端软件管理一个本地缓存，缓存的数据来源于服务器。无需任何外部通信，所有的加密服务通信 API 都能在几毫秒的时间内进行响应。这样我们的连接过程发生在边缘，无需和中央服务器进行通信。Istio 将请求流入位于中央的 Mixer 服务，而数据的推送过程又必须由 Pilot 完成。这种机制极大的降低了 Istio 的稳定性，而 Consul 却能够在边缘高效的完成数据更新的分发以及其他工作。

Consul 的数据面是可插接的。它包含了一个内置的代理服务器，这一服务牺牲了较多性能，换来易用性的提升。用户也可以使用 Envoy 这样的第三方代理。不同的任务会有各自合适的代理，Consul 就提供了这种能力，从而能够支持复杂多样的应用部署。

除了第三方代理支持，应用可以直接和 Connect 协议进行集成。这样一来，引入 Connect 的开销就可以忽略不计了。任何其他的 Connect 支持的应用，不管使用代理或者 Connect 原生方式，都具备互联互通的能力。

Consul 只在四层实现了认证和鉴权——TLS 连接是否能够建立。我们认为服务认证应该留在四层，七层要做的事情是路由、遥测等事情。我们鼓励用户借助我们的可插接数据面，为集群所需要的七层功能选择合适的代理服务器。Consul 会在未来加入更多七层特性。

Consul 实现了自动的 TLS 认证管理，并且提供了完整的轮转支持。即使是一个大型的 Consul 集群中，也能够在无中断的情况下实现自动轮转。认证管理系统也是可插接的，目前通过代码集成在 Consul 中，很快我们会将其剥离成为外部插件。这就 Consul 就有了和任意 PKI 方案协同工作的能力。

因为 Consul 的服务连接能力（”Connect“）是内置的，他也具备和 Consul 一样的稳定性。2014 年以来，Consule 就在大型企业的生产环境中工作，目前已经有单集群部署 50000 节点的规模。

这一比较基于我们自己对 Istio 的有限认识，以及和 Istio 用户的交流。如果读者认为其中有不实之处，请点击 Edit this page 提交修改建议。我们会尽快对读者意见进行审核和更新，希望以此来保证本文的准确性。