本文内容很多内容摘自《云原生服务网格Istio》，这本书对Istio的介绍很清晰。

基本原理

基本介绍：istio是一个服务治理平台，治理服务间的访问，只要服务间产生访问就可以进行治理，不关注服务是否为微服务，也不要求服务的代码进行微服务化。

istio与服务治理

关于微服务

微服务的本质还是将复杂的单体应用拆解成若干的小服务，分而治之。但业务本身的规模和复杂度并没有变少反而变多，网络的可靠性，通信安全，网络延时等变化都成了我们需要关注的内容，另外微服务的机制带来了大量的工作，比如服务如何请求目标服务？需要引入服务发现和负载均衡等，总之简单的事情忽然变得复杂了。
这就需要一些通用的框架来进行这些工作。但在未进行微服务化之前应用的多个模块间本就不需要通信，也不需要服务发现，所以这些框架理解为用于解决微服务而产生的新问题更合理一些。

服务治理的三种形态

第1种：在应用程序中包含治理逻辑

在最初的服务拆分中，不同模块间的调用都成了问题，怎样选择一个对端服务，怎样发出请求都需要自己写代码来实现。这种方式简单，对外依赖小，但不同模块都需要存在重复的服务治理代码，并且业务逻辑与治理逻辑会产生耦合，如果需要修改治理逻辑很可能需要对全部的模块进行升级。

第2种：治理逻辑独立的代码

为了解决第一种方案的弊端，我们很容易想到把治理服务的公共逻辑抽取到一个公共库，让所有的服务都去使用这个公共库。当这些治理逻辑包含在开发框架中后，只要是使用这种开发框架的代码都会具有这种能力。如下图所示的SDK模式。这种类型非常经典的开发框架就是spring cloud

SDK模式虽然在代码的层面上解耦了业务和治理的逻辑，但是业务代码和SDK还是要一起进行编译的，业务代码和治理逻辑还在一个进程内，这就导致了几个问题：

1. 业务代码必须与SDK基于同一种语言。
2. 在治理逻辑升级时，即使业务逻辑没有变化，也需要用户的整个服务进行统一升级。

第3种：治理逻辑独立的进程

在这里我们可以总结一下第二种方案产生问题的原因：

1. 入侵了业务层代码
2. 治理逻辑虽然独立，但还依旧依赖于业务逻辑的进程

那么就再解耦一层，把业务逻辑彻底与业务的代码中进行剥离，这就是下图所示的Sidecar模式。

这种形态下，业务逻辑的进程与服务治理逻辑的进程完全独立，两者的代码和运行都无耦合，这样既可以做到开发语言没有界限，也可以做到升级时相互独立。对代码不会产生任何侵入，这种方案就是Istio采用的治理方案。

形态	业务逻辑侵入	业务代码侵入	业务进程侵入
在应用程序中包含治理逻辑	Y	Y	Y
治理逻辑独立的代码	N	N	Y
治理逻辑独立的进程	N	N	N

Istio与kubernetes

Kubernetes已经提供很很强大的应用负载的部署、升级、扩容等管理能力。Kubernetes中的Service机制已经可以做到服务注册、服务发现和负载均衡。在之前讲的微服务工具的观点来讲，Kubernetes已经做到了不侵入的情况下实现服务互通的问题。但是对服务间的限流、动态路由、调用链追踪都不在Kubernetes的能力范围内。

Istio则可以在Kubernetes的基础上增强这些能力实现更细粒度的控制。Istio与Kubernetes从设计理念到系统架构来看关系都非常密切，甚至有人认为Istio实际上就是Kubernetes团队开发的一个可插拔的增强特性。
Istio的服务发现机制非常完美的基于了Kubernetes的域名访问机制（不论是vs、dr同时通过Service的域名进行配置的），这样避免了自身再去实现一个服务发现的功能，导致服务发现不一致的问题。

Istio的官方一直在强调Istio的可扩展性，可以适配不同的平台甚至docker容器，但是了解了Istio的工作机制后不难发现它的重要能力都是基于Kubernetes进行构建的（Istio在0.8版本中支持通过Eureka注册中心来进行服务发现，但在1.0版本后这一支持也被剔除）。

Istio的工作机制

下图展示了Istio的简化的工作机制，可以以下图为例看到在服务发生调用的时候Istio都做了什么
业务场景:

• 用户访问用户管理模块，用户管理模块调用订单管理模块获取订单信息。

1. 自动注入：在每一个pod启动时Istio都会对其增加一个init任务，为其启动一个Sidecar的container
2. 流量拦截：在pod初始化时的init任务会设置iptables规则，每当有流量产生时都会基于配置的iptables规则把出入流量拦截到Sidecar上，应用程序感知不到Sidecar的存在，还是以原本的访问方式访问。以图中内容来举例，用户管理的出口流量会被用户管理的Sidecar拦截，订单管理的入口流量会被订单管理的Sidecar拦截。
3. 服务发现：服务发起方的Envoy调用管理组件Pilot的服务发现接口获取目标服务的实例列表（Pilot是通过目标服务的Service来发现的目标实例列表，所以Istio的工作是需要依赖Service的）。以图中内容来举例用户管理服务侧的Sidecar通过Pilot的服务发现接口得到了订单管理服务的各个实例地址，为访问做准备。
4. 流量治理：Sidecar获取到Pilot下发的访问规则， 在拦截到输入输出流量的时候按规则治理。以图中内容来举例：用户管理服务的Sidecar根据Pilot下发的流量治理规则把不同特征的请求分发给订单管理服务的V1、V2版本上。
5. 服务遥测：服务间产生通信的时候Sidecar会将请求内容上报给Mixer遥测组件，Mixer会根据适配器将数据转发给对应的后端监控服务（prometheus、fluentd等）进行监控、日志采集、调用链分析等
6. 策略执行：服务间产生通信的时候Sidecar会将请求内容上报给Mixer遥测组件，Mixer会根据适配器将数据转发给对应的策略服务（list、Denier、MemoryQuota）进行黑白名单、熔断、配额限制来判断该访问通信是否能够执行。
7. 访问安全：在服务访问时通过双方的Sidecar进行双向的认证和通道加密，秘钥证书都由Citadel组件维护。

Istio的重要组件

Istio-pilot

Pilot可以理解为传统C/S架构中的服务端Master，他会下发指令给客户端完成业务功能。
Pilot主要实现两个功能：

1. 服务发现：pilot会通过Kubernetes的Service来进行Pod的服务发现，并把服务发现结果转换为Istio自己的数据模型下发给所有的Sidecar
2. 规则下发：当用户在控制台配置了服务治理规则，pilot会将这些规则下发给所有的Sidecar。

istio-Mixer

Mixer主要功能是收集服务间的通信信息，进行监控记录以及策略控制。Mixer主要是通过两个子组件构成：
1.telemetry：主要负责将采集信息通过适配器发送给后台的监控服务进行监控和记录
2.policy：policy的工作模式与telemetry基本是一模一样的，会把采集信息通过适配器发送给后台的策略服务来判断访问是否能够执行（黑白名单之类）

istio-citadel

安全组件，以Secret的形式为每个服务都生成证书密钥，在pod创建时挂载到pod上，pod互相访问时通过这些证书密钥进行双向认证

istio-galley

配置中心

istio-sidecar-injector

负责自动注入的组件：只要开启了自动注入，在pod创建时就会调用istio-sidecar-injector向pod中注入sidecar容器

istio-proxy

在翻阅istio文档时经常会发现Sidecar、Envoy、Proxy等术语会混着使用。实际上Sidecar是一种概念，Envoy是这个概念的实现方式。而实际上使用istio自动注入生成的Sidecar容器的名称实际上是istio-proxy。
istio-proxy中包含Sidecar的功能，还包含了一个proxy-agent探针作为守护进程，保护Sidecar实时有效。

其他组件

Istio还有很多集成组件比如Prometheus、Grafana、Zipkin等等，这些组件为Istio的调用链监控等功能提供了支持。