政府网站信息资源建设/网站推广seo教程
在service mesh中，我们使用最多的就是sidecar模式，也就是将基础设施管理通过sidecar来承载
经典的 Sidecar Mesh 部署架构有很多优势，如平滑升级、多语言、业务侵入小等，但也带来了一些额外的问题，比如:
Proxy 带来的性能损耗，在复杂拓扑的网络调用中将变得尤其明显
流量拦截带来的架构复杂性
Sidecar 生命周期管理
部署环境受限，并不是所有环境都满足 Sidecar 流量拦截条件
基于此，社区提出了proxyless的解决方案，并且有些开源组件已经开始支持这种proxyless形式。
那么什么是proxyless呢？
顾名思义，其实就是不需要通过sidecar的方式来进行service mesh的处理，也是，本质就是将sidecar实现的功能转移到了框架上（历史的倒退？），与其说是技术的倒退，倒不如说是业务场景的综合考量。
注：ebpf方式也可以看作是另一种形式的proxyless
下面先来看看实现proxyless的基础，那就是要实现xDS协议
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中流量的可观察性。
下面通过gRPC和dubbo这两个当前最流行的微服务框架来讲讲对proxyless的支持
gRPC
gRPC小组正在努力扩展当前的gRPCLB功能。其不再使用自定义负载均衡协议，而是采用基于Envoy xDS API的xDS协议。这将允许与支持xDS API的开源控制平面（例如Istio Pilot，go-control-plane和java-control-plane）进行交互。
为了利用xDS负载均衡，gRPC客户端需要连接到xDS服务器。客户端需要在用于创建gRPC通道的目标URI中使用xds解析器。下图显示了API调用的顺序。
xDS服务器负责发现gRPC服务器的端点并将其传达给客户端。然后，客户端会定期请求更新。
我们使用 Envoy go-control-plane库来实现xDS server。对于部署在Kubernetes中的gRPC的服务，我们可以使用k8s client-go来发现目标EndPoints。
dubbo
随着 Dubbo 3.1 的 release，Dubbo 在云原生的路上又迈出了重要的一步。在这个版本中添加了 Proxyless Mesh 的新特性，Dubbo Proxyless Mesh 直接实现 xDS 协议解析， 实现 Dubbo 与 Control Plane 的直接通信，进而实现控制面对流量管控、服务治理、可观测性、安全等的统一管控，规避 Sidecar 模式带来的性能损耗与部署架构复杂性。
Dubbo 里 xDS 处理的主要逻辑在 PilotExchanger 和各个 DS (LDS、RDS、CDS、EDS) 的对应协议的具体实现里。PilotExchanger 统一负责串联逻辑，主要有三大逻辑：
获取授信证书。
调用不同 protocol 的 getResource 获取资源。
调用不同 protocol 得 observeResource 方法监听资源变更。
例如对于 lds 和 rds，PilotExchanger 会调用 lds 的 getResource 方法与 istio 建立通信连接，发送数据并解析来自 istio 的响应，解析完成后的 resource 资源会作 为rds 调用 getResource 方法的入参，并由 rds 发送数据给 istio。当 lds 发生变更时，则由 lds 的 observeResource 方法去触发自身与 rds 的变更。上述关系对于 rds 和 eds 同样如此。现有交互如下，上述过程对应图里红线的流程：
在第一次成功获取资源之后，各个DS会通过定时任务去不断发送请求给 istio，并解析响应结果和保持与 istio 之间的交互，进而实现控制面对流量管控、服务治理、可观测性方面的管控，其流程对应上图蓝线部分。
https://jimmysong.io/blog/beyond-istio-oss/#performance-optimizing
http://www.uml.org.cn/yunjisuan/202109244.asp
http://limeng.org/2020/03/08/xds-in-grpc.html