Appearance
Service Mesh-概念与演进
看在前面
微服务：一句话回顾
微服务是一种架构风格：把大系统按业务功能分解为多个职责单一、松耦合、可独立部署的小服务，以轻量机制（通常为 HTTP RESTful API）相互通信，形像地说就是"搭积木"。它带来包括降低复杂度、独立开发部署（配合 CI/CD 与 Docker）、跨语言选型在内的优点。也带来分布式的代价——服务发现、服务间调用与调用链跟踪、服务容错、分布式事务与数据一致性、测试与部署复杂度，归纳起来是 API Gateway、服务间调用、服务发现、服务容错、服务部署、数据调用 六类问题。围绕这些问题形成了服务注册/发现、负载均衡、服务网关、配置中心、API 管理与调用链在内的整套组件。Spring Cloud、Dubbo 这类框架已经把上述能力较好地封装进了应用程序内部。
微服务概念的完整展开见 微服务架构最强讲解，那叫一个通俗易懂！。本文聚焦它的下一步演进：把这些治理能力从应用代码中剥离出去的 Service Mesh。
网格服务（Service Mesh）
1、从最原始的主机之间直接使用网线相连
2、网络层的出现
3、集成到应用程序内部的控制流
4、分解到应用程序外部的控制流
5、应用程序的中集成服务发现和断路器
6、出现了专门用于服务发现和断路器的软件包/库，如 Twitter 的 Finagle 和 Facebook 的 Proxygen。这时候还是集成在应用程序内部
7、出现了专门用于服务发现和断路器的开源软件，如 Netflix OSS、Airbnb 的 synapse 和 nerve
8、最后作为微服务的中间层 Service Mesh 出现
Service Mesh 有如下几个特点
应用程序间通讯的中间层
轻量级网络代理
应用程序无感知
解耦应用程序的重试/超时、监控、追踪和服务发现
Service Mesh 核心：sidecar 与控制面/数据面
Service Mesh 的形态由两部分构成：
数据面（data plane）：在每个服务实例旁部署一个轻量级网络代理——sidecar（边车）。服务间进出的流量全部被 sidecar 接管，由它完成服务发现、负载均衡、重试/超时、熔断、加密与监控上报。应用进程只管业务逻辑，对这一切无感知（对多语言应用尤其友好——治理能力不再依赖某种语言的 SDK）。
控制面（control plane）：负责把路由规则、流量策略、安全策略统一下发到所有 sidecar，并汇聚它们的遥测数据，形成统一的治理入口。业务开发者不再在代码里配置重试与熔断，而是在控制面上改规则、全网格生效。
一句话：**原先进程内的微服务治理组件（注册发现、熔断、链路追踪等），下沉到了 sidecar + 控制面组成的基础设施层。**代表实现是 Istio（控制面）+ Envoy（数据面 sidecar）。
延伸：ESB 篇把 Service Mesh 称作"去中心化的 ESB"——治理能力还在，中心节点没了，见 ESB。