【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

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



相关文章
|
6月前
|
Dubbo Java 应用服务中间件
性能工具之JMeter Dubbo 脚本开发
【5月更文挑战第13天】性能工具之JMeter Dubbo 脚本开发
80 3
性能工具之JMeter Dubbo 脚本开发
|
22天前
|
存储 SQL 消息中间件
Hadoop-26 ZooKeeper集群 3台云服务器 基础概念简介与环境的配置使用 架构组成 分布式协调框架 Leader Follower Observer
Hadoop-26 ZooKeeper集群 3台云服务器 基础概念简介与环境的配置使用 架构组成 分布式协调框架 Leader Follower Observer
37 0
|
3月前
|
开发框架 Dubbo 应用服务中间件
微服务开发框架-----Apache Dubbo
这篇文章介绍了Apache Dubbo微服务开发框架,它提供RPC通信和微服务治理能力,支持服务发现、负载均衡和流量治理等功能,并强调了Dubbo在微服务规模化实践和企业级治理方面的优势。
微服务开发框架-----Apache Dubbo
|
4月前
|
NoSQL Redis
Redis 主从复制架构配置及原理
Redis 主从复制架构配置及原理
61 5
|
3月前
|
监控 安全 API
Android项目架构设计问题之保证线上用户不会进入到本地配置页面如何解决
Android项目架构设计问题之保证线上用户不会进入到本地配置页面如何解决
28 0
|
3月前
|
JSON Android开发 数据格式
Android项目架构设计问题之在远端动态配置中添加相应配置如何解决
Android项目架构设计问题之在远端动态配置中添加相应配置如何解决
27 0
|
4月前
|
监控 算法 Java
高并发架构设计三大利器:缓存、限流和降级问题之配置Sentinel的流量控制规则问题如何解决
高并发架构设计三大利器:缓存、限流和降级问题之配置Sentinel的流量控制规则问题如何解决
|
4月前
|
存储 对象存储
业务系统架构实践问题之在设计领域时配置与单据之间的关系如何解决
业务系统架构实践问题之在设计领域时配置与单据之间的关系如何解决
|
6月前
|
数据中心 网络架构 Python
【计算巢】数据中心的网络架构设计原则
【5月更文挑战第31天】探讨数据中心网络架构设计原则:稳定性是基础,需抵御各种挑战;强调扩展性,适应业务发展;追求高效,确保数据传输速度;注重灵活性,灵活应对变化。简单Python代码示例展示网络节点连接。设计时需具备长远眼光,综合考虑技术方案,以构建坚固高效的信息桥梁。同学们,要持续学习和探索,为信息世界贡献力量!
83 2
|
6月前
|
XML 监控 Dubbo
Dubbo03【管理控制台和监控中心搭建】,Java开发实用必备的几款插件
Dubbo03【管理控制台和监控中心搭建】,Java开发实用必备的几款插件

热门文章

最新文章