宋小生-中间件

2017年的9月份，阿里宣布重启Dubbo的开发维护，并且后续又将Dubbo捐献给了Apache，经过多年的发展已经发布到3.X版本了，Dubbo重启维护之后是否有值得我们期待的功能呢，下面就来看看吧。Apache Dubbo 是一款微服务框架，为大规模微服务实践提供高性能 RPC 通信、流量治理、可观测性等解决方案，涵盖 Java、Golang 等多种语言 SDK 实现。

容错模版类AbstractClusterInvoker//从服务目录里面根据路由规则动态查询invoke服务提供者的调用器 List < Invoker < T > > invokers = list(invocation);//获取负载均衡策略默认为随机RandomLoadBalance LoadBalance loadbalance = initLoadBalance(invokers , invocation);try {} }...

将思路拉回到RegistryProtocol的创建Invoker对象的doCreateInvoker代码不论是接口级还是应用级注册都会调用代码。

然后看AbstractServiceNameMapping的getAndListen方法}

前面说了《Dubbo3消费者自动感应决策应用级服务发现原理》简单的说了下消费者是如何通过创建代理对象来进行应用级或者接口级的一个决策，只提到了迁移规则的使用与最终的currentAvailableInvoker对象的创建，并没有说详细的细节，这里我们来详细看看细节：服务发现，即消费端自动发现服务地址列表的能力，是微服务框架需要具备的关键能力，借助于自动化的服务发现，微服务之间可以在无需感知对端部署位置与 IP 地址的情况下实现通信。可以通过以下图的消费者与注册中心的交互逻辑来帮助理解：消费者主动向注册中心订

这里要说的内容对Dubbo2迁移到Dubbo3的应用比较有帮助，消费者应用级服务发现做了一些自动决策的逻辑来决定当前消费者是应用级发现还是接口级服务发现，这里与前面说的提供者双注册的原理是对等的，提供者默认同时进行应用级注册和接口级注册，消费者对提供者注册的数据来决定使用应用级发现或者接口级发现。这些都是默认的行为，当然对于消费者来说还可以自定义其他的迁移规则，具体的需要我们详细来看逻辑。如果说对于迁移过程比较感兴趣可以直接去官网看文档相对来说还是比较清晰:https://dubbo.apache.org/

前面我们通过Demo说了一个服务引用配置的创建。另外也在前面的文章说了服务提供者的启动完整过程，不过在说服务提供者启动的过程中并未提到服务消费者是如何发现服务，如果调用服务的，这里先就不再说关于服务消费者启动的一个细节了，直接来看前面未提到的服务消费者是如何引用到服务提供者提供的服务的。先来回顾下样例代码：更多内容也可关注原文 https://blog.elastic.link/......

前面简单介绍了一下消费者的例子，消费者创建的第一步就是先进行消费者信息的配置对应类型为ReferenceConfig，这里详细来看ReferenceConfig包含哪些信息？先简单了解下消费者配置的类型关系如下图所示：引用配置与服务配置类型都是通过继承接口配置来扩展的，在分析生产者的时候详细介绍过服务相关的配置，这里来详细看消费者引用者的相关配置信息.前面例子说了消费者配置对象的创建主要是通过如下代码：这个配置类型的对象创建过程并没有太多的逻辑这里主要来说下各种配置信息：服务消费者引用服务配置。对应的

为了更方便了解原理,我们先来编写一个Demo,从例子中来看源码实现:，前面说了提供者现在已经有服务注册上去了，那接下来我们编写一个消费者的例子来进行服务发现与服务RPC调用。为了Demo可以正常启动,需要我们先在本地启动一个Zookeeper如下图所示:接下来给大家贴一下示例源码,这个源码来源于Dubbo源码目录的 dubbo-demo/dubbo-demo-api 目录下面的dubbo-demo-api-consumer子项目,这里我做了删减,方便看核心代码:首先我们定义一个服务接口如下所示:19.

MetadataService此服务用于公开Dubbo进程内的元数据信息。典型用途包括：1。使用者查询提供者的元数据信息，以列出接口和每个接口的配置2。控制台（dubbo admin）查询特定进程的元数据，或聚合所有进程的数据。在Dubbo2.x的时候，所有的服务数据都是以接口的形式注册在注册中心，Dubbo3将部分数据抽象为元数据的形式来将数据存放在元数据中心，然后元数据由服务提供者提供给消费者而不是再由注册中心进行推送，如下图所示：//未完待续............................

上个博客《15-Dubbo的三大中心之元数据中心源码解析》导出服务端的时候多次提到了元数据中心，注册信息的注册。Dubbo3出来时间不太长，对于现在的用户来说大部分使用的仍旧是Dubbo2.x，Dubbo3 比较有特色也是会直接使用到的功能就是应用级服务发现：对于直接使用Dubbo3的用户还好，可以仅仅开启应用级注册，但是对于Dubbo2.x的用户升级到Dubbo3的用户来说前期都是要开启双注册来慢慢迁移的，既注册传统的接口信息到注册中心，又注册应用信息到注册中心，同时注册应用与接口关系的元数据信息。

目录16-模块发布器发布服务全过程16.1 简介16.2 导出服务的入口16.3 服务配置导出服务16-模块发布器发布服务全过程16.1 简介Dubbo做为服务治理框架,比较核心的就是服务相关的概念,这里我先贴个找到的关于Dubbo工作原理的架构图:如果按完整服务启动与订阅的顺序我们可以归结为以下6点:导出服务(提供者)服务提供方通过指定端口对外暴露服务注册服务(提供者)提供方向注册中心注册自己的信息(服务发现)-订阅服务(消费者)服务调用方通过注册中心订阅自己感兴趣的

13-Dubbo的三大中心之元数据中心源码解析13.1 简介关于元数据中心的概念对于大部分用户来说是比较陌生的,配置中心的话我们还好理解,对于元数据中心是什么,我们来看下我从官网拷贝过来的一段文字:元数据中心在2.7.x版本开始支持，随着应用级别的服务注册和服务发现在Dubbo中落地，元数据中心也变的越来越重要。在以下几种情况下会需要部署元数据中心：对于一个原先采用老版本Dubbo搭建的应用服务，在迁移到Dubbo 3时，Dubbo 3 会需要一个元数据中心来维护RPC服务与应用的映射关系（即接口

目录14-Dubbo配置加载全解析14.1 回到启动器的初始化过程14.2 初始化加载应用配置14-Dubbo配置加载全解析14.1 回到启动器的初始化过程在应用程序启动的时候会调用发布器的启动方法 ,然后调用初始化方法,在发布器DefaultApplicationDeployer中的初始化方法initialize() 如下:@Override public void initialize() { if (initialized) { return;

目录13-Dubbo的三大中心之配置中心13.1 配置中心简介13.2 启动配置中心13-Dubbo的三大中心之配置中心13.1 配置中心简介百度了一段不错的文字来介绍配置中心，我看了下肯定比我写的好多了，那我就直接拷贝过来一起看：对于传统的单体应用而言，常使用配置文件来管理所有配置，比如SpringBoot的application.yml文件，但是在微服务架构中全部手动修改的话很麻烦而且不易维护。微服务的配置管理一般有以下需求：集中配置管理，一个微服务架构中可能有成百上千个微服务，所以集中配置

目录12 全局视野来看Dubbo3的服务启动生命周期12.1 启动方法简介12.2 启动器启动方法的调用逻辑start()12.3 应用程序发布器DefaultApplicationDeployer的启动方法12.4 应用程序发布器对应用级别的初始化逻辑12.5 应用下模块的启动（服务的发布与引用）12.6 模块发布器发布服务的过程12 全局视野来看Dubbo3的服务启动生命周期12.1 启动方法简介在说启动方法之前先把视野拉回第一章《1-从一个服务提供者的Demo说起》我们的Demo代码,下面只贴一

11-Dubbo启动器DubboBootstrap添加协议配置信息ProtocolConfig11.1 简介先贴个代码用来参考: DubboBootstrap bootstrap = DubboBootstrap.getInstance(); bootstrap.application(new ApplicationConfig("dubbo-demo-api-provider")) .registry(new RegistryConfig("zookeeper://127.

10-Dubbo启动器DubboBootstrap添加注册中心配置信息RegistryConfig10.1 简介先贴个代码用来参考: DubboBootstrap bootstrap = DubboBootstrap.getInstance(); bootstrap.application(new ApplicationConfig("dubbo-demo-api-provider")) .registry(new RegistryConfig("zookeeper://12

9-Dubbo启动器DubboBootstrap添加应用程序的配置信息ApplicationConfig9.1 简介先贴个代码用来参考: DubboBootstrap bootstrap = DubboBootstrap.getInstance(); bootstrap.application(new ApplicationConfig("dubbo-demo-api-provider")) .registry(new RegistryConfig("zookeeper://

7-Dubbo的SPI扩展机制之自动激活扩展Activate源码解析7.1 Activate扩展的说明此注解对于使用给定条件自动激活某些扩展非常有用，例如：@Activate可用于在有多个实现时加载某些筛选器扩展。group() 指定组条件。框架SPI定义了有效的组值。value() 指定URL条件中的参数键。SPI提供程序可以调用ExtensionLoader。getActivateExtension(URL、String、String)方法以查找具有给定条件的所有已激活扩展。比如后面我们

6 Dubbo的SPI扩展机制之普通扩展对象的创建与Wrapper机制的源码解析6.1 普通扩展对象的加载与创建这里我们要分析的是ExtensionLoader类型的getExtension(String name)方法, 有了前面自适应扩展的铺垫,这里就更容易来看了getExtension是根据扩展名字获取具体扩展的通用方法,我们来根据某个类型来获取扩展的时候就是走的这里,比如在这个博客开头的介绍:ApplicationModel中获取配置管理器对象 configManager = (Conf

5 自适应扩展对象的创建getAdaptiveExtension方法自适应扩展又称为动态扩展,可以在运行时生成扩展对象ExtensionLoader中的getAdaptiveExtension()方法,这个方法也是我们看到的第一个获取扩展对象的方法. ,这个方法可以帮助我们通过SPI机制从扩展文件中找到需要的扩展类型并创建它的对象,自适应扩展:如果对设计模式比较了解的可能会联想到适配器模式,自适应扩展其实就是适配器模式的思路,自适应扩展有两种策略:一种是我们自己实现自适应扩展:然后使用@Adap

在上一章中我们初始化模型对象的时候了解到有几个地方用到了扩展机制来初始化对象,这一章我们会详细来讲一下这个扩展对象的加载过程TypeDefinitionBuilder.initBuilders(this); public static void initBuilders(FrameworkModel model) { Set<TypeBuilder> tbs = model.getExtensionLoader(TypeBuilder.class).getSupported

3-ModuleModel对象的建模在上一章中我们看到AbstractMethodConfig的构造器中有这么一行代码用来创建模块模型对象,那这一章我们就来看下模型对象的初始化过程:public AbstractMethodConfig() { super(ApplicationModel.defaultModel().getDefaultModule()); }3.1 模块模型(ModuleModel)参数对象的创建这个AbstractMethodConfig构.....

2 ServiceConfig对象的建模2.1 示例源码回顾:为了方便我们理解记忆这里先来回顾下上一章我们说的示例代码如下所示:public class Application { public static void main(String[] args) throws Exception { startWithBootstrap(); } private static void startWithBootstrap() { Servi

1 从一个服务提供者的Demo说起为了更方便了解原理,我们先来编写一个Demo,从例子中来看源码实现:1.1 启动Zookeeper为了Demo可以正常启动,需要我们先在本地启动一个Zookeeper如下图所示:1.2 服务提供者接下来给大家贴一下示例源码,这个源码来源于Dubbo源码目录的 dubbo-demo/dubbo-demo-api 目录下面的dubbo-demo-api-provider子项目,这里我做了删减,方便看核心代码:首先我们定义一个服务接口如下所示:import jav