基于开源体系的云原生微服务治理实践与探索

作者：董艺荃｜携程服务框架负责人

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

携程微服务产品起步于 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 实践。

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