Service Mesh
Service Mesh 的中文译为 “服务网格” ，是一个用于处理服务和服务之间通信的基础设施层，它负责为构建复杂的云原生应用传递可靠的网络请求，并为服务通信实现了微服务所需的基本组件功能，例如服务发现、负载均衡、监控、流量管理、访问控制等。在实践中，
服务网格通常实现为一组和应用程序部署在一起的轻量级的网络代理，但对应用程序来说是透明的。
Sidecar指的是和应用服务部署在一起的一个代理程序，要是访问你的应用要走proxy才能访问到，只能走sidecar去通信，不能走应用和应用之间去通信，因为应用所有的流量都被proxy所接管了。
服务网格的本质是将业务程序给接管起来，然后由自己的proxy代理去负责数据的转发。
上面蓝色的方块都会有一个控制心去统一管理蓝色的方块，比如在控制中心可以给它发送一个配置，让这些proxy去生效。
还可以去做访问控制，指定某个应用不能访问某个应用，这样proxy就不会转发了。
管理员只是负责配置中心，来配置整个服务网格内的一些流量的管控，等等一系列这些功能。
Service Mesh特点
Service Mesh有以下特点：
servicemesh可以看作nginx代理后端的应用之上更为高级的一种模式，这个模式就是增加控制系统，这些控制系统可以将所有的代理统一的去管理起来，就不像传统单体应用的代理。
因为流量都经过sidecar，被它接管了，那么可以做非常多的功能。
service mesh设计的目标和实现的原理其实就是来自于proxy，和一个控制中心去管理。
Istio概述
Isito是Service Mesh的产品化落地，是目前最受欢迎的服务网格，功能丰富、成熟度高。
Istio版本变化
在Istio1.5版本发生了一个重大变革，彻底推翻原有控制平面的架构，将有原有多个组件整合为单体结构 “istiod”，同时废弃了Mixer 组件，如果你正在使用之前版本，必须了解这些变化。
之前有很多的组件，在部署的时候要部署7，8个组件，但是又不知道组件之间什么关系，怎么去通信的，有些组件可能很容易就挂掉了。
listio是基于kubernetes上面一个服务网格治理平台，早期追求架构的纯粹性，一个控制面很多组件，好多组件从架构来说非常清晰，设计的非常好，后面就陷入了困境，一个控制面很多组件，当你做系统升级的时候，这个升级就陷入了困境，先升级哪个组件，后升级哪个组件，中间是否会有业务中断，这就会造成很多的困扰。
所以做个取舍，比如一些组件是一个团队维护的，那就合并好了，将一些组件变为一个组件了，这样升级的风险降低了，维护成本降低，这里面没有绝对的原则，完全看你的业务场景。
重构之后，服务端控制面板这就有istiod，之前老版本有4个组件，现在只要一个组件。
Istio架构与组件
Istio服务网格在逻辑上分为数据平面和控制平面。
- Pilot：策略配置组件，为Proxy提供服务发现、智能路由、错误处理等。 （管理proxy）
- Citadel：安全组件，提供证书生成下发、加密通信、访问控制。
- Galley：配置管理、验证、分发。
（指的是微服务的那一端，就是服务部署的那一端，比如部署一个Pod，这就属于数据平面，他会在数据平面里面植入一个proxy）（proxy负责所有微服务网络通信，微服务之间通信都会走这个proxy，或者微服务访问外部也要走这个proxy，负责转发和配置相关的策略）
可以看到改版之后架构清晰明了，减少了更多的成本。
Istio基本概念
Istio 有 4 个配置资源，落地所有流量管理需求：（各种各样功能是根据这些配置资源实现的）
- VirtualService（虚拟服务）：实现服务请求路由规则的功能。
- DestinationRule（目标规则）：实现目标服务的负载均衡、服务发现、故障处理和故障注入的功能。
- Gateway（网关）：让服务网格内的服务，可以被全世界看到。
- ServiceEntry（服务入口） ：允许管理网格外的服务的流量。（用的较少）