【Dubbo3终极特性】「云原生三中心架构」带你探索Dubbo3体系下的配置中心和元数据中心、注册中心的原理及开发实战(上)

简介: 【Dubbo3终极特性】「云原生三中心架构」带你探索Dubbo3体系下的配置中心和元数据中心、注册中心的原理及开发实战(上)

Dubb3的应用级服务发现


Dubbo3提供了全新的应用级服务发现模型,该模型在设计与实现上区别于 Dubbo2 的接口级服务发现模型。


概括来说,Dubbo3 引入的应用级服务发现主要有以下优势


  • 适配云原生微服务变革。云原生时代的基础设施能力不断向上释放,像 Kubernetes 等平台都集成了微服务概念抽象,Dubbo3 的应用级服务发现是适配各种微服务体系的通用模型。


  • 提升性能与可伸缩性。支持超大规模集群的服务治理一直以来都是 Dubbo 的优势,通过引入应用级服务发现模型,从本质上解决了注册中心地址数据的存储与推送压力,相应的 Consumer 侧的地址计算压力也成数量级下降;集群规模也开始变得可预测、可评估(与 RPC 接口数量无关,只与实例部署规模相关)。


下图是 Dubbo2 的服务发现模型:Provider 注册服务地址,Consumer 经过注册中心协调并发现服务地址,进而对地址发起通信,这是被绝大多数微服务框架的经典服务发现流程。而 Dubbo2 的特殊之处在于,它把 “RPC 接口”的信息也融合在了地址发现过程中,而这部分信息往往是和具体的业务定义密切相关的。

image.png

而在接入云原生基础设施后,基础设施融入了微服务概念的抽象,容器化微服务被编排、调度的过程即完成了在基础设施层面的注册。如下图所示,基础设施既承担了注册中心的职责,又完成了服务注册的动作,而 “RPC 接口”这部分信息,由于与具体的业务相关,不可能也不适合被基础设施托管。

image.png


在这样的场景下,对 Dubbo3 的服务注册发现机制提出了两个要求: Dubbo3 需要在原有服务发现流程中抽象出通用的、与业务逻辑无关的地址映射模型,并确保这部分模型足够合理,以支持将地址的注册行为和存储委托给下层基础设施 Dubbo3 特有的业务接口同步机制,是 Dubbo3 需要保留的优势,需要在 Dubbo3 中定义的新地址模型之上,通过框架内的自有机制予以解决。


这样设计的全新的服务发现模型,在架构兼容性、可伸缩性上都给 Dubbo3 带来了更大的优势。

image.png

在架构兼容性上,如上文所述,Dubbo3 复用下层基础设施的服务抽象能力成为了可能;另一方面,如 Spring Cloud 等业界其它微服务解决方案也沿用这种模型, 在打通了地址发现之后,使得用户探索用 Dubbo 连接异构的微服务体系成为了一种可能。


Dubbo3 服务发现模型更适合构建可伸缩的服务体系,这点要如何理解? 这里先举个简单的例子,来直观的对比 Dubbo2 与 Dubbo3 在地址发现流程上的数据流量变化:假设一个微服务应用定义了 100 个接口(Dubbo 中的服务), 则需要往注册中心中注册 100 个服务,如果这个应用被部署在了 100 台机器上,那这 100 个服务总共会产生 100 * 100 = 10000 个虚拟节点;而同样的应用, 对于 Dubbo3 来说,新的注册发现模型只需要 1 个服务(只和应用有关和接口无关), 只注册和机器实例数相等的 1 * 100 = 100 个虚拟节点到注册中心。 在这个简单的示例中,Dubbo 所注册的地址数量下降到了原来的 1 / 100,对于注册中心、订阅方的存储压力都是一个极大的释放。更重要的是, 地址发现容量彻底与业务 RPC 定义解耦开来,整个集群的容量评估对运维来说将变得更加透明:部署多少台机器就会有多大负载,不会像 Dubbo2 一样, 因为业务 RPC 重构就会影响到整个集群服务发现的稳定性。



Dubbo3部署架构


本文主要侧重介绍在云原生背景下的部署架构,主要体现在基础设施(Kubernetes、Service Mesh等)会承担更多的职责,三中心化体系结构,如:注册中心、元数据中心、配置中心等的职责被集成,促使架构变得更加优秀、资源优化的更加彻底。通过分析这些中心化的组件能让我们更容易理解Dubbo3对应云原生模式下的工作原理。

image.png

从上面的图中,我们可以看出来,整体的的Dubbo的Rpc框架中,除了对应的Consumer消费端、Provider服务提供端Registry注册中心这些之前dubbo中已经定义的中心化组件之外,还多出了config-center、metadata这两个中心。




Dubbo3的三中心化体系


作为一个微服务框架,Dubbo SDK跟随着微服务组件被部署在分布式集群各个位置,为了在分布式环境下实现各个微服务组件间的协作, Dubbo3扩展了一些中心化组件,这包括:


  • 注册中心
  • 协调Consumer消费者与Provider服务提供者之间的地址注册与发现。


  • 配置中心
  • 存储Dubbo启动阶段的全局配置,保证配置的跨环境共享与全局一致性
  • 负责服务治理规则(路由规则、动态配置等)的存储与推送。


  • 元数据中心
  • 接收Provider服务端上报的服务接口元数据,为Admin等控制台提供运维能力(如服务测试、接口文档等)
  • 作为服务发现机制的补充,提供额外的接口/方法级别配置信息的同步能力,相当于注册中心的额外扩展。


注意:以上三个中心体系并不是运行Dubbo的必要条件,用户完全可以根据自身业务情况决定只启用其中一个或多个(甚至不需要任何中心,直连模式,当然生产不推荐),以达到简化部署的目的。


接下来我们将会针对于这三个中心分别给大家去详细讲解说明一下。




注册中心


大多数情况下,我们基本都会以独立的注册中心以开始Dubbo服务开发,而配置中心、元数据中心则会在微服务演进的过程中逐步的按需被引入进来

image.png

注册中心扮演着非常重要的角色,它承载着服务注册服务发现的职责。目前Dubbo支持以下两种粒度的服务发现服务注册,分别是接口级别应用级别注册中心可以按需进行部署:


直连模式


在最初的Dubbo SDK使用过程中,如果仅仅提供直连模式的RPC服务,不需要部署注册中心。


注册模式


无论是接口级别还是应用级别,如果需要Dubbo SDK自身来做服务注册和服务发现,则可以选择部署注册中心,在Dubbo中集成对应的注册中心。


Mesh模式


在Dubbo + Mesh 的场景下,随着Dubbo服务注册能力的弱化,Dubbo内的注册中心也不再是必选项,其职责开始被控制面取代,如果采用了Dubbo + Mesh的部署方式,无论是ThinSDK的mesh方式还是Proxyless的mesh方式,都不再需要独立部署注册中心。


注册中心不依赖于配置中心和元数据中心


对于组成而言注册中心不完全依赖于配置中心和元数据中心,如下图所示。

image.png

没有部署配置中心和元数据中心,在Dubbo中会默认将注册中心的实例同时作为配置中心和元数据中心,这是Dubbo的默认行为,如果确实不需要配置中心或者元数据中心的能力,可在配置中关闭,在注册中心的配置中有两个配置分别为use-as-config-center和use-as-metadata-center,将配置置为false即可




元数据中心


元数据中心并不是在Dubbo3才推出的,而是在2.7.x版本就开始支持,随着应用级别的服务注册和服务发现在Dubbo中落地,元数据中心也变的越来越重要,如下图所示。

image.png

上面图中不配备配置中心,意味着可以不需要全局管理配置的能力。该图中不配备注册中心,意味着可能采用了Dubbo mesh的方案,也可能不需要进行服务注册,仅仅接收直连模式的服务调用。在以下几种情况下会需要部署元数据中心:


(场景1)老版本Dubbo迁移到新版本Dubbo3的场景


对于一个原先采用老版本Dubbo搭建的应用服务,在迁移到Dubbo3时,Dubbo3会需要一个元数据中心来维护RPC服务与应用的映射关系(即接口与应用的映射关系)。


应用级别的服务发现和服务注册


以往的“接口 —— 实例列表”结构的数据组织形式,如下图所示。

image.png

如果采用了应用级别的服务发现和服务注册,在注册中心中将采用”应用 —— 实例列表”结构的数据组织形式,如下图所示。

image.png

以往用接口级别的服务注册和服务发现的应用服务在迁移到应用级别时,得不到接口与应用之间的对应关系,从而无法从注册中心得到实例列表信息,所以Dubbo为了兼容这种场景,在Provider端启动时,会往元数据中心存储接口与应用的映射关系



(场景2)让注册中心更加聚焦于地址的发现和推送能力


为了让注册中心更加聚焦于地址的发现和推送能力,减轻注册中心的负担,元数据中心承载了所有的服务元数据、大量接口/方法级别配置信息等,无论是接口粒度还是应用粒度的服务发现和注册,元数据中心都起到了重要的作用。


如果有以上两种需求,都可以选择部署元数据中心,并通过Dubbo的配置来集成该元数据中心。元数据中心并不依赖于注册中心和配置中心,用户可以自由选择是否集成和部署元数据中心,如下图所示:

image.png

可以看到消费者会元数据中心拉取到接口和应用服务的关系。配合着注册中心拉取到应用与服务实例之间的关系,两者组成了更加优雅地格式和优化了存储空间。

image.png

  • 注册中心-存储:应用名称->接口服务实例地址


  • 元数据中心-存储:应用名称->接口信息+参数信息


两者可以直接整合为应用名称->接口服务实例地址->接口信息




配置中心


配置中心与其他两大中心不同,它无关于接口级还是应用级,它与接口并没有对应关系,它仅仅与配置数据有关,即使没有部署注册中心和元数据中心,配置中心也能直接被接入到Dubbo应用服务中


在整个部署架构中,整个集群内的实例(无论是Provider还是Consumer)都将会共享该配置中心集群中的配置,如下图所示

image.png

  • 该图中不配备注册中心,意味着可能采用了Dubbo mesh的方案,也可能不需要进行服务注册,仅仅接收直连模式的服务调用。


  • 该图中不配备元数据中心,意味着Consumer可以从Provider暴露的MetadataService获取服务元数据,从而实现RPC调用。



保证三大中心高可用的部署架构


虽然三大中心已不再是Dubbo应用服务所必须的,但是在真实的生产环境中,一旦已经集成并且部署了该三大中心,三大中心还是会面临可用性问题,Dubbo需要支持三大中心的高可用方案。在Dubbo中就支持多注册中心、多元数据中心、多配置中心,来满足同城多活、两地三中心、异地多活等部署架构模式的需求。


Dubbo SDK对三大中心都支持了Multiple模式。


  • 多注册中心:Dubbo 支持多注册中心,即一个接口或者一个应用可以被注册到多个注册中心中,比如可以注册到ZK集群和Nacos集群中,Consumer也能够从多个注册中心中进行订阅相关服务的地址信息,从而进行服务发现。通过支持多注册中心的方式来保证其中一个注册中心集群出现不可用时能够切换到另一个注册中心集群,保证能够正常提供服务以及发起服务调用。这也能够满足注册中心在部署上适应各类高可用的部署架构模式。


  • 多配置中心:Dubbo支持多配置中心,来保证其中一个配置中心集群出现不可用时能够切换到另一个配置中心集群,保证能够正常从配置中心获取全局的配置、路由规则等信息。这也能够满足配置中心在部署上适应各类高可用的部署架构模式。


  • 多元数据中心:Dubbo 支持多元数据中心:用于应对容灾等情况导致某个元数据中心集群不可用,此时可以切换到另一个元数据中心集群,保证元数据中心能够正常提供有关服务元数据的管理能力。


拿注册中心举例,下面是一个多活场景的部署架构示意图:

image.png



支持的组件与部署架构


Dubbo 实现普遍支持以下产品或部署架构,具体多语言 SDK 实现可能有差异。



注册中心


  • Zookeeper
  • Nacos
  • Kubernetes


元数据中心


  • Zookeeper
  • Nacos
  • Redis


配置中心


  • Zookeeper
  • Nacos
  • Redis
  • Apollo


Mesh


  • 数据面 Envoy
  • 控制面 Istio

接下来后面的文章会为大家实战一下如何进行配置和设置对应的注册中心、配置中心和元数据中心。



相关文章
|
3月前
|
Cloud Native 测试技术 开发者
终于!我找到了开发的得力助手!阿里云天池云原生编程挑战赛参赛攻略
在比赛过程中,通义灵码插件成为了我开发工作的得力助手。这个插件提供了智能代码补全和错误提示功能,大大提高了我的编码效率。尤其是通义灵码能够实时分析代码,给出优化建议,让我避免了很多潜在的错误。
212 64
|
23小时前
|
负载均衡 监控 Dubbo
Dubbo 原理和机制详解(非常全面)
本文详细解析了 Dubbo 的核心功能、组件、架构设计及调用流程,涵盖远程方法调用、智能容错、负载均衡、服务注册与发现等内容。欢迎留言交流。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
Dubbo 原理和机制详解(非常全面)
|
6月前
|
Dubbo Java 应用服务中间件
性能工具之JMeter Dubbo 脚本开发
【5月更文挑战第13天】性能工具之JMeter Dubbo 脚本开发
80 3
性能工具之JMeter Dubbo 脚本开发
|
2月前
|
监控 Android开发 iOS开发
深入探索安卓与iOS的系统架构差异:理解两大移动平台的技术根基在移动技术日新月异的今天,安卓和iOS作为市场上最为流行的两个操作系统,各自拥有独特的技术特性和庞大的用户基础。本文将深入探讨这两个平台的系统架构差异,揭示它们如何支撑起各自的生态系统,并影响着全球数亿用户的使用体验。
本文通过对比分析安卓和iOS的系统架构,揭示了这两个平台在设计理念、安全性、用户体验和技术生态上的根本区别。不同于常规的技术综述,本文以深入浅出的方式,带领读者理解这些差异是如何影响应用开发、用户选择和市场趋势的。通过梳理历史脉络和未来展望,本文旨在为开发者、用户以及行业分析师提供有价值的见解,帮助大家更好地把握移动技术发展的脉络。
66 6
|
2月前
|
人工智能 Cloud Native Serverless
来云栖大会!探展云上开发,沉浸式体验云原生 + AI 新奇玩法
计算馆将展示中国最先进的云计算产业链全景,从底层硬件到数据创新,从云计算基础设施到数据管理服务、人工智能平台和模型服务,全景式呈现 AI 时代云计算最新技术形态和产品进展。计算馆有哪些推荐?往下看!
|
3月前
|
开发框架 Dubbo 应用服务中间件
微服务开发框架-----Apache Dubbo
这篇文章介绍了Apache Dubbo微服务开发框架,它提供RPC通信和微服务治理能力,支持服务发现、负载均衡和流量治理等功能,并强调了Dubbo在微服务规模化实践和企业级治理方面的优势。
微服务开发框架-----Apache Dubbo
|
3月前
|
负载均衡 Dubbo 应用服务中间件
Dubbo服务调用过程原理
该文章主要介绍了Dubbo服务调用过程的原理,包括服务调用的主要阶段和服务调用的具体步骤。
Dubbo服务调用过程原理
|
3月前
|
缓存 Dubbo Java
Dubbo服务消费者启动与订阅原理
该文章主要介绍了Dubbo服务消费者启动与订阅的原理,包括服务消费者的启动时机、启动过程以及订阅和感知最新提供者信息的方式。
Dubbo服务消费者启动与订阅原理
|
3月前
|
Dubbo 网络协议 Java
深入掌握Dubbo服务提供者发布与注册原理
该文章主要介绍了Dubbo服务提供者发布与注册的原理,包括服务发布的流程、多协议发布、构建Invoker、注册到注册中心等过程。
深入掌握Dubbo服务提供者发布与注册原理
|
3月前
|
负载均衡 Dubbo Java
Dubbo服务Spi机制和原理
该文章主要介绍了Dubbo中的SPI(Service Provider Interface)机制和原理,包括SPI的基本概念、Dubbo中的SPI分类以及SPI机制的实现细节。
Dubbo服务Spi机制和原理

热门文章

最新文章