利用几天时间，读了下<<云原生网络Istio>云原生网络Istio>。
发现它的强大之处，并且让我们能够更好的玩转微服务，所以做个笔记来梳理所看的就很有必要了。

Istio是什么？

Istio是一个用于服务治理的开放平台。

服务治理的三种形态

1. 应用程序中包含治理逻辑

    在微服务化的过程中，将服务拆分后会发现一堆麻烦事，连基本的业务连通都成为问题。  
    所以在处理一些治理逻辑，例如如何找到对端的服务实例，怎么选择一个对端实例请求时，  
    都需要自己用代码来实现。所以微服务越多，重复的代码越多，维护艰难，高度耦合。  
    这样不管是对治理逻辑升级还是对业务的升级，都要改同一段代码。如下图所示:  
   

image.png

2. 治理逻辑独立的代码

    在解决第一种形态的问题时，会很容易想到把治理的公共逻辑抽象成一个公用库，  
    让所有的微服务都适用这个公用库。也就是SDK模式(如下图)，非常典型的框架就是spring cloud。  
    SDK模式虽然在代码上解耦了业务和治理逻辑，但业务代码和SDK还是要一起编译，还在同一个进程内。  
    所以会有几个问题:业务代码需要和SDK属于同一种语言。在治理逻辑升级时，还需要用户的整个服务升级。
   

image.png

3. 治理逻辑独立的进程

    SDK模式仍旧侵入了用户的代码，那就再解耦一层，把治理逻辑彻底从用户的业务代码中剥离出来，  
    就是如下图所示的Sidecar模式。  
    显然，在这种形态下面，用户的业务代码和治理逻辑都以独立的进程存在，  
    这样可以做到与开发语言无关，升级也相互独立。
   

image.png

Service Mesh(服务网格)

实际上服务治理的第三种形态就可以认为是当前最流行概念Service Mesh的雏形。它有几个特点:

• 治理能力独立(sidecar)
• 应用程序无感知
• 服务网格是一种处理服务通信的基础设施层

image.png

Istio问世

image.png
上图很好的归纳了Istio的一些功能点:
image.png
image.png

与Kubernetes完美结合

从场景上看Kubernetes已经提供了非常强大的应用负载的部署，升级，扩容等运行管理能力。K8s中的Service机制也已经可以做服务注册，服务发现和负载均衡，支持通过服务名访问到服务实例。
但是K8s对服务间访问的管理如服务的熔断，限流，动态路由，调用链追踪都不在它的能力范围内，所以Istio就成了K8s的最完美帮手。

image.png

Istio与Kubernetes架构关系

image.png

1. 数据面
   数据面Sidecar运行在Kubernetes的Pod里，作为一个Proxy和业务容器部署在一起。在服务网格的定义中要求应用程序在运行的时候感知不到Sidecar的存在。而基于Kubernetes的一个Pod多个容器的优秀设计使得部署运维对用户透明，用户甚至感知不到部署Sidecar的过程。用户还是用原有的方式创建负载，通过Istio的自动注入服务，可以自动给指定的负载注入Proxy。如果在另一种环境下部署和使用Proxy，则不会有这样的便利。

2. 统一服务发现
   Istio的服务发现机制非常完美地基于Kubernetes的域名访问机制构建而成，省去了再搭一个类似Eureka的注册中心的麻烦，更避免了在Kubernetes上运行时服务发现数据不一致的问题。
   尽管Istio强调自己的可扩展性的重要性在于适配各种不同的平台，也可以对接其他服务发现机制，但在实际场景下，通过深入分析Istio几个版本的代码和设计，便可以发现其重要的能力都是基于Kubernetes进行构建的。

3. 基于Kubernetes CRD描述规则
   Istio的所有路由规则和控制策略都是通过Kubernetes CRD实现的，因此各种规则策略对应的数据也被存储在Kube-apiserver中，不需要另外一个单独的APIServer和后端的配置管理。所以，可以说Istio的APIServer就是Kubernetes的APIServer，数据也自然地被存在了对应Kubernetes的etcd中。
   Istio非常巧妙地应用了Kubernetes这个好基座，基于Kubernetes的已有能力来构建自身功能。Kubernetes里已经有的，绝不再自己搞一套，避免了数据不一致和用户使用体验的问题。

好啦，后面会整理Istio中的一些基本概念和Demo。