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

作者简介

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

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