Service Mesh基础概念

Service Mesh 演进历程

网络基础设施

计算机网络系统

开发人员需要在自己的代码里处理网络通讯 的细节问题，如数据包顺序，流量控制等。 结果就是应用程序需要处理网络逻辑，导致 网络逻辑和业务逻辑混杂在一起。 

TCP/IP 出现

解决了流量控制等问题。 虽然网络逻辑代码依然存在，但已经从应用程序抽 离出来，成为操作系统网络层的一部分。 应用程序和开发人员得以解脱，互联网百花齐放。 

微服务时代

关于微服务， Martin Fowler 对微服务的描述是“微服务是以一组小型服务来开发单个应用程序的方法，每个服务都在运行在自己的进程中，服务间采用轻量级通信机制（通常用HTTP资源的API）”，可以看出微服务的本质上还是分而治之，化繁为简的哲学智慧在计算机领域的一个体现。

第一代微服务

熔断限流、负载均衡、服务发现、授权、trace监控等分布式系统特有的通信语义，需要开发人员去实现 。 （服务规模较小情况）

第二代微服务

面向微服务架构的开发框架出现(BRPC/RAL/GDP等)，屏蔽通信细节，开发人员使用较少的框架代码就能开发出健壮的分布式系统。（服务有一定规模）

服务治理形态比较

通过第一代微服务，第二代微服务实现的能力可以总结如下表格。业务逻辑与服务治理是不是有更解耦的方式呢？很显然， 用户的业务代码和治理逻辑都独立的进程存在，两只的代码和运行都无耦合，这样可以做到与开发语言无关，升级也相互独立。

形态	业务逻辑入侵	业务代码入侵	业务进程入侵
在应用中包含治理逻辑	Y	Y	Y
治理逻辑独立的代码	N	N	Y
治理逻辑独立进程	N	N	N

Service Mesh 时代

第一代 Service Mesh

服务治理能力下沉到代理层，代理层实现负载均衡、服务发现、认证授权、监控追踪、流量控制等。（Linkerd，Envoy，NginxMesh为代表的代理模式（边车模式）应运而生）

第二代 Service Mesh

解耦策略决策逻辑，统一运维入口，演化出集中式的控制面板（以Istio为代表），提高配置分发效率。