Service Mesh
Service Mesh 是微服务时代的 TCP 协议
时代1：原始通信时代
在这里插入图片描述
通信底层需要底层能够传输字节码和电子信号的物理层完成， 在 TCP 协议出现之间，需要服务自己处理通信的连接，丢包，乱序，重试等一系列问题。也就是说服务实现过程中，需要考虑网络传输的问题。
TCP 时代
为了避免每个服务都需要自己实现一套相似都网络传输处理逻辑， 于是有了 TCP 协议， 解决了网络传输过程中的流量控制问题，把网络传输从服务实现中抽取出来。
微服务时代
TCP 出现之后，机器之间的网络通信不再是问题，但是随着分布式系统， BigTable/MapReduce 等分布式系统蓬勃发展， 分布式系统对通信提出了新对通信语义，入熔断策略， 负载均衡， 服务发现，认证和鉴权，trace和监控, 于是便有了微服务。第一代微服务在自己对服务中实现服务发现和熔断。
微服务2.0
为了避免每个服务自己实现一套分布式通信对语义功能， 出现了一些微服务框架，Spring Cloud, 这些框架实现了分布式系统的服务发现，熔断，负载均衡等。使得开发人员使用少量的框架代码就能够实现分布式系统。
Service 1.0
微服务解决了服务发现，负载均衡，服务熔断等问题，但是也有了一些新等问题。
- 微服务框架复杂，要掌握也不是一件容易的事情，业务开发人员应该专注业务本身，而不是服务框架，实际使用过程中，要解决框架出现的问题也比较复杂。
- 语言兼容问题，微服务的一个重要特性就是语言无关， 也就是说，服务可以用 Go 开发，也可以用 Java 开发。但是这些框架往往都有自己都语言要求， 一般是服务应用 Java 开发。很难兼容其他语言。
- 版本升级问题，框架一般是采用 Lib 包依赖的方式。这样复杂项目依赖问题会十分棘手。框架库的升级无法对服务透明，往往框架升级会导致服务升级。
如何解决这个问题，采用代理思想解决。把分布式服务通信抽象为一层，这一层中实现负载均衡。服务发现，认证鉴权，监控追踪，流量控制等。作为一个以服务对等的代理服务存在和服务部署在一起。接管服务的流量，通过代理之间的通信完成服务之间的通信。
全局部署图如下，像一个网格， 蓝色部分是代理服务，绿色部分是服务本身。
暂时去掉服务，这样有了 Service Mesh 服务网格
Service Mesh 2.0
Service 1.0 由一系列服务代理构成， 为了提供统一的运维入口，演化成了统一的集中式管理面板。所有的单机代理组件通过和控制面板之间交互进行网络拓扑策略的更新和单机数据的汇报。
控制面板的全局部署视图
Service Mesh 有没有问题？
服务网格是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格保证请求在这些拓扑中可靠地穿梭。在实际应用当中，服务网格通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但对应用程序透明。
优点总结：
- 基础设施，服务网格是一个基础设施，请求在拓扑之间可靠传输
- 网络代理，屏蔽了分布式系统通信的复杂性（服务发现，服务熔断， 认证鉴权， 流量控制，监控追踪）
- 与语言无关，服务可以用任何语言编写
- 应用透明，对服务是透明对存在，升级不会导致服务升级
挑战：
- 以代理的方式进行通信，降低通信性能
- Service Mesh 接管了网络流量， 对 Service Mesh 稳定性要求高， 对服务运维和管理也是挑战。
参考资料
- https://skyao.io/learning-servicemesh/introduction/evolution.html
- https://github.com/skyao/learning-servicemesh
- https://jimmysong.io/istio-handbook/concepts/sidecar-pattern.html
- https://jimmysong.io/kubernetes-handbook/cloud-native/cncf.html
- https://zhuanlan.zhihu.com/p/61901608
