服务治理演进剖析 & Service Mesh、 xDS核心原理梳理

阅读原文时间：2021年05月22日阅读：1

基于XDS协议实现控制面板与数据面板通信分享

基于这段时间在同程艺龙基础架构部的蹲坑，聊一聊微服务治理的核心难点、历史演进、最新动态，以上内容属自我思考，不代表同程艺龙技术水准。如理解有偏差、理解不透彻、现状梳理不清楚的请大家多指教。

大纲

微服务治理的核心难点
方案演进的法宝：代理模式

2.1 集中式代理

2.2 客户端嵌入Sdk代理

2.3 主机独立进程
Service Mesh是模式三

3.1 目前现状 & 建议取舍
istio是一种开源的Service Mesh实现

4.1 关键能力 & 平台支持

4.2 XDS协议

- 4.2.1 标准xDS协议

- 4.2.2 设计者为什么引入ADS角度？

- 4.2.3 设计者为什么引入Increment xDS角度？

4.3 基于同程艺龙服务治理现状的一点看法

1.微服务治理的难点

在服务很少的情况下，直观的讲： A---> B， A如何知道B服务的实例？A是不是要使用某种负载均衡策略去请求B？

作为服务治理技术的演进，根源就在于此。

现代分布式体系，服务越来越多、服务的实例数也越来越多、互相调用犬牙交错、服务环境多且切换频繁。

技术上提出代理模型来统一管理服务注册/发现、负载均衡。

2.演进的法宝：代理

截止目前，从宏观上讲，演进出三种代理模型，并且并不强调哪种是最佳，适合的才是最好的。

2.1 模式一：集中式代理

服务数在个位数、服务实例可枚举的中小体系，可以采用这种集中代理模型，一般选用nginx负载均衡器

因为直观、简单，由开发人员或者框架组在代理上手动配置。
容器、K8s应该内置了服务注册、服务发现功能，倒是不需要手动去配置ip和端口

2.2 模式二：客户端嵌入sdk代理

从代理功能，强化分离出独立的服务注册模块

直接变化是： A直接请求B，但是A预先（随时感知到）B
这种就比模型一智能一点：服务B自行注册、服务A自行发现，这个“自行”都是通过sdk实现
核心的服务注册、发现在逻辑上与应用分离
很明显，独立的Service Registry现在除了关注自己

的核心功能外，还要负责接受心跳、维护实例状态，通知调用方服务实例变更（可能通过推送或sdk轮询）

这种是目前市面上开源注册中心的核心体系，这一套开发人员介入较多，运维人员介入较少，同程艺龙老版DSF就类似这样的结构

2.3 模式三: 独立进程代理

再回顾模式二、很明显，我们需要针对不同技术语言开发SDk，而且sdk是被发散部署在各应用上(实则脱离管控、碎片化)。

在技术、业务快速迭代、大规模部署实例的现实面前，模式二：[侵入式太强、业务方升级sdk没动力、sdk版本碎片化严重、sdk带包袱演进] 都极其费劲心力。

模型三的核心是将服务注册、发现功能从原应用中剥离，以独立进程部署

独立进程接管服务治理相关，还可以接手更细粒度的流量调度、负载均衡+鉴权
独立进程在物理层面与应用分离 (有的是独立进程部署在主机，由主机上应用共享；有的是一对一部署在应用侧)

模式三因为对应用更加透明，独立进程的部署可能需要运维人员更多精力, 当然如果是容器/k8s部署独立进程，可以规避很多环境、配置的琐碎差异。

3. Service Mesh

Service Mesh 基于模式三，它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。

但比模式三更加抽象和纯粹。

将模式三的Service Registry抽象为控制面，可以对接多种服务注册Provider（k8s、Consul等）

这个与模式二、三显式[服务注册--服务发现]还不一样，从[服务发现]升级为[请求分发]， Service Mesh不做[服务注册]的功能，由集群内生机制将服务实例注册到控制面

强调了在“基础设施层”处理服务通信。
它不是"服务"的网格, 而是“代理”的网格

数据层截获不同服务之间的调用并对其进行“处理”；控制层协调代理的行为，并为运维人员提供 API，用来操控和观测整个网络.

优势

服务治理和应用逻辑解耦
利用控制面API与服务注册中心解耦
通过将服务治理能力下沉到基础设施，支持了异构系统的统一治理

劣势

因在基础设施层劫持流量，需要高级运维和开发通力配合
网络拓扑更加复杂，监测定位排障变得更加困难
从调用链路看，服务网格是侵入式的，有毫秒级别的延迟

3.1 现状& 选型

服务不会频繁变更、服务实例不多的中小项目可以采用经典的集中式代理模式，稳定直观。

强调服务集成的中型项目可以采用客户端嵌入sdk 服务注册、发现；

强调流量调度的中大项目可以采用 Service Mesh 模式。

作为一个企业，如果你的微服务应用已经具有了非常完备的服务治理能力，那么你不一定非得引入 Service Mesh。但是假设你的系统并不具有完善的治理功能，或者系统架构中的痛点正好可以被 Service Mesh 所解决，那么使用 Service Mesh 就是你的最佳选择。

4. Istio是Service mesh的实现

4.1 istio的能力

为 HTTP、gRPC、WebSocket 和 TCP 流量自动负载均衡。
通过丰富的路由规则、重试、故障转移和故障注入对流量行为进行细粒度控制。
提供完善的可观察性方面的能力，包括对所有网格控制下的流量进行自动化度量、日志记录和追踪。
提供身份验证和授权策略，在集群中实现安全的服务间通信。

支持的平台：

Kubernetes
Consul
GCP

这里面穿插几个已有答案的疑问？

Istio 中是如何做 sidecar 注入的？
Sidecar proxy 是如何做透明流量劫持的？

总结起来： istio注入sidecar，最好是结合k8s, 使用Init容器做一些劫持配置(修改iptables)

4.2 XDs

基于 xDS 协议提供了标准的控制面规范，并以此向数据面传递服务信息和治理规则。

xDS是由Envoy贡献给istio，现在已经作为sidecar的标准协议。

v1 xDS API. 传统的REST-JSON API，现在已经是ProtoBufffer和 REST/gRPC api

v2 xDS API. 21年初停用

xDS 是一组发现服务的总称，包含LDS，RDS，CDS，EDS以及SDS。

Envoy 通过xDS API 可以动态获取Listener(监听器)，Route(路由)，Cluster(集群/服务)，Endpoint(集群成员/服务实例)以及Secret(秘钥)配置。

**xDS协议是基于gRPC实现的传输协议，即Envoy通过gRPC streaming订阅Pilot的资源配置。

Pilot借助ADS对API更新推送排序的能力，按照CDS-EDS-LDS-RDS 的顺序串行分发配置。**

利用XDS协议，Envoy可以实现配置的完全动态化，配置实时更新而无需重启Envoy或者影响业务，此外，利用其L3/L4/L7 Filter机制，Envoy可以完全无侵入的扩展各种强大的功能。利用其内置的Tracing机制和Stats模块，可以很方便的实现对流量的跟踪以及监控，保证Envoy中流量的可观察性。