饿了么 Dubbo 实践分享

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
可观测可视化 Grafana 版,10个用户账号 1个月
简介: 饿了么从 2021年 11 月启动 Dubbo3 升级工作。在此之前,饿了么使用 HSF2 作为服务框架。升级过程历史半年,目前已基本完成,共有将近 2000 个应用和 10 万个节点运行在 Dubbo3 之上。

饿了么 Dubbo 实践分享

——刘军

阿里云-云原生应用平台,Apache Dubbo PMC

 

饿了么从 2021 11 月启动 Dubbo3 升级工作。在此之前,饿了么使用 HSF2 作为服务框架。升级过程历史半年,目前已基本完成,共有将近 2000 个应用和 10 万个节点运行 Dubbo3 之上。

一、Dubbo 3 简介

image.png

Dubbo3 是下一代云原生微服务框架。设计原则上, Dubbo3 面向云原生支持百万集群实例可伸缩,强调柔性和智能化流量调度策略上,Dubbo3 完全开源业务价值上,Dubbo3 更强调降低单机资源消耗,提升全链路资源利用率以及云原生时代服务治理能力。


Dubbo3 Dubbo2.0 架构演进而来,继承开源 Dubbo2 以及阿里内部演进多年 HSF2 完整特性优点,并且保持对 Dubbo2 HSF2 完全兼容。因此老用户几乎实现 Dubbo3 0 成本迁移。


Dubbo3 提供核心特性主要以下四个

① 全新服务发现模型。

② 提供基于 HTTP /2 Triple 协议。

③ 统一流量治理模型,支持更丰富的流量治理场景。

④ Service Mesh模型:提供Sidecar Mesh ProxyLess Mesh 两种部署架构。

image.png

Dubbo3 基于 Dubbo2 HSF2 两款产品诞生,同时以云原生架构作为指导思想,进行了大量重构,并规划一系列功能性。在开源 Dubbo3 产品之上,有基于 Dubbo3 企业用户实践生态产品以及公有云厂商云产品,有大家比较关心 Dubbo3 典型用户阿里巴巴


在此之前,阿里巴巴一直运行在自研 HSF2 框架之上。虽然 HSF2 Dubbo2 有很多相似之处,但如今已经演进成两个不同框架实现 Dubbo3 HSF2 Dubbo2 融合后,阿里巴巴完全迁移到Dubbo3


开源Dubbo3,如何满足阿里特有诉求?答案是:通过 Dubbo3 开源标准 SPI扩展。因此阿里内部现在还有一套 HSF 3,与以往 HSF 2 完全不同,已经是两个不同的框架。


HSF3基于标准 Dubbo3 SPI 生成扩展库,但也仅仅是一个扩展库,比如注册中心扩展路由组件扩展或者监控组件扩展,而其他配置组装服务暴露服务发现、地址解析等核心流程已经完全跑在 Dubbo3 之上。


模式之下,阿里巴巴内部的实现诉求将完全体现在开源Dubbo3 之上。阿里巴巴内部开发人员同时工作在 Dubbo3 以及内部扩展SPI HSF3之上。


通过 SPI 扩展的模式同样适用于公有云产品或其他厂商实践。

image.png

升级到 Dubbo3 后,能够获得以下三方面的收益:


① 性能和资源利用率提升升级 Dubbo3 后,预期能够实现单机资源接近 50%资源利用率下降集群规模越大,效果越明显。同时Dubbo3 从架构上支持百万实例级别集群横向扩展。


② 助力业务架构升级:借助于 Dubbo3 提供新协议能够让业务架构升级得到更多帮助。比如此前,从前端应用接入到后端,需要经过网关代理而网关需要进行协议转换或类型映射工作,因此往往会成为架构瓶颈。有了 Triple 协议后,过程变得更容易实现同时提供流式通信模型更丰富通信场景支持。


③ 云原生:屏蔽了基础设施层变革,降低 Mesh 升级成本,提供了更丰富的流量治理模型

image.png

Dubbo 从设计之初就内置服务发现能力。 Provider 注册地址到注册中心,Consumer 通过订阅实时获取注册中心地址并进行更新。接收到地址列表后,Consumer 基于特定负载均衡策略发起对Provider RPC 调用,如上图所示。过程中,每个Provider通过特定 key 向注册中心注册本机可访问地址,而注册中心通过 key Provider 实例进行地址聚合。 Consumer 通过同样 key 从注册中心订阅,以便实时收到聚合后地址列表。

image.png

Provider部署应用通常有多个 Dubbo Service 每个 Service 可能都有独有配置。Service 服务发布过程就是基于服务配置生成地址 URL 过程生成地址数据就如上图橙色部分 URL 所示同样其他服务也会生成地址,即 Dubbo 实例会生成多个 Service URL


注册中心以 Service 服务名作为数据划分依据,将服务下所有地址数据都作为子节点进行聚合。子节点内容是实际可访问 IP 地址, Dubbo URL

image.png

URL 地址数据的详细格式可划分成个部分


① 实例可访问地址消费端将基于这条数据生成 TCP 链接,作为后续 RPC 数据传输载体。


② RPC 服务元数据主要是用于定义和描述一次 RPC请求表明这条地址数据是与某条具体 RPC 服务有关,比如接口名、版本号分组以及方法定义等。


③ RPC 相关配置数据配置用于控制 RPC 调用行为,有些用于同步 Provider 端进程实例状态到消费端典型配置超时时间序列化编码方式。


④ 业务自定义数据:主要用于区分以上框架预定义各项配置,用户提供更大灵活性。用户可以进行任意扩展,将状态同步到消费端。


结合上面对 Dubbo2 接口及地址模型分析,可以得出 Dubbo 服务治理易用性的秘密:首先在接口服务发现模型地址发现聚合 Key 等于 RPC 粒度的服务,比如在 Java 中定义 Dubbo 服务接口;其次,注册中心同步数据不只包含地址,还包含各种数据以及配置;最后,得益于前面两点Dubbo 可支持各种不同粒度的服务治理,比如应用粒度RPC 服务粒度以及方法粒度


Dubbo 在地址通知过程中同步数据非常丰富是一直以来 Dubbo2 在易用性、服务治理功能性、可扩展性方面强于很多其他框架核心原因。

image.png

然而,Dubbo2 地址模型虽然带来易用性和强大功能,但在实践过程中也逐渐发现架构水平可扩展性上出现了限制。这个问题在普通微服务集群下通常感知不到当集群规模逐渐增长,集群内应用和机器达到一定数量时,集群内组件就会开始出现规模瓶颈。主要存在以下两个突出问题,如上图橙色所示:


由于所有 URL 地址数据都被发送到注册中心,注册中心存储容量容易达到上限,推送效率也会下降消费端侧,Dubbo2 框架常驻内存通常已经占用超过业务进程40%每次地址推送带来动态 CPU 资源消耗或资源波动也非常明显,甚至影响正常业务调用。


通过DubboProviderr蓝色部分)实例来分析以上问题出现的原因。假设有一个普通 DubboProvider 应用,应用内部有 10 RPC Service Dubbo服务应用被部署在 100 个机器实例之上。那么,应用在集群中产生数据量10*100,即 1000 URL 数据。


数据从两个维度放大。从地址角度,有 100 个机器实例,100 条唯一地址数据被放大 10 从服务角度,因为服务元数据在应用内都是唯一元数据,被地址数放大 100 倍。

image.png

面对上述问题,在 Dubbo3 架构下,我们不得不深入思考如何在保留应用性和功能性同时,重新组织 URL 地址数据,避免冗余数据出现,使 Dubbo3 能够支撑更大规模水平扩容;其次,还需解决如何在地址发现层面与其他微服务体系打通

image.png

在地址发现链路上,接口级聚合元素Key RPC 服务。在应用级发现中,设计思路是将聚合 Key 由服务调整为应用。另外通过对注册中心数据大幅精简,只保留最核心IP port,使应用发现链路传输地址数据量得到大幅度精简。

image.png

上图为升级后应用级服务发现内部数据结构。之前接口级地址发现模型不同主要在于图中橙色部分。Provider 实例侧相比于此前每个 RPC Service 都注册一条地址数据,升级后的 Provider 部署机器实例只注册一条地址到注册中心。注册中心侧地址开始以应用名为粒度进行聚合应用名节点下是精简后Provider 及实例新生成 URL 已经只包含 IP port

image.png

应用级发现经过上述调整,实现地址单条数据大小和地址总数量下降,但也带来新挑战——基本损失了此前 Dubbo2 强调易用性和功能性,因为数据传输被精简掉如何精细地控制单个服务行为变得无法实现。


针对上述问题,Dubbo3 解法是引入内置元数据服务 MetadataService 在引入元数据服务后,此前由注册中心Provider 同步数据行为转变为点对点拉取行为,消费端在收到纯粹 IP port 地址通知后,会通过 MetadataService 找到对应的 Provider 进行点对点元数据读取。


模式下,元数据传输数据量不再是问题甚至于可以在数据服务或数据内容之上扩展出更多参数,暴露出更多服务治理。

image.png

上图为 Dubbo 应用级服务发现的基本工作原理,重点看 Consumer 地址订阅行为。


消费端分两步来完成地址读取以及组装工作。首先从注册中心收到精简后IP port 地址后,通过调用 MetadataService元数据读取到对端元数据信息。收到这两份数据后,再由消费端完成地址数据聚合最终在运行态还原出类似Dubbo2 URL 地址格式。从运行态最终结果而言,应用级地址模型同时兼顾传输层面性能与运行层面功能性。


三、饿了么 Dubbo3 升级过程

image.png

上图为饿了么基本部署架构图。


升级之前,饿了么微服务框架采用HSF2跨单元 RPC 调用通过中间Proxy中心化部署代理完成中转。过程中 Proxy 所承载机器数和流量有迅速增长。与应用级服务发现地址发现模型相关,比较突出一点是 Proxy 需要订阅两侧所有地址数据。因此在存储和数据聚合方面,资源消耗和稳定性都受到严重挑战。


因此,我们期望通过升级 Dubbo3 结合整个架构升级来解决通过 Proxy 集中式流量调度以及 Proxy 面临地址存储和推送压力。主要期望实现两个目标


第一,将地址模型切换到应用级服务发现地址模型,从而大幅度减轻中心化节点和消费端节点资源消耗压力


第二,以应用级服务发现架构下全局共享注册中心取代 Proxy 需要订阅两侧不同注册中心模型,实现跨单元节点通信直连。

image.png

Dubbo3 对此前的 Dubbo 2 HSF2 全面 API 兼容因此,饿了么升级到 Dubbo3 可以实现零改造升级并且每个应用都可以进行独立升级,不需要关心上下游应用升级状态。 Dubbo3 升级后,不论从地址发现模型还是协议默认行为,都保持与 2.0 版本兼容,用户可以在任意时间点对任意应用按需切换。


上图右侧模拟展示饿了么集群在 Dubbo3 升级过程中间状态其中灰色代表没有升级HSF2 老应用,橙色和绿色代表已经升级到 Dubbo3 应用,其中橙色表示已完成迁移,绿色代表已升级但未迁移


上图升级过程可以说明两点Dubbo3 框架升级在 API 和默认行为方面是完全兼容的;另外集群内应用以及升级到Dubbo3 以后地址行为切换行为是完全独立

橙色部分往发现模型迁移时具体操作如何?

image.png

首先看 Provider 端行为。Provider 在升级 Dubbo3 以后会默认保持双注册行为,即同时注册接口级地址和应用级地址一方面是为了保持兼容性,另一方面为未来消费端迁移做好准备。


双注册行为对于注册中心带来额外压力在应用级服务发现模型下并不是问题。每增加一条应用及服务发现 URL 地址,只会带来 0.1% - 1% 额外开销。

image.png

Consumer 端与 Provider 类似,要实现平滑迁移,消费端地址模型不可避免地要做双订阅过程。


消费端双订阅行为可以通过规则和开关进行动态调整,控制消费端消费某个服务某个应用独立迁移到应用地址模型。除此之外,Dubbo3 还内置自动决策机制并默认开启,在发现应用地址可用情况下,即可自动完成从接口地址到应用地址切换。

image.png

Dubbo 基本工作原理比较简单,其核心是围绕提供者、消费者注册中心三个节点数据同步。饿了么在升级 double3 应用级发现模型后,成功实现了去 Proxy 总体架构目标。


Dubbo3 可以实现透明兼容升级,并且能够按需切换地址模型行为。Dubbo3在饿了么升级,代表阿里巴巴内部真正意义上实现对于 HSF2替换,并且迁移到新的应用级地址服务发现模型。

 

相关文章
|
1月前
|
XML Dubbo Java
【Dubbo3高级特性】「框架与服务」服务的异步调用实践以及开发模式
【Dubbo3高级特性】「框架与服务」服务的异步调用实践以及开发模式
49 0
|
1月前
|
负载均衡 监控 Dubbo
从理论到实践:Dubbo 的 `<dubbo:service>` 与 `<dubbo:reference>` 全面指南
从理论到实践:Dubbo 的 `<dubbo:service>` 与 `<dubbo:reference>` 全面指南
36 0
|
1月前
|
监控 负载均衡 Dubbo
分布式架构与Dubbo基础入门与实践
分布式架构与Dubbo基础入门与实践
40 1
|
8月前
|
监控 Dubbo Cloud Native
Apache Dubbo 云原生可观测性的探索与实践
Apache Dubbo 云原生可观测性的探索与实践
116854 3
|
8月前
|
运维 Dubbo 安全
政采云基于 Dubbo 的混合云数据跨网实践
政采云基于 Dubbo 的混合云数据跨网实践
|
10月前
|
存储 运维 监控
Apache Dubbo 云原生可观测性的探索与实践
Apache Dubbo 已接入指标、链路、日志等多维度观测能力,助力云原生实践,本文将介绍 Dubbo 可观测性的探索与实践。
Apache Dubbo 云原生可观测性的探索与实践
|
8月前
|
Kubernetes Dubbo 应用服务中间件
GitHub标星35k+微服务深度原理实践进阶PDF,竟让阿里换下了Dubbo
最近一个粉丝分享了他悲惨的阿里面试故事,好不容易冲进三面,最后凉了! 关键在于微服务部分没回答好。 本人自己说在看到这些面试真题之后人都是懵的,之前这方面也没有很重视,结局就很可惜了。 今天先结合我这个粉丝的经历和面的题,分析一下微服务,以及我在这方面的学习经验也给大家分享一下。
|
机器学习/深度学习 运维 Dubbo
全国首个政企采购云平台:政采云基于 Dubbo 的混合云跨网方案实践
全国首个政企采购云平台:政采云基于 Dubbo 的混合云跨网方案实践
全国首个政企采购云平台:政采云基于 Dubbo 的混合云跨网方案实践
|
自然语言处理 Kubernetes Dubbo
Dubbo3 在同程旅行的实践
目前 Dubbo3 在公司的落地开发工作已经完成,通过本文我们对公司内部 Dubbo3 的实践及收益做了深入总结。
144 0
Dubbo3 在同程旅行的实践
|
XML Dubbo Java
Dubbo3 入门实践:如何使用 Spring Boot 方式快速开发 Dubbo 应用
> 示例演示了如何使用 Spring Boot 方式快速开发 Dubbo 应用 > Dubbo 还提供了包括[XML](../../reference-manual/config/xml)、[API](../../reference-manual/config/api)等多种启动与接入方式,更多开发方式和配置细节可参见[配置手册](../../reference-manual/config/)。
342 0