文章目录 基本原理istio与服务治理关于微服务服务治理的三种形态第1种：在应用程序中包含治理逻辑第2种：治理逻辑独立的代码第3种：治理逻辑独立的进程 Istio与kubernetesIstio的工作机制Istio的重要组件Istio-pilotistio-Mixeristio-citadelistio-galleyistio-sidecar-injectoristio-proxy其他组件
本文内容很多内容摘自《云原生服务网格Istio》，这本书对Istio的介绍很清晰。
基本原理
基本介绍：istio是一个服务治理平台，治理服务间的访问，只要服务间产生访问就可以进行治理，不关注服务是否为微服务，也不要求服务的代码进行微服务化。
istio与服务治理 关于微服务微服务的本质还是将复杂的单体应用拆解成若干的小服务，分而治之。但业务本身的规模和复杂度并没有变少反而变多，网络的可靠性，通信安全，网络延时等变化都成了我们需要关注的内容，另外微服务的机制带来了大量的工作，比如服务如何请求目标服务？需要引入服务发现和负载均衡等，总之简单的事情忽然变得复杂了。
这就需要一些通用的框架来进行这些工作。但在未进行微服务化之前应用的多个模块间本就不需要通信，也不需要服务发现，所以这些框架理解为用于解决微服务而产生的新问题更合理一些。
在最初的服务拆分中，不同模块间的调用都成了问题，怎样选择一个对端服务，怎样发出请求都需要自己写代码来实现。这种方式简单，对外依赖小，但不同模块都需要存在重复的服务治理代码，并且业务逻辑与治理逻辑会产生耦合，如果需要修改治理逻辑很可能需要对全部的模块进行升级。
为了解决第一种方案的弊端，我们很容易想到把治理服务的公共逻辑抽取到一个公共库，让所有的服务都去使用这个公共库。当这些治理逻辑包含在开发框架中后，只要是使用这种开发框架的代码都会具有这种能力。如下图所示的SDK模式。这种类型非常经典的开发框架就是spring cloud
SDK模式虽然在代码的层面上解耦了业务和治理的逻辑，但是业务代码和SDK还是要一起进行编译的，业务代码和治理逻辑还在一个进程内，这就导致了几个问题：
业务代码必须与SDK基于同一种语言。在治理逻辑升级时，即使业务逻辑没有变化，也需要用户的整个服务进行统一升级。 第3种：治理逻辑独立的进程在这里我们可以总结一下第二种方案产生问题的原因：
入侵了业务层代码治理逻辑虽然独立，但还依旧依赖于业务逻辑的进程那么就再解耦一层，把业务逻辑彻底与业务的代码中进行剥离，这就是下图所示的Sidecar模式。
这种形态下，业务逻辑的进程与服务治理逻辑的进程完全独立，两者的代码和运行都无耦合，这样既可以做到开发语言没有界限，也可以做到升级时相互独立。对代码不会产生任何侵入，这种方案就是Istio采用的治理方案。
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都做了什么
业务场景:
Pilot可以理解为传统C/S架构中的服务端Master，他会下发指令给客户端完成业务功能。
Pilot主要实现两个功能：
Mixer主要功能是收集服务间的通信信息，进行监控记录以及策略控制。Mixer主要是通过两个子组件构成：
1.telemetry：主要负责将采集信息通过适配器发送给后台的监控服务进行监控和记录
2.policy：policy的工作模式与telemetry基本是一模一样的，会把采集信息通过适配器发送给后台的策略服务来判断访问是否能够执行（黑白名单之类）
安全组件，以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的调用链监控等功能提供了支持。