服务通信
V0
服务之间通过手动控制网络流传输等 进行通信
V1
服务之间通过HTTP / TCP进行通信
V2 微服务架构
微服务之间通过相同的网络协议通信(rpcx grpc)
V3 微服务架构演进
为了避免每个服务都需要自己实现一套分布式系统通信的语义功能，随着技术的发展，一些面向微服务架构的开发框架出现了
这些框架实现了分布式系统通信需要的各种通用语义功能：如负载均衡和服务发现等，因此一定程度上屏蔽了这些通信细节，使得开发人员使用较少的框架代码就能开发出健壮的分布式系统。
痛点
- 版本兼容问题: 框架以lib库的形式和服务联编，复杂项目依赖时的库版本兼容问题非常棘手，同时，框架库的升级也无法对服务透明，服务会因为和业务无关的lib库升级而被迫升级(GO版本 ，依赖的lib比项目开发版本高)
- 多语言治理: 多语言的复杂性主要在于 SDK 的重复实现，每个治理逻辑需要开发不同的语言版本，此后还要一直对其进行维护，这是一份冗余且负担很重的工作。
- 多语言治理: 由于微服务本身的定义就是 不同服务可以使用不同的语言 ，因此不同的SDK会需要开发不同语言的代码
- 多协议治理: 微服务之间可以使用不同的通信协议 ，rpcx grpc
什么是Service Mesh
Service Mesh 是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但对应用程序透明。
Service Mesh (服务网格)适合云环境下的分布式微服务
解决了什么问题
- 屏蔽分布式系统通信的复杂性(负载均衡、服务发现、认证授权、监控追踪、流量控制等等)，服务只用关注业务逻辑；
- 真正的语言无关，服务可以用任何语言编写，只需和Service Mesh通信即可；
- 对应用透明，Service Mesh组件可以单独升级；
第一代Service Mesh : 边车模式(Sidecar)
将分布式服务的通信抽象为单独一层，在这一层中实现负载均衡、服务发现、认证授权、监控追踪、流量控制等分布式系统所需要的功能，作为一个和服务对等的代理服务，和服务部署在一起，接管服务的流量，通过代理之间的通信间接完成服务之间的通信请求
Service Mesh 将服务治理能力下沉到了 sidecar，SDK 只需要负责编解码、与 sidecar 通信，通用逻辑基本不用修改，只要对 sidecar 修改就可以应用到所有语言和框架
我们从一个全局视角来看，得到下图
不同微服务之间的流量其实是在sidecar之间流转，sidecar接收到流量后将流量转发到service
第二代Service Mesh: 治理
第一代Service Mesh由一系列独立运行的单机代理服务构成，为了提供统一的上层运维入口，演化出了集中式的控制面板，所有的单机代理组件通过和控制面板交互进行网络拓扑策略的更新和单机数据的汇报。这就是以Istio为代表的第二代Service Mesh。
即: 在第二代Service Mesh中，为每个微服务Sidecar引入了治理能力
统一的控制面板
数据平面
即每个微服务的Sidecar
控制平面
治理Sidecar的平台
开源现状
个人感觉蚂蚁的MOSN比较适合
具体实践
接入前：
- 是否需要接入Service Mesh
- 所在平台是否支持接入Service Mesh
- 是否有人力 、上级的支持
需要关注
接入 Mesh后 需要关注
- 性能 。引入sidecar 会导致服务调用链路变长 sidecar和微服务之间通信也需要消耗性能
- 治理能力 。包括限流 接口预热 接口鉴权等
- 问题排查 。是否方便进行正常业务问题排查 ，组件问题排查
