作者简介

CH3CHO，携程高级研发经理，负责微服务、网关等中间件产品的研发工作，关注云原生、微服务等技术领域。

一、携程微服务产品的发展历程

携程微服务产品起步于2013年。最初，公司基于开源项目ServiceStack进行二次开发，推出.Net平台下的微服务框架CServiceStack。

2014年，公司推出Java平台下同CServiceStack完全互通的自研微服务框架Baiji和第一代服务注册中心。该服务注册中心后续经历多次重构，目前使用的已是第四代产品。

2017年,公司正式引进开源产品Dubbo，推出整合携程治理能力的CDubbo框架。该框架最初基于Dubbo 2.5.4版本进行二次开发，经历多次版本升级后，目前使用Dubbo 2.7.7版本。

2020年,公司正式开始探索落地Service Mesh项目。目前，相关产品已经在生产环节正式落地，正在进行接入推广工作。

携程微服务产品情况复杂，主要在于以下四点。

第一，线上同时运行着三种微服务框架产品。

第二，同时采用HTTP和Dubbo两种通信协议。

第三，采用完全自研的基础设施，包括注册中心和配置中心。

第四，现存8000多个线上服务，实例数超过10万个。

随着研发的深入，我们团队主要遇到了以下三点问题。

第一，维护多个功能类似的中间件产品工作量较大，保证产品之间功能对齐需要花费大量的精力。

第二，由于产品以SDK公共依赖包的形式集成在业务应用内，进行版本升级需要业务方配合，推动升级比较困难，版本长尾问题严重。

第三，由于团队工作精力和技术栈的限制，只有少数几个语言平台上存在SDK支持，不利于小众语言用户使用微服务产品。​

二、携程的云原生微服务架构设计

由于线上集群已初具规模，如何平滑过渡和迁移框架成为关键问题。彻底抛弃现有基础设施，一步到位实现全面云原生，不仅实施难度较大，项目周期也比较长。

因此，项目决定采用“小步快走”的方式。首先保证代码完全向后兼容，其次保证整体架构支持业务应用迁移，提升接入容错率。

项目进行架构设计时，遇到了三个关键的问题。

数据权威问题：常见的Service Mesh实践以K8s为准则，将所有的数据保存在K8s内，但平台现有数据大部分保存在自研的注册中心和配置中心内。

有方案提出采用两条推送路的方式，云内数据保存在K8s内，云外数据保存在现有注册中心里，通过外部工具或组件实现双向同步。但双向同步复杂度较高，既要保证数据的准确性和实时性，也要保证同步不成环。

因此，出于架构简便性考虑，项目最终选择保持注册中心数据权威地位不变，通过外部组件将数据写入K8s。

边界划分问题：目前的项目部署体系是一个Region内包含多个Zone，一个Zone内又包含多个K8s集群，集群之间网络互通。但由于故障隔离的需要，数据最好保持在Zone内收敛，使实例信息不需要进行跨Zone同步。

Zone内收敛存在的问题是当调用方发起跨Zone调用时，需要经过网关进行中转。这种调用方式和现有的调用链路存在差异，会提高计算复杂度。

因此，项目最终选择保持现有工作模式不变，使得调用方能够获取Region内所有的Zone服务实例，保持数据在Region内透明。

技术选型问题：过去，项目研发产品大部分采用自研模式，通过整个团队成员协作完成开发工作，而依托开源社区能够更容易地产出优秀产品。

因此，项目最终选择基于开源产品进行二次开发。

目前所使用的Service Mesh架构设计，也被称为“渐进性”架构，主要有三个方面的特点。

开源方面：选择Istio和Envoy作为Service Mesh的基础设施。

实例和配置同步方面：由新开发的SOA Operator负责将存储在注册中心和配置中心中的数据写入K8s。

同时，该程序也会把K8s集群内服务提供方的数据写入注册中心，使得K8s集群外用户也能够正常读取服务数据。并且，该服务不需要SDK支持，由SOA Operator直接完成注册和发现，任何语言都可以方便地接入微服务产品体系。

使用方面：K8s集群外的应用仍然使用过去的交互方式，通过SDK和注册中心进行通信。

K8s集群内的应用，如果使用SDK，检测到Sidecar存在之后，SDK会自动地关闭服务治理功能，使用特殊的host进行请求。如果不存在SDK支持，接入Mesh可以直接使用HTTP Client，继续使用特殊的host发起请求。

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实践。

目前，多家大型互联网企业和开源社区正在共同推进该项目的进行，希望能够完成从服务治理到云原生基础设施的全链路生态覆盖。