业务全面上云后，今年双11，阿里巴巴微服务技术栈全面迁移到开源标准以Dubbo3为代表的云端中间件系统。在业务方面，基于Dubbo3，首次实现了关键业务不间断推送、不降级的全面用户体验提升。技术上，研发运维效率大幅提升，地址推送等部分关键场景资源利用率提升40%以上，基于TrinityDubbo3开源中间件体系，打造了阿里云上单元化的最佳实践和统一的标准，同时为开源社区贡献了大规模的实践经验和技术创新，成为核心源和微服务开源技术和标准制定的来源。推动力。面对百万级集群实例，实现关键环节不间断推送，资源利用率大幅提升的关键是Dubbo3中新引入的应用级服务发现。下面重点讲解Dubbo3应用级服务发现的详细解决方案，并通过饿了么的案例讲解其升级迁移过程。饿了么在去年11月份就开始了Dubbo3相关的升级工作。在此之前，饿了么的服务框架使用的是HSF2。从HSF2到Dubbo3的整体升级过程历时半年，目前已经基本完成，近2000个应用，10w个节点已经运行在Dubbo3上。通过这次分享，主要是想和大家分享一下饿了么的Dubbo3升级经验，为什么要升级Dubbo3，升级的具体过程，以及中间遇到的问题，尤其是饿了么的应用级服务发现模型重点是，如何完成地址发现模型的升级和最终效果。当然，在此之前，我们先对Dubbo3和应用级服务发现做一个全面的介绍。关于Dubbo3的介绍，希望通过这一部分，让大家了解Dubbo3是什么，与2.7架构的主要区别有哪些，提供了哪些特性，可以解决哪些实际问题；也包括大家关心兼容性和升级成本。以及与HSF2等的关系。我们将Dubbo3定义为下一代云原生服务框架，那么3.0架构到底包含了什么？我们来看看3.0的一些核心设计原则：首先，从架构层面，Dubbo是为云原生而设计的，支持超大规模微服务集群的实践——百万级实例，期望提升系统稳定性通过智能流量调度系统和吞吐量；在战略层面，Dubbo3核心将毫无保留开源，成为国内公有云事实标准的服务框架，得到各大公有云厂商的支持，通过灵活的SPI扩展机制支持不同的部署方式从商业价值来看，Dubbo3将显着降低单机资源消耗，提升全链路资源利用率和服务治理效率。这是3.0设计过程中遵循的核心原则或目标，让我们可以从更高的层次去理解Dubbo3。在选择Dubbo3框架的时候，一定要关心Dubbo3提供了哪些新功能。如果你是Dubbo的老用户，你也会关心Dubbo3的兼容性问题。总结起来就是Dubbo3的迁移成本，以及它能带来的核心价值。左边部分是对Dubbo3兼容性和来源的详细说明。首先，Dubbo3是从自身的2.0架构演化而来的，因此它几乎继承了2.0的所有特性，同时保持了对Dubbo2的全面兼容。因此，老用户几乎可以零成本迁移到Dubbo3。Dubbo3是在企业实践经验的基础上演化而来的。我们知道，Dubbo最初是阿里开源的，贡献给了Apache社区。此次阿里也将Dubbo3定位为其下一代服务框架。因此，Dubbo3集成了HSF2的几乎所有服务治理特性，在阿里巴巴已经开始全面替代HSF2框架，这个我们在后面的企业实践部分会讲到。右边是Dubbo3提供的核心特性列表，主要包括四个部分。一种新的服务发现模型。应用粒度服务发现，云原生设计，适应基础设施和异构系统；性能和集群可扩展性大大提高了下一代RPC协议Triple。基于HTTP/2Triple协议，兼容gRPC；网关穿透力强，多语言友好，支持ReactiveStream统一流量管理模型。针对云原生流量治理，SDK、Mesh、VM、Container等统一治理规则；支持更丰富的流量治理场景ServiceMesh。SidecarMesh和ProxylessMesh，更多的架构选择，更低的迁移和落地成本这张图更直观地反映了Dubbo3的背景以及与一些重要产品的关系。Dubbo3的诞生是基于Dubbo2和HSF2的产品。同时以云原生架构为指导思想进行了大量重构，规划了一系列功能特性；这些共同构成了Dubbo3，也就是我们的github仓库和开源官网。参见Dubbo3；在开源的Dubbo3产品之上，我们有基于Dubbo3的企业实践用户、生态产品、公有云厂商的云产品。比如大家比较关心的Dubbo3典型用户阿里巴巴，在此之前一直在自研的HSF2框架上运行。当然，鉴于HSF2和Dubbo2的历史有很多相似之处，它们实际上已经演变成两个不同的框架，在实现了Dubbo3的融合之后，阿里巴巴正在用开源的Dubbo3全面替代HSF2；说到这里，可能有朋友会问，如何充分利用开源的Dubbo3来满足阿里自身的独特需求？答案是通过SPI扩展，所以现在阿里有一套HSF3，HSF3和之前的HSF2完全不一样。HSF3完全基于标准的Dubbo3SPI扩展库，如注册中心扩展、路由组件扩展、监控组件扩展等，而其他核心流程如配置组装、服务暴露、服务发现、地址解析等都运行在Dubbo3上;在这种模式下，阿里巴巴内部的实际诉求将充分体现在开源的Dubbo3上，包括内部开发人员也在开源的Dubbo3之上工作。SPI扩展也适用于其他厂商的公有云产品和实践。首先是性能和资源利用率的提升。升级Dubbo3的应用有望实现单机内存降低50%，对于更大的集群效果会更明显。Dubbo3从架构上支持百万级实例级别的集群水平扩展，依赖于应用级服务发现和Triple协议。大幅提升应用的服务管理效率和吞吐量。其次，是Dubbo3让业务架构升级变得更简单、更合理。怎么理解呢？最值得关注的是协议。在2.x版本中，web端、移动端和后端之间的通信必须通过网关代理来完成协议转换、类型映射等工作。三重协议使这些变得更加容易和自然；通过流式通信模型满足更多业务场景。最后，得益于Dubbo3完善的云原生解决方案，Dubbo3可以帮助企业屏蔽底层云原生基础设施细节，让业务迁移成本更低。接下来重点讲解Dubbo3应用级服务发现的详细解决方案，这也是饿了么升级目标中最重要的部分。先从Dubbo最经典的工作原理图说起。Dubbo从设计之初就内置了发现服务地址的能力。提供者向注册中心注册地址，消费者通过订阅从注册中心获取实时地址更新。Consumer收到地址列表后，根据特定的负载均衡策略向Provider发起RPC调用。在这个过程中，每个Provider通过特定的密钥向注册中心注册本地可访问的地址；注册中心通过这个key聚合provider实例的地址；消费者通过同一个密钥向注册中心进行订阅，从而及时收到聚合后的地址列表；这里，我们对接口级地址发现的内部数据结构进行详细分析。首先看右下角provider实例内部的数据和行为。Provider部署的应用中通常有多个Service，即Dubbo2中的Service。每个服务可能有自己独特的配置。我们所说的发布服务服务的过程，其实就是根据这个服务配置生成一个地址。URL流程，生成的地址数据如图；同样，其他服务也会生成地址。然后，查看注册中心的地址数据存储结构。注册中心以服务服务名作为数据划分的依据，将一个服务下的所有地址数据聚合为子节点。子节点的内容为实际可访问的ip地址。也就是我们Dubbo中的URL，格式只是provider实例生成的。我们再来看看URL地址的详细格式。这里，URL地址数据分为几部分：第一部分是实例的可访问地址，主要信息包括ip端口。消费者会根据这个数据生成一个tcp网络链接作为后续的RPC数据传输载体，后面是RPC元数据。元数据用于定义和描述RPC请求。一方面，它表明这条地址数据与特定的RPC服务有关。它的版本号、分组和方法相关的信息，另一方面表明接下来的部分是RPC配置数据，一部分用来控制RPC调用的行为，一部分用来同步RPC的状态Provider流程实例，典型的如超时时间和数据编码的序列化方法。最后一部分是自定义元数据。这部分不同于上述框架的预定义配置，给用户更多的灵活性。用户可以任意扩展和添加自定义元数据，进一步丰富实例状态。结合以上两页对Dubbo2接口级地址模型的分析，以及最初的Dubbo基本示意图，我们可以得出几个结论：第一，地址发现聚合的关键是RPC粒度服务。二、注册中心同步数据不仅包括地址，还包括各种元数据和配置。得益于1和2，Dubbo实现了支持应用、RPC服务、方法粒度的服务治理能力。这就是Dubbo2一直以来在易用性和服务治理功能上的表现。它在性能和可扩展性方面强于许多服务框架的真正原因。事物总是有它的两个方面。Dubbo2地址模型在带来易用性和强大功能的同时，也给整个架构的横向扩展带来了一些限制。这个问题在正常规模的微服务集群中是完全感觉不到的，但是随着集群的增长，当整个集群的应用和机器数量达到一定数量时，整个集群中的各个组件就开始遇到规模瓶颈。在总结了阿里巴巴、工商银行等众多典型用户的生产环境特点后，我们总结出以下两个突出问题（图中红色部分）：一是注册中心的集群容量已经达到上层临界点。由于所有的URL地址数据都发送到注册中心，注册中心的存储容量达到了上限，推送效率也随之下降。在消费端，Dubbo2框架的常驻内存已经超过40%，每次地址推送带来的CPU等资源消耗率也非常高，影响了正常的业务调用。为什么会出现这个问题？下面我们以一个具体的provider例子来展开，试图解释为什么应用在接口级地址模型下容易出现容量问题。青色部分，假设有一个普通的DubboProvider应用，里面定义了10个RPCServices，应用部署在100个机器实例上。该应用在集群中产生的数据量将是“服务数+机器实例数”，即10100=1000。数据在两个维度上被放大：从地址角度。100个唯一的实例地址，从服务的角度放大了10倍。10条独特的服务元数据被放大100倍。面对这个问题，在Dubbo3架构下，我们不得不重新思考两个问题：如何在保留可用性和功能性的情况下重组URL地址数据，避免冗余数据的出现，让Dubbo3支持更大集群的水平扩展？地址发现层面如何与其他微服务系统如Kubernetes、SpringCloud等进行对接？Dubbo3的应用级服务发现方案的设计本质上就是围绕着以上两个问题展开的。基本思路是：地址发现链路上的聚合元素，就是我们之前提到的关键，从服务调整到应用，这就是为什么叫应用级服务发现；已经大大简化，只保留核心ip和端口地址数据。这是对升级后应用级地址发现内部数据结构的详细分析。与之前的接口级地址发现模型相比，我们主要关注橙色部分的变化。首先，在provider实例这边，相比之前每个RPCService注册一个地址数据，一个provider实例只会向registry注册一个地址；注册中心侧，地址以应用名称为粒度进行聚合，应用名称节点下是精简后的提供者实例地址；上述应用层服务发现的调整，实现了单个地址大小和地址总数的减少，但也带来了新的挑战：易用性和功能性的基础丢失了，因为元数据的传输被简化，如何精细控制单个服务的行为变得不可能。为了解决这个问题，Dubbo3的解决方案是引入了一个内置的MetadataService元数据服务，由Consumer向Provider的集中推送转换为点对点的拉取。在这种模式下，元数据传输的数据量将不再是问题，因此可以在元数据中扩展更多的参数，暴露更多的治理数据。这里我们重点关注消费者的地址订阅行为。消费者分两步读取地址数据。首先从注册中心接收简化地址，然后调用MetadataService元数据服务读取peer的元数据。信息。消费者接收到这两部分数据后，会完成地址数据的聚合，最终在运行状态下还原出类似于Dubbo2的URL地址格式。因此，就最终结果而言，应用层地址模型兼顾了地址传输层的性能和操作层的功能。以上就是应用级服务发现背景和工作原理的全部内容。接下来我们看一下饿了么升级到Dubbo3的过程，特别是应用层的服务发现。下面是饿了么的基本部署架构图。升级前，饿了么微服务框架采用HSF2，跨单元RPC调用通过代理中转。在此过程中，代理承载的机器数量和流量迅速增加。最突出的一点是代理在订阅所有地址数据后，资源消耗和稳定性都受到严峻挑战。通过Dubbo3的全站升级，业务线期望实现两个目标：将地址模型切换为应用级服务发现，大幅降低中心化节点和消费端节点的资源消耗压力。代理模式被应用级服务发现架构下的全局共享注册中心替代，实现跨单元节点的直接通信。无论是针对Dubbo2还是HSF2，我们都做了全面的API兼容，所以Dubbo3基本可以实现零改造升级，每个应用独立透明升级，无需关心其上下游的升级状态应用方面，由于Dubbo3升级后，从地址发现模型和协议的默认行为都保持兼容2.0版本，用户可以随时为任何应用切换Dubbo3行为。如右图所示，我们模拟了饿了么集群Dubbo3升级过程的一个中间状态，其中灰色标记为旧版本HSF2应用，橙色和绿色标记为升级后的Dubbo3应用，橙色部分的应用及其调用链接意味着它不仅升级到了Dubbo3，同时也完成了Dubbo3行为的切换。在这里，意味着它已经切换到应用程序级别的地址模型。这里的升级过程主要是为了说明Dubbo3框架升级的兼容性和独立性。下面详细分析一下橙色节点迁移到Dubbo3应用级发现的过程。首先，看一下Provider端。升级Dubbo3后，服务提供者会默认保持双重注册行为，即同时注册接口级地址和应用级地址。该中心一方面保持兼容性，另一方面为未来的消费端迁移做准备。双注册的切换可以通过-Ddubbo.application.register-mode=al/interface/interface来控制，建议保持双注册的默认行为，减少后续迁移成本。大家可能会担心重复注册给注册中心带来的存储压力。其实在应用级服务发现模型下这不是问题，因为如果你回想一下我们之前分析应用级服务发现的工作原理，注册地址已经大大减少了。简化一下，根据我们的实际计算，每多注册一个应用级服务发现URL，只会增加0.1%到1%的额外开销。和provider端类似，consumer端要实现平滑迁移，也需要经历双订阅的过程，这里不再赘述。也可以通过规则或开关动态调整消费者的双订阅行为，控制消费者消费的某项服务或应用向应用级地址模型的迁移；此外，Dubbo3还内置了检测应用级地址的自动决策机制。切换在可用时自动完成，并且此行为是默认行为。饿了么成功升级了Dubbo3和应用层的服务发现模型，实现了去代理架构的目标。在我们关心的服务发现数据链路上：数据注册订阅传输量下降90%，注册中心数据存储整体资源占用下降90%消费端服务框架自身常驻内存消耗减少了50%。集群的整体稳定性和性能得到了显着提升，也为未来的扩容做好了准备。虽然饿了么的整体部署架构比较复杂，但是我们对饿了么Dubbo3升级过程的讲解还是很简单明了的，因为服务发现的过程本身就比较简单，核心就是围绕提供者、消费者、注册。中心三个节点的数据同步。其中，重要的有三点。一是应用层服务发现工作原理的整体讲解。第二点是Dubbo3的基本升级过程。Dubbo3可以实现透明兼容升级，按需切换行为。第三点，Dubbo3以饿了么阿里巴巴为代表，真正意义上实现了对HSF2的替代，只是部分SPI扩展已经和开源版本保持一致。
