初识Istio

初识Istio

Istio是什么

迭代方式说明Istio是什么

• 一个用于服务治理的开放平台
• 一个Service Mesh形态的用于服务治理的开放平台
• 一个与Kubernetes紧密结合的适用于云原生场景的Servuce Mesh形态的用于服务治理的开放平台

官方介绍服务治理涉及到以下几个方便：

• 连接：Istio通过集中的配置的流量规则控制服务的流量和调用，实现负载均衡、熔断、故障注入、重试、重定向等服务治理功能。
• 安全：Istio提供透明的认证机制、通道加密、服务访问授权等安全能力，可增强服务访问的安全性。
• 策略执行：Istio通过可动态拔插、可扩展的策略实现访问控制、速率限制、配额管理、服务计费能力。
• 可观察性：动态获取服务运行数据和输出，提供强大的调用链、监控和调用日志手机输出的能力。配合可视化工具，可方便运维人员了解服务的运行状态，发现并解决问题。

服务治理的三种形态

• 在应用程序中包含治理逻辑
  在微服务化的过程中，服务将会拆分为多个服务，但是在多个服务之间必须要保证通信，这时候就需要自己编写代码进行实现。这种方式比较简单，并且对外部依赖较低，但是会出现大量的重复代码，所以微服务越多，那么重复的代码就会越多，维护成本较高。并且业务代码和治理逻辑耦合，不管是对治理逻辑升级还是业务代码升级，都需要修改同一段代码。

• 治理逻辑独立的代码
  在第一种方式下容易想到把治理的公共逻辑抽象成一个公共库，让所有的微服务都是用这一个公共库，将这样的微服务治理功能集成在开发框架中，只要使用这样的框架没就能包含治理能力。这种方式成功的解耦了业务和治理逻辑，但是在编译的时候，业务代码和SDK还是需要一起编译，并且在同一个进程内。这产生了业务代码必须和SDK基于同一种代码，即语言绑定。其次就是SDK对于开发人员的难度较高。

• 治理逻辑独立的进程
  SDK模式还是侵入了用户的代码，那么再往下一层就是将服务治理逻辑彻底从用户的业务代码中剥离出来，这种情况下，业务进程和服务治理的进程都是独立存在的，其代码和运行都无耦合。这样就可以达到与开发语言无关，维护也是相互独立的。这种方式也叫做Sidecar模式，在对已存在的系统进行微服务治理是，只需要搭配Sidercar即可，对原本的业务服务无需做任何的修改。

Istio与服务网格

服务网格的特点

• 基础设施：服务网格是一种处理服务间通信的基础设施层
• 云原生：服务网格尤其适用于在云原生场景下帮助应用程序在复杂的服务拓扑间可靠地传递请求
• 网络代理：服务网格一般通过一组轻量级网络代理来执行治理逻辑的
• 对应用透明：轻量网络代理与应用程序部署在一起，但是应用感知不到代理的存在，还是使用原来的工作方式

Istio与Kubernetes

Kubernetes提供了强大的应用负载的部署、升级、扩容等运行管理能力，并且其中的Service资源也可以做服务注册、服务发现和负载均衡。
Kubernetes本身是支持微服务的架构的，在pod中部署微服务是非常合适的。但是也有相关的缺陷，服务的熔断、限流、动态路由、调用链追踪等。如何提供从底层的负载部署运行到上层的服务访问治理端，Kubernetes加Istio则是不二之选。
Kubernetes结合Istio使用

• 数据面：Sidecar运行在Kubernetes的pod里面，作为一个porxy和业务容器部署在一起，在服务网格的定义中要求应用程序运行的时候感知不到Sidecar的存在。基于Kubernetes的一个pod多个容器是得部署运维对用户透明，用户感知不到创建Sidecar的创建过程，还是以原有的方式创建负载，通过Istio自动注入服务，可以自动的给指定的负载注入proxy。
• 统一服务发现：Istio的服务发现机制，基于Kubernetes的域名访问机制构建而成。
• 基于Kubernetes CRD描述规则：Istio的所有路由规则和控制策略都是通过Kubernetes CRD实现的，因此各种策略规则都存储在Kube-apiservice中。
  Istio和Kubernetes的天然融合且基于Kubernetes构建，补齐了Kubernetes的治理能力，提供了端到端的服务运行治理平台。