服务网格：Istio 架构

什么是服务网格

---

服务网格(Service Mesh)这个术语通常用于描述构成这些应用程序的微服务网络以及应用之间的交互。随着规模和复杂性的增长，服务网格越来越难以理解和管理。

它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求，例如A/B测试、金丝雀发布、限流、访问控制和端到端认证等。

每一个方框就是一个pod，绿色的部分就是应用代码，蓝色部分就是sidecar。

这样应用之间的服务调用就变成了sidecar和sidecar之间调用的一个网。所谓的mesh就是sidecar的这种网络调用使得整个平台变成了一个网状结构。

服务网格有多样的能力，服务发现，负载均衡，故障恢复等等。

为什么要使用Istio?

---

• HTTP、gRPC、WebSocket和TCP流量的自动负载均衡。（像基于内核能力的负载均衡，它是工作在四层的，我们只能通过五元组去做负载均衡。有些协议grpc协议，它是基于长连接的服务，一个客户端要访问后端服务，这个协议是基于http2的，http2是连接复用的协议，客户端和服务器发起了一个连接，这个连接就不会断掉，后面的连接会基于之前的tcp连接继续去发。基于这种场景，客户端和服务端产生了一个连接，这个连接就会一直保持，如果后端服务器有3个，基于hhtp2，客户端发起请求，一旦和和后端的服务器建立好了连接，它就再也不断了，然后所有的请求都会被发送到后端服务器去。这样很难做到负载均衡，这样永远都有两个空闲的，一个在处理请求，所以这样的话基于内核的这种tcp协议的负载均衡无法满足这种诉求，所以有了istio，istio是一个应用软件，它里面可以跑grpc协议，它可以先将grpc协议接下来然后再去做负载均衡，所以对于高级应用协议的负载均衡可以通过istio去做了）
• 通过丰富的路由规则、重试、故障转移和故障注入，可以对流量行为进行细粒度控制。（有了应用的能力，istio是控制面。反向代理软件envoy，sidecar里面跑的进程叫做envoy，envoy本身是应用进程，应用进程就可以有很多的高级能力和故障处理的能力，因为加任何的能力不需要修改内核而是修改应用代码就行了，所以它就可以进行很多的细流量的控制）
• 可插入的策略层和配置API,支持访问控制、速率限制和配额。（envoy是可以提供灵活的插件的，访问控制和速率的配置，这样就可以提供插件化去做灵活的扩展）
• 对出入集群入口和出口中所有流量的自动度量指标、日志记录和跟踪。（这些都可以通过envoy去做统一汇报，基于服务网格可以去做安全保障，包括认证和鉴权）
• 通过强大的基于身份的验证和授权，在集群中实现安全的服务间通信。

Istio功能概览

---

 在说服务网格的时候，它不仅仅是在谈服务网格自身，要去做高级的流量管理不仅仅是集群内部的，还要涉及到外面的客户端的流量如何进来。

它就是涉及到了ingress流量，外面的流量进来之后，集群内部的微服务跳转，就是服务和服务之间的调用，还涉及到内部的服务调用外部的服务可以通过统一的对外代理出去访问，这个叫做egress gateway。

虽然说他是服务网格，但是它解决的是入栈的流量，服务网格的流量，和出栈流量的统一管控。

这样就将所有流量的管控都统一起来了。

k8之前提供ingress对象来帮你做入栈流量管理，但是ingress有许许多多的限制，这些限制基于istio都能够帮你实现，所以你即使做入栈流量的接入，只做这一点也能够完全满足你的诉求。

istio是一个集成了入栈流量，mesh流量，出栈流量统一管控的一个组合。

流量管理

---

istio基于简单的配置就可以做精细化的流量管理。基于精细化的流量管理可以去做A/B测试，金丝雀部署等等这些支持业务场景。

连接

·通过简单的规则配置和流量路由，可以控制服务之间的流量和API调用。Istio简化了断路器、超时和重试等服务级别属性的配置，并且可以轻松设置A/B测试、金丝雀部署和基于百分比的流量分割的分阶段部署等重要任务。

控制

·通过更好地了解流量和开箱即用的故障恢复功能，可以在问题出现之前先发现问题，使调用更可靠，并且使您的网络更加强大——无论您面临什么条件。

可以真实的了解流量的走向，一些开箱即用的故障恢复来帮你管控流量。

安全

---

现在的架构不应该只在集群的边界去做加固，而是你要去做假设整个集群都是不安全的，所以任何应用提供服务的时候都需要去做安全加固，认证鉴权加密传输。istio就天然有这种能力，它允许去做协议的升级，允许基于tls协议去做身份验证，去做鉴权。

·使开发人员可以专注于应用程序级别的安全性。Istio提供底层安全通信信道，并大规模管理服务通信的认证、授权和加密。使用Istio,服务通信在默认情况下是安全的，它允许跨多种协议和运行时一致地实施策略——所有这些都很少或根本不需要应用程序更改。

●虽然Istio与平台无关，但将其与Kubernetes(或基础架构)网络策略结合使用，其优势会更大，包括在网络和应用层保护Pod间或服务间通信的能力。

可观察性

---

Istio生成以下类型的遥测数据，以提供对整个服务网格的可观察性：

• 指标：Istio基于4个监控的黄金标识(延迟、流量、错误、饱和)生成了一系列服务指标。Istio还为网格控制平面提供了更详细的指标。除此以外还提供了一组默认的基于这些指标的网格监控仪表板。
• 分布式追踪：Istio为每个服务生成分布式追踪span,运维人员可以理解网格内服务的依赖和调用流程。
• 访问日志：当流量流入网格中的服务时，Istio可以生成每个请求的完整记录，包括源和目标的元数据。此信息使运维人员能够将服务行为的审查控制到单个工作负载实例的级别。

所有这些功能可以更有效地设置、监控和实施服务上的SLO,快速有效地检测和修复问题。

入栈流量，出栈流量，mesh流量都经过sidecar，所有的sidecar都知道整个集群的网络流量是怎么走的，包括延迟错误码，源目标端口 ip这些信息都能够拿到，这样就可以很清晰的抓到当前集群之间服务不同之间的调用关系，流量调用的健康状况，错误码的分布情况，就有一个非常清晰的视图能够看到整个集群的健康状态。

Istio架构演进

---

数据平面

• 由一组以Sidecar方式部署的智能代理(Envoy)组成。这些代理可以调节和控制微服务及Mixer之间所有的网络通信。（istio本身的数据面是反向代理软件叫做envoy）

控制平面

• 负责管理和配置代理来路由流量。此外控制平面配置Mixer以实施策略和收集遥测数据。（istio往往由数据面和控制平面的一个组合，envoy是数据面，istio是数据面）

架构演进

• 从微服务回归单体（istio本身的架构做过重大的调整，这个调整是由分布式架构变回了一个单体架构，早期的istio会将功能划分为三个大的模块，第一个就是流量治理模块，由piolt模块去完成的。第二个模块是由telemetry和policy就是策略管控和状态监控，这两个能力，这两个能力是放在muxer里面。最后一个就是和安全相关的封装在citadel里面，早期部署的时候istio里面就有很多的组件，除了这些组件还要其他的一些pod，整个应用拉起来就有十来个pod，每个组件都有单一的职责，这些组件在逻辑上依赖也不是这么强，各司其职是一个完美的架构，这个架构在后期遇到了一些状况，比如要去做版本的变更，这个就要考虑先升级谁后升级谁，出现了问题还要去排错，这个问题可能出现在pliot mixer citadel里面，这个排错会变得相当的困难。随着这个架构体系往后面走就遇到了一些卡点，在升级的时候很难去做无损升级，在排查的时候有很多的困难。虽然将这些组件分离开来了，但是我们后续发现后续这些组件的生命周期好像是一样的，其实就是有点设计过度，是不是应该将最后的各个功能整合在一起，所以就有了重大的架构变化）

在控制面，将所有的能力，流量管控，安全等等这些能力都放到istiod里面去了，mixer组件是没有了。

入栈的流量进入到proxy里面来，在proxy进入到集群里面来，很多时候是提供gateway网关，网关也是一个envoy的proxy，这个流量进入到集群里面就在proxy里面去跳转。proxy会去将流量劫持掉，然后再发给应用，应用和应用之间的调用都是通过proxy去走的mesh traffic。

设计目标

---

 最大化透明度

• Istio将自身自动注入到服务间所有的网络路径中，运维和开发人员只需付出很少的代价就可以从中受益。
• Istio使用Sidecar代理来捕获流量，并且在尽可能的地方自动编程网络层，以路由流量通过这些代理，而无需对已部署的应用程序代码进行任何改动。
• 在Kubernetes中，代理被注入到Pod中，通过编写iptables规则来捕获流量。注入Sidecar代理到Pod中并且修改路由规则后，Istio就能够调解所有流量。
• 所有组件和API在设计时都必须考虑性能和规模。

增量

• 预计最大的需求是扩展策略系统，集成其他策略和控制来源，并将网格行为信号传播到其他系统进行分析。策略运行时支持标准扩展机制以便插入到其他服务中。（比如endpoint状态怎么样以增量的形式推到envoy里面，比如一个pod发生了变化，很多envoy的配置都需要刷新，每次刷新全量的时候是扛不住的，网络流量占用的带宽也太大了，所以需要去计算质量和只发增量）

可移植性

• 将基于lstio的服务移植到新环境应该是轻而易举的，而使用Istio将一个服务同时部署到多个环境中也是可行的(例如，在多个云上进行冗余部署)。

策略一致性

• 在服务间的API调用中，策略的应用使得可以对网格间行为进行全面的控制，但对于无需在API级别表达的资源来说，对资源应用策略也同样重要。
• 因此，策略系统作为独特的服务来维护，具有自己的API,而不是将其放到代理/sidecar中，这容许服务根据需要直接与其集成。