携程基于开源体系的云原生微办事 治理实践与探索
用券网信息：一、携程微办事 产品的成长 历程
携程微办事 产品起步于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实践。
目前，多家年夜 型互联网企业和开源社区正在配合 推进该项目的进行，希望能够完成从办事 治理到云原生基础设施的全链路生态笼罩 。
【作者简介】CH3CHO，携程高等 研发经理，负责微办事 、网关等中间件产品的研发工作，存眷 云原生、微办事 等技术领域。
页:
[1]