Istio的原理、架构和组件介绍

一、什么是Istio

“Istio, an open platform to connect, secure, control and observe services.”，中文翻译是“连接、安全加固、控制和观察服务的开放平台”。

Istio 的主要功能：

· 连接（Connect）：智能控制服务之间的调用流量，能够实现灰度升级、AB 测试和红黑部署等功能。

· 安全加固（Secure）：自动为服务之间的调用提供认证、授权和加密。

· 控制（Control）：应用用户定义的 policy，保证资源在消费者中公平分配。

· 观察（Observe）：查看服务运行期间的各种数据，比如日志、监控和 tracing，了解服务的运行情况。

服务网格（Service Mesh）这个术语通常用于描述构成这些应用程序的微服务网络以及应用之间的交互。随着规模和复杂性的增长，服务网格越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求，例如 A/B 测试、金丝雀发布、限流、访问控制和端到端认证等。Istio 提供了一个完整的解决方案，通过为整个服务网格提供行为洞察和操作控制来满足微服务应用程序的多样化需求。

Istio针对现有的服务网络，提供一种简单的方式将连接、安全、控制和观测的模块，与应用程序或服务隔离开来，从而开发人员可以将更多的精力放在核心的业务逻辑上，以下是Istio的核心功能概述：

· HTTP、gRPC、WebSocket 和 TCP 流量的自动负载均衡。

· 通过丰富的路由规则、重试、故障转移和故障注入，可以对流量行为进行细粒度控制。

· 可插入的策略层和配置 API，支持访问控制、速率限制和配额。
· 对出入集群入口和出口中所有流量的自动度量指标、日志记录和追踪。
· 通过强大的基于身份的验证和授权，在集群中实现安全的服务间通信。

二、架构和原理

上面是官方给的架构图，核心组件有：Proxy代理、Mixer混合器、Pilot引导、Citadel堡垒，以及Galley。

1、Proxy代理

Istio的核心原理，是网络代理，拦截下所有想拦截的流量，然后想干啥就干啥吧。
Istio使用的代理组件是Lyft团队的Envoy，一个C++开发的高性能代理。这是Lyft在Istio项目里的唯一贡献，却让Lyft排在跟Google/IBM并列的位置，可想而知Envoy对Istio的重要性。

Envoy之所以有能力拦截下所有的流量，是因为它被设计为部署在每一个需要管理的Pod里，作为一个独立容器存在，支持通过配置iptables或cni网桥两种方式来拦截流量（这里也不展开说了，还不明白的同学可以翻看我之前发的k8s底层网络的说明，看看Flannel的实现原理），请看上图，Business-manager容器的请求发出时，会经过本Pod的Enovy代理，Enovy完成规则校验、数据采集、日志等操作后，再转发出去；值得注意的是，请求方Enovy转发出去的流量会发送给接收方的Enovy，之后才有可能到达真正的接收方data-product容器。当然这些操作是Istio的活，我们要做的仅仅是通过配置的形式告诉Istio我们要对哪些流量做什么动作。

通过对拦截下来的流量的解析和修改（是的，理论上什么都能干，包括修改甚至丢弃流量），Envoy包括但不限于以下功能：

· 动态服务发现
· 负载均衡
· TLS 终止
· HTTP/2 & gRPC 代理
· 熔断器
· 健康检查、基于百分比流量拆分的灰度发布
· 故障注入
· 丰富的度量指标

2、Mixer混合器

顾名思义，Mixer混合了各种策略以及后端数据采集或遥测系统的适配器，从而实现了前端Proxy与后端系统的隔离与汇合。Mixer是一个灵活的插件模型（有没有发现无论是k8s还是Istio，实现上都很青睐于插件模型，这是一个很灵活的实现方式），它一端连着Envoy，同时我们可以将日志、监控、遥测等各种系统“插入”到Mixer的另一端中，从而得到我们想要的数据或结果。

我们来看下官方的Mixer拓扑图，Mixer被设计为一个独立运行的模块，它可以“插入”logging日志、quota指标、auth安全认证、Tele遥测等很多模块。每插入一个模块都会在前端生成一个规则过滤器。前端的Enovy在每次流量到来时，都会请求Mixer，匹配每一个过滤器。

这就涉及到性能问题了，所以Istio在这个拓扑下设计了一个二级缓存系统。Envoy端在每个Pod里有一个一级缓存，当然这个缓存不能太大；Mixer端会有一个二级缓存，由于Mixer是独立运行的，所以这个缓存可以设计的比较大。这样Envoy可以预先缓存一部分规则，只有当规则缺失时才需要向Mixer请求，这就减少了每次流量到来的网络请求次数；另一方面，日志等数据上送，也是异步执行的，先经过一级缓存、二级缓存再到达后端存储或处理系统。

3、Pilot引导

简单来说，Pilot是为我们提供配置智能路由（如A/B测试、金丝雀发布等）、弹性（超时、重发、熔断等）等功能的管理系统，它提供了一系列rules api，允许运维人员指定一系列高级的流量管理规则。Pilot负责将我们的配置转换并写入到每个sidecar（Enovy）。

4、Citadel堡垒

这个名字也很有意思，它管理着集群的密钥和证书，是集群的安全部门。典型的如果我们的服务是跨网络通讯（Istio允许我们建立一个安全的集群的集群网络），开发人员想省事懒得对通讯数据进行加解密和身份认证，这事就可以交给Citadel来处理了。更详细的说，Istio各个模块在安全性上分别扮演以下角色：

· Citadel，用于密钥和证书管理

· Sidecar和周边代理，实现客户端和服务器之间的安全通信

· Pilot，将授权策略和安全命名信息分发给代理

· Mixer，管理授权和审计

5、Galley

这个不知道咋翻译，目前这个组件的作用是验证用户编写的Istio api配置。从官网的说法来看，后面这个组件会逐步接管获取配置、处理和分配的工作，比如从k8s的数据中心（etcd）获取集群信息的活，理论上应该交给Galley干。从这个信息来看，Galley的定位应该类似于k8s的api server组件，提供集群内统一的配置信息接口，从而将用户配置的细节隔离开来。

三、功能列表

以下是从官网各项示例中整理出来的Istio所支持的功能列表：

四、性能评估

官方给出了对最新版本V1.1.4的性能测试结果。在由1000个服务和2000个sidecar组成，每秒产生70000个网格范围内的请求的网格中，得到以下结果：

· Envoy在每秒处理 1000 请求的情况下，使用 0.6 个 vCPU 以及 50 MB 的内存。

· istio-telemetry在每秒1000个网格范围内的请求的情况下，消耗了0.6个vCPU。

· Pilot使用了 1 个 vCPU 以及 1.5 GB 的内存。

· Envoy在第 90 个百分位上增加了 8 毫秒的延迟。

四、优劣比较

1、Isito服务网格的优势

伴随着微服务不断的发展，Istio服务网格的使用场景越来越多，通过Istio服务网格的接入，解决了下述各种问题。

（1）随着公司业务的不断发展，公司内部原有大量的Web应用，在不想改造代码的前提下，想加入服务化大家庭，享受各种服务治理的能力。

（2）随着新技术的不断涌现，加上公司业务的快速发展，公司内部不同的业务系统会根据不同的场景选择不同的语言进行业务开发，例如Node.js, Go等等。不同的语言都需要接入服务化大家庭，享受各种服务治理的能力。

（3）随着业务的发展，微服务架构必然需要不断的升级，基于Istio架构的微服务，业务系统和微服务架构是解耦的，所以在微服务架构升级时，业务部门不需要做任何修正，从而减轻了业务部门的工作量。

（4）Istio在Pilot配置路由规则，然后将路由规则下发至Envoy，Envoy根据路由规则，可以在不修改应用程序的前提下实现应用的灰度发布，熔断，扩缩容，注入故障等功能。从而减轻了开发和运维的工作量。

（5）Istio通过Mixer的配置，可以在不修改应用的前提下，为服务添加白名单，ACL的检查，从而控制服务的访问。

（6）Istio的Citadel通过内置身份和证书管理，来保护服务之间的所有通信安全性，而不会对开发人员造成麻烦的证书管理负担。

Istio服务网格作为一个基础设施层，将微服务的治理完全从业务系统中独立出来了，业务开发人员从此可以完全的专注于业务系统的开发，不需要考虑微服务治理等方面的问题，极大的提高了业务开发人员的生产效率。同时由于Istio作为一个基础设施层，轻量级高性能网络代理，对应用透明，运维人员可以依靠统一的规则进行维护，从而也极大的提高了运维人员的生产效率。同时也降低了业务开发人员与运维人员的沟通成本。

2、Isito服务网格的不足

虽然istio 降低了应用服务与服务治理之间的耦合度，让用户能够将主要精力放在具体的业务功能实现上，而不需要过多的考虑服务治理(如流量控制、负载均衡、故障处理等)方面的问题，提高了开发效率，并且Istio通过高度的抽象和良好的设计采用一致的方式解决了灰度发布的问题，通过Pilot下发路由，然后Envoy对流量进行了转发，极大的提高了运维的生产性。

但是Istio还是存在一个极大的痛点，即高并发访问时吞吐量不能够达到大促的需求。利用上图的模型对Istio进行了压力测试，来验证Istio的吞吐量和稳定性。在高并发的情况下Istio顶住了压力，***的保证了访问的正确性，没有发生任何丢包，请求失败，路由混乱的错误。

但是Istio吞吐量并不是很理想，服务间以HTTP 方式访问时吞吐量尤其低下，服务间以GRPC 方式访问时性能虽有提升，但是还是不能够完全满足大促期间的高并发量的要求。Istio 在微服务治理方面所展现的功能特性和灵活性使得Istio的魅力格外亮眼。相信在不久的将来，Istio 在吞吐量上的痛点能够得到突破，达到大促的需求。