Istio 什么是服务网格（Service Mesh）

引言

简单说说我对Istio的理解，因为Istio东西较多，这里先说个大概的概念。读本文前起码对K8s有所了解或使用过。后续我会写一些实际案例的文章，读本文先是对Istio与ServiceMesh有个概念。

Istio 理解

我自己的理解是K8S虽然更偏向服务，并且可以直接实现服务发现，Configmap等等，常规Spring Cloud 的流控，权重，灰度发布等等规则，还是集成在了代码中，使用Istio Vitrual Service、Gateways等可以将这些东西从代码中分离出来，让Istio来控制这些，目的在于将这些与业务无关的东西转移到基础架构上。
在K8s配合Istio后其实是为了让其他语言也可以完美的加入到我们的微服务系统中，如果全是Java，那么Spring Cloud就可以了.

为什么使用服务网格？

1. 假设在架构中要使用NetflixOSS Hystrix或者SpringCloud Alibaba，就必须使用JAVA，通常，熔断和负载均衡是都会集成在代码里，但是复杂系统中微服务实现往往会使用不同的编程语言，不同的框架，这些方案往往存在差异性和缺少共性。
2. Linux容器简化了应用程序的打包部署，容器是云原生应用的基石，通过应用容器化不仅使得开发部署更加敏捷，迁移更加灵活，并且可以将这些实现标准化。
3. 而容器编排则更近一步，负责解决如何高效地编排和利用好这些资源，最早大家使用的都是docker swarm集群,使用docker stack部署，而现在Kubernetes编排容器已经成为一种标准，它比docker swarm中多了一些扩展及健康检查（探针）。
4. Istio的这些服务网格技术在微服务治理上很好地补齐了Kubernetes的功能，同时又与Kubernetes有着完美的集成，不同于现有的微服务架构，如 SpringCloud,Dubbo,NetflixOSS等。

什么是服务网格？

要学习Istio的使用其实很简单，学习本身就是先学习如何使用，再学习原理，这是很正常的过程，所以服务网格事实上也很容易学习。
前面说过，Istio是为了让熔断，负载均衡，限流，网关等等与业务无关的东西，从代码中分离出来，将它们移到基础架构上。这样我们就可以使用不同的语言，不同的框架来实现微服务的业务功能，而其他的交给Istio来做。
基于Sidecar代理的服务网格技术会让管理和维护变得更轻松，能提供更灵活的方法来配置运行时策略。
服务网格一般由控制平面和数据平面组成。

• 控制平面：
  具体来说控制平面是一组在一个专用的命名空间中运行的服务。这些服务完成一些控制管理的功能，包括遥测数据、提供面向用户API、向数据平面代理提供数据等。
• 数据平面：
  数据平面是由一系列运行在每个服务实例中的透明代理构成，这些代理自动处理进出服务的所有流量，因为它们是透明的，所以这些代理充当了一个进程外的网络堆栈，向控制平面发送遥测数据并从控制平面接收控制信号。

服务网格是一个专用的基础设施层，使服务到服务之间的通信更加安全，快速，可靠。
上面写了一堆，但是如果你没有接触过Istio，实际上会看的云里雾里，所以我这里有给新手理解的一种说法：

• 服务网格是一种网络模型，位于TCP/IP之上的抽象层。你可以理解成为每个服务实例都配置了一个nginx或haproxy（实际上是envoy），而我们将这种转发服务，注入到每个服务实例中，我们通过控制平面将策略更新到每个注入到服务中的代理中，这样我们就具有统一更新策略的功能。

Istio 注入

Istio 注入k8s 前

Istio支持consule和k8s

通过istioctl manifest apply --set profile=demo(default)等 来安装。

在使用istioctl kube-inject后，事实上会在一个Pod中启动3个container。

其中除了本身的container之外，会多出2个container：

1. istio-init
2. istio-proxy

istio-init 在初始化network space，iptables等之后会立马挂掉。

---

Istio 注入k8s 后

istio proxy 中 会有2个进程分别是：

1. pilot-agent
2. envoy

Istiod的Discovery会Watch ApiServer

ApiServer 会将数据存在ETCD中。

只要我们通过istioctl修改流控规则等，Istiod会立刻监听到，并解析成envoy的配置。

之后由polit-agent 发送给envoy。

图解

可以看看这张图，绿色代表每一个Service,蓝色代表注入后的envoy，在内部通信时就会根据蓝色来相互交流，为什么说是服务网格呢，只有被注入的服务相互之间通信才会用到envoy，如果某个Service并没有被注入，那么实际上它就是在这个网格之外，也就不会使用envoy的规则。