更多精彩内容，欢迎观看：
《云计算加速开源创新》——基于开源体系的云原生微服务治理实践与探索（上）：https://developer.aliyun.com/article/1223963?spm=a2c6h.13148508.setting.18.68ac4f0eE1VQvG
HTTP协议在Service Mesh架构上运行良好，但Dubbo协议在Sidecar网关上存些一些问题。
其一，元数据的位置：HTTP协议中元数据位于报文最前端，而Dubbo协议中元数据位于报文末端，因此需要先解析报文才能定位到元数据位置。
其二，序列化问题：解析报文需要对报文进行反序列化处理，目前Envoy支持Dubbo默认序列化协议。但这种方式会产生额外开销，而且Dubbo服务使用的序列化器复杂，甚至还有一些团队为进一步降低报文大小，使用了压缩算法，网关解析难度大。
Dubbo 3推出了Triple，这是一种使用基于HTTP/2的gRPC并通过请求标头实现元数据信息传递的通信协议，也是Dubbo 3中推荐使用的服务通信协议
Triple协议适用于Envoy框架，且能轻松接入Service Mesh。Dubbo版本升级也并不复杂。
由于gRPC的PB序列化格式，Triple协议无法直接使用。尽管Triple协议对PB兼容性较好，但PB要求先写契约再生成代码，而Dubbo要求先写代码，不存在契约，数据模型也是与PB对象完全不同的POJO格式。
为了连接POJO和PB对象，Triple协议设计了Wrapper。将原POJO对象序列化处理得到二级数据后，传入到Wrapper用PB进行序列化。
然而，这种方式不仅会导致内存占用变大，而且会引发更多的GC。多次GC和重复序列化将会增大CPU负载。
为解决Triple协议带来的问题，项目给gRPC添加了自定义序列化器。这样不仅可以实现流式的序列化，也可以为用户提供和原生Dubbo一样的使用体验。
其他语言想要调用这种gRPC服务，只需要具备这种自定义序列化器即可，默认的自定义序列化器JSON可以被大部分语言解析。
治理方面，Service Mesh使用Istio和Envoy作为基础设施，通过Istio读取K8S中CRD数据，并生成配置推送给Envoy。
因此，保存在自研服务治理系统里内的实例数据、配置数据必须全部转化成CRD格式，同步到K8S以供Istio处理。
Operator作为翻译机包含了大量模型转换逻辑，能够将配置模型翻译成CRD模型。针对一些复杂的功能，项目通过Envoyfilter或者Envoy的二次开发，添加自定义的Envoyfilter进行实现。
目前，所有的常用功能都已完成对齐，整体功能覆盖率超90%。数千个线上应用完成接入，进入后续接入推广工作。
三、 云原生微服务产品的未来发展趋势
Service Mesh提供的都是通用能力，如分组、路由、流量控制、负载均衡等。这些功能本身没有语义，一线的业务研发和运维人员理解起来存在一定困难。
而且，该产品功能与现存治理系统的功能存在差异。为了给一线人员提供更好的微服务治理体验，需要将实际运维需求和底层控制数据联系起来。
目前，社区内Dubbo Mesh的研发工作也在积极进行，其做法跟携程云原生微服务治理框架类似。通过单独的控制面将配置数据写到K8S里，将实例数据通过MCP进行同步。
另外，新的开源产品OpenSergo也在研发中。据官方介绍，该项目力图打造一套通用的面向云原生的微服务治理标准，并且提供一系列的API和SDK实践。
目前，多家大型互联网企业和开源社区正在共同推进该项目的进行，希望能够完成从服务治理到云原生基础设施的全链路生态覆盖。
