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轮询）
这种是目前市面上 开源注册中心的核心体系 ， 这一套开发人员介入较多，运维人员介入较少。
2.3 模式三: 独立进程代理
再回顾模式二、 很明显，我们需要针对不同技术语言开发SDk，而且sdk是被发散部署在各应用上(实则脱离管控、碎片化)。
在技术、业务快速迭代、大规模部署实例的现实面前，模式二：[侵入式太强、业务方升级sdk没动力、sdk版本碎片化严重、sdk带包袱演进] 都极其费劲心力。
模型三的核心是将 服务注册、发现功能从原应用中剥离，以独立进程部署
- 独立进程接管服务治理，还可以接手更细粒度的流量调度、负载均衡+鉴权
- 独立进程在物理层面与应用分离 (有的是独立进程部署在主机，由主机上应用共享；有的是一对一部署在应用侧)
模式三因为对应用更加透明，独立进程的部署可能需要 运维人员更多精力, 当然如果是容器/k8s部署独立进程，可以规避很多环境、配置的琐碎差异。
3. ServiceMesh
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 注入的？[1]
- Sidecar proxy 是如何做透明流量劫持的？[2]
总结起来：istio注入sidecar，最好是结合k8s, 使用Init容器做一些劫持配置(修改iptables)
4.2 xDS
基于 xDS[3] 协议提供了标准的控制面规范，并以此向数据面传递服务信息和治理规则。
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中流量的可观察性。
4.2.1 标准xDS流程
这里暂时一带而过，因为请求/响应结构体也很简单， 但是后面我们聊到[增量xDS] 会回过头来看。
xDS协议分析
在实际使用和性能考量中：设计者延伸出两种设计角度：
| 角度 | --- | --- | ---后者-->前者带来了什么？ |
| 维护资源的方式 | 全量传输 | 增量传输 | 性能 |
| 资源下发的方式 | 单链独立资源 | 单链 多资源聚合 | 带来了强一致性的能力 |
这样就对应4种xDS效果：
- State of the World（Basic xDS）：全量传输 独立gRPC stream；
- Incremental xDS：增量传输 独立gRPC stream；
- Aggregated Discovery Service（ADS）：全量传输 聚合gRPC stream；
- Incremental ADS：增量传输 聚合gRPC stream （暂未实现）；
早期的xDS协议是 全量传输 单链接 独立资源， 现在主流的还是全量传输 聚合gRPC Stream (ADS)。
下面我们分析一下 设计者为什么要延伸出两个角度 ？
4.2.2 角度一：ADS （从规避流量损失的角度）
为什么设计者要延伸出这个聚合维度？或者说变更到这个主流方案？
因为有现实需要！
由于Envoy xDS采用最终一致性，部分流量可能在更新时被丢弃。
使用ADS可以解决[无法忍受数据丢弃的场景],
ADS为什么可以做到？
ADS通过一个连接（gRPC同一stream）申请多种资源/接受多种资源。
- 能够保证请求一定落在同一Pilot上，解决多个管理服务器配置不一致的问题。
- 通过顺序的配置分发，轻松解决资源更新顺序的问题。
按照这个方式CDS-EDS-LDS-RDS下发，由Polit控制，规避流量丢失的问题，这就是ADS设计的由来。
4.2.3 角度二：增量xDS （从性能的角度）
[当配置发生变化时，仅下发和更新发生变化的配置部分]
如何实现？
这个时候就要回头看标准XDS协议的流程， 增量 xDS 客户端需要向服务器告知它已拥有的资源从而避免重复发送。
☺️以上便是本次输出的全部内容，因为已知原因略去一些隐私内容，
主要解读了[服务治理]的演进过程、目前主流的 ServiceMesh的核心特征，以及xDS方案的演变过程，相比原中文官网垂直灌输式的输出，本文强调以流畅的思路来清楚表达演变过程，知其然更知其所以然， 如果觉得对你有所帮助，麻烦一键三连。
