Service Mesh之Istio

本篇文章是本人学习Service Mesh的第二章，主要用来介绍当前最流行的一个Service Mesh落地产品Istio。

本篇文章的目的主要希望从大的层面弄清楚下面几点：

1. Isti是什么？
2. Istio长什么样子？
3. Istio 为什么这么设计？

问题1 ：Istio是什么？

Istio是 Service Mesh实现的一个开源产品，目前备受瞩目，被各大厂商和开发者争相追捧。

它提供了一个完整的解决方案，可以以统一的方式去管理和监测你的微服务应用。同时，它还具有管理流量、实施访问策略、收集数据等方面的能力，而所有的这些都对应用透明，几乎不需要修改业务代码就能实现。

它最大的特性就是对应用透明，你可以将你的微服务应用无缝的接入网格，而无需修改业务逻辑。提供了以下重要的功能：

1.为 HTTP、gRPC、WebSocket 和 TCP 流量自动负载均衡。
2.通过丰富的路由规则、重试、故障转移和故障注入对流量行为进行细粒度控制。
3.提供完善的可观察性方面的能力，包括对所有网格控制下的流量进行自动化度量、日志记录和追踪。
4.提供身份验证和授权策略，在集群中实现安全的服务间通信。

Istio的核心功能主要包括下面几个方面：

1）流量控制

请求路由和流量转移
弹性功能，包括熔断、超时、重试
调试能力，包括故障注入和流量镜像

2）安全

提供的安全功能主要分为认证和授权两部分

1.认证:
提供了两种方式的认证：
1）对等认证（Peer authentication）：用于服务到服务的认证。
2）请求认证（Request authentication）：也叫最终用户认证，验证终端用户或客户端。
2.授权：
Istion的授权策略可以为网格中的服务提供不同级别的访问控制，比如网格级别、命名空间级别和工作负载级别

3）可观察性

作用：面对复杂的应用环境和不断扩展的业务需求，即使再完备的测试也难以覆盖所有场景，无法保证服务不会出现故障。正因为如此，才需要“可观察性”来对服务的运行时状态进行监控、上报、分析，以提高服务可靠性。

主要由下面三类数据构成：
1.指标：
指标本质上是时间序列上的一系列具有特定名称的计数器的组合，
不同计数器用于表征系统中的不同状态并将之数值化。通过数据聚合之后，
指标可以用于查看一段时间范围内系统状态的变化情况甚至预测未来一段时间系统的行为。

2.日志：
日志是软件系统中记录软件执行状态及内部事件最为常用也最为有效的工具。

3.分布式追踪：
分布式追踪通过额外数据（Span ID等特殊标记）记录不同组件中事件之间的关联，
并由外部数据分析系统重新构造出事件的完整事件链路以及因果关系。

问题2: Istio长什么样子？

Istio架构由两部分组成，分别是数据平面和控制平面，架构如下所示：

1.数据平面：

由整个网格内的Sidecar代理组成，这些代理以Sidecar的形式和应用服务一起部署。每一个Sidecar会接管进入和离开服务的流量，并配合控制平面完成流量控制等方面的功能。可以把数据平面看做是网格内 Sidecar代理的网络拓扑集合。

Istio里面的数据平面默认使用的是Envoy作为Sidecar代理，而它主要支持下面几点：

路由、流量转移。
弹性能力：如超时重试、熔断等。
调试功能：如故障注入、流量镜像。

2.控制平面：

就是控制和管理数据平面中的Sidecar代理，完成配置的分发、服务发现、和授权鉴权等功能。

Istio1.5中的控制平面由原来分散的、独立部署的几个组件整合为一个单体结构 istiod，变成了一个单进程、多模块的组织形态，主要包括下面几部分：

1) Pilot:

主要功能是将路由规则等配置信息转换为Sidecar可以识别的信息，并下发给数据平面。可以把它简单的理解为是一个配置分发器（dispatcher），并辅助Sidecar完成流量控制相关的功能。

2) Citadel

Istio中专门负责安全的组件，内置有身份和证书管理功能，可以实现较为强大的授权和认证等操作。

3) Galley

其目的是将Pilot和底层平台（如 Kubernetes）进行解耦。它分担了原本Pilot 的一部分功能，主要负责配置的验证、提取和处理等功能。

问题 3: Istio为什么这么设计？

Istio被设计的大而全，希望打造一个最终形态的ServiceMesh产品，也正是基于这个目的，Istio主要从下面4个部分来考虑需要解决的事情：

1. 对应用透明： 从本质上来说，对应用透明是ServiceMesh的特性，一个合格的ServiceMesh产品都应该具有这一特性，否则也就失去了网格产品的核心竞争力。Istio通过借助 Kubernetes 的 admission controller ，配合 webhook 可以完成Sidecar的自动注入。在配置方面，也基本做到了对应用无侵入。
2. 可扩展性： Istio认为，运维和开发人员随着深入使用Istio提供的功能，会逐渐涌现更多的需求，主要集中在策略方面。 因此，为策略系统提供足够的扩展性，成为了Istio 的一个主要的设计目标。Istio1.5版本之前提出来的Mixed，便是这一类代表，虽然1.5移除了这部分内容，但是本人觉得这是因为Istio还没有想好如何去更好的支持Mixed实现的这部分内容，毕竟它的插件模式，是可扩展性的一大利器。
3. 可移植性： 考虑到现有云生态的多样性，Istio被设计为可以支持几种不同的底层平台，也支持本地、虚拟机、云平台等不同的部署环境。不过从目前的情况来看，Istio和 Kubernetes 还是有着较为紧密的依赖关系。
4. 策略一致性： Istio使用自己的 API 将策略系统独立出来，而不是集成到Sidecar中，这允许服务根据需要直接与之集成。同时，Istio在配置方面也注重统一和用户体验的一致。一个典型的例子是路由规则都统一由虚拟服务来配置，可在网格内、外以及边界的流量控制中复用。

参考资料：

云原生社区：https://cloudnative.to/

servicemesher社区： https://www.servicemesher.com/

Iistio中文网：https://istio.io/latest/zh/

listio官网：https://istio.io/

Istio Handbook书籍：https://www.servicemesher.com/istio-handbook/

envoy英文文档：https://www.envoyproxy.io/docs

envoy中文文档：https://www.servicemesher.com/envoy/

开源代码：

Istio: https://github.com/istio/istio

mosn: https://github.com/mosn/mosn

envoy: https://github.com/envoyproxy/envoy