Service Mesh_系统设计笔记8

一.从网络的可靠性说起

机器之间可以通过物理连接（例如电缆、电话线、无线电波、卫星或红外光束等等）传递信号，进行信息交换：

然而，数据在传输中可能会出现一些异常状况，例如：

• 数据丢失：数据包可能会到达一个缓冲区已经被塞满的路由器，接着被丢掉

• 顺序出错：一组数据包可能会途径闲忙程度不同的多个路由器，出现不同程度的延迟，最后到达顺序会与发出时的顺序不一致

所以至少要有丢包重发、顺序重组等控制机制，早期这部分工作由网络服务/应用来完成（与业务逻辑并存于应用层）：

后来，这部分工作下沉到了网络栈（操作系统的网络层），由 TCP/IP 等标准网络协议来保证数据传输的可靠性 （下图中的大粗线）：

二.微服务架构下的可靠性挑战

网络协议提供的可靠性保障对于小型的多机互联场景而言足够了，但在大规模的分布式场景（如微服务架构）中，需要引入更多的机制来保障整体的可靠性，例如：

• Service Discovery 机制 ：通过服务注册查询机制，让一个微服务能够找到另一个，从而允许动态伸缩、以及故障转移

• 熔断机制（ Circuit Breaker pattern ）：提供断路保护（ 就像电表跳闸 ），防止某个服务不可用引发级联故障，比如操作不成功导致疯狂重试，请求堆积，甚至耗尽相关资源，系统中不相关的部分也因此出现故障

同样，这部分工作早期也是由微服务来完成的（与业务逻辑并存于微服务中）：

紧接着出现了 Finagle 、 Proxygen 等开源类库， 由专门的类库来完成这些工作，而不必在每个服务中重复相同的控制逻辑 ：

然而，随着系统中服务数量的增多，这种方式也暴露出了一些问题：

• 胶水部分的资源投入：需要投入资源将第三方库与系统其余部分连接起来

• 类库限制了微服务的技术选型：这些类库通常是特定于平台的，仅支持特定运行时或编程语言，会给微服务的技术选择造成限制。毕竟，微服务的一大特点就是 允许使用不同的编程语言来编写不同服务 ）

• 类库的维护成本：类库本身也需要持续维护升级，每次更新都需要重新部署所有服务，即便服务没有任何改动

这样看来， 类库似乎不是个理想的解决方案

三.将微服务控制下沉到网络栈？

既然在应用层解决不太合适，那么能否如法炮制，下沉到网络栈呢？

与通用的基础通信机制不同，这些应用服务相关的控制机制很难交由下层网络栈来实现，照搬下沉行不通

Sidecar

不能在（服务）里面，也不能在下面，所以最后放到了旁边 ：

即，通过代理来实现这些网络控制，所有出入流量都经过代理，称之为 Sidecar ：

Sidecar 作为辅助进程，随应用程序运行在一旁，并为其提供额外的功能

问题似乎已经通过网络代理完美解决了，业界也出现了一些开源方案：

• Synapse + Nerve

• Prana

然而，这些方案都建立在特定的基础组件之上，例如 Nerve 和 Synapse 基于 Zookeeper ，Prana 基于 Eureka ，而无法适应不同的基础组件

那么， 有没有足够灵活，基础组件无关的解决方案呢？

有。叫 Service Mesh

四.从 Sidecar 到 Service Mesh

如果给每个服务配套一个代理 Sidecar，服务间仅通过代理互相通信，最终得到了类似这样的部署模型：

即， 代理之间相互连接形成了一个网状网格，称之为 Service Mesh（服务网格） ：

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application.

一个专门处理服务间通信的基础设施层，保障复杂服务拓扑中通信的可靠性

具体的，Service Mesh 能够提供Service Discovery、负载均衡、加密、观察/跟踪、身份验证和授权，以及熔断机制等支持：

The mesh provides critical capabilities including service discovery, load balancing, encryption, observability, traceability, authentication and authorization, and support for the circuit breaker pattern.

从 Sidecar 到 Service Mesh，关键在于以更高的视角看待这一个个代理，发现它们形成的网络所具有的价值：

五.Service Mesh + 部署平台

紧接着， Service Mesh 很自然地与（掌控着 Service 的）部署平台擦出了火花 （如 Istio + Kubernetes ），进而衍生出了控制层（Control Plane），让这层基础设施变得配置化：

并最终形成了控制层 + 数据层的上下结构：

其中，管理实例间网络流量的部分称为数据层（Data Plane），数据层的行为由控制层（Control Plane）生成的配置项来控制，而控制层一般会提供 API、CLI 以及 GUI 等多种方式管理应用

即：

参考资料

• Pattern: Service Mesh

• What Is a Service Mesh?

• What’s a service mesh?