在上一篇文章我们分析了一下dubbo在服务暴露发生了哪些事，今天我们就来分析一下整个服务暴露中的本地暴露。(PS:其实我感觉本地暴露蛮鸡肋的)。本地暴露需要服务提供方与服务消费方在同一个JVM。下面我们来写一个本地暴露使用的例子：DemoService.javapublicinterfaceDemoService{StringsayHello(Stringname);}DemoServiceImp

Dubbo是阿里开发的分布式服务调用框架，提供了它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。工程目录模块介绍dubbo-common  Dubbo通用模块，定义了业务无关的工具类例如io处理、日志处理、配置处理、类处理等等操作，以及对于线程池的扩展，二进制编码处理，class编译处理，json数据处理，数据持久化接口处理等等。dubbo-rpc-api

先思考下，如果要实现服务发布和注册，需要做哪些事情？配置文件解析或注解解析启动netty服务实现远程监听服务注册服务端无外乎就这3件事，接下来我们用源码分析来论证我们的猜想Dubbo集成SpringSpring的标签扩展在spring中定义了两个接口1.NamespaceHandler:注册一堆BeanDefinitionParser，利用他们来进行解析配置2.BeanDefinitionPars

@(dubbo源码分析)[#rpc]dubbo源码分析（一）：dubbo整体源码结构分析image.pngdubbo整体的结构分析如下：启动时，provider会把所有接口注册到注册中心，并且订阅动态配置

在上一篇文章我们讲解了一下dubbo远程服务暴露过程中通过Netty进行Socket服务暴露。使得远程客户端可以访问这个暴露的服务，这个只是解决了访问之前点到点的服务调用。对于分步式环境当中，越来越多的服务我们如何管理并且治理这些服务是一个问题。因此dubbo引入了注册中心这个概念，把服务暴露、服务调用的信息保存到注册中心上面。并且还可以订阅注册中心，实现服务自动发现。因为dubbo远程暴露里面的

dubbo源码分析（二）：dubbo服务暴露总过程image.pngdubbo服务的暴露过程主要是分为两步：将provider的接口实现类转化为Invoker对象将Invoker对象转化为Exporter

上一篇我们简单描述了dubbo服务暴露-服务引用的流程这一篇我们从dubbo协议来具体分析一下Protocol层export()过程publicExporterexport(Invokerinvoker)throwsRpcException{URLurl=invoker.getUrl();//exportservice.Stringkey=serviceKey(url);DubboExporter

在上一篇文章中dubbo源码分析之SPI机制介绍了dubbo的spi机制中的ExtensionLoader的源码，本篇文章将继续深入研究这个dubbospi底层类的实现。

Dubbo默认是使用Netty进行通信的，那么Netty会配置一个Handler，来处理一些事件，所以这个Handler是核心，主要找一下Dubbo初始化Netty的时候设置的Handler回顾一下网络通信相关，在DubboProtocol中，会调用createServer方法返回一个Server对象，这是一个切入点privateExchangeServercreateServer(URLurl)

Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的RPC实现服务的输出和输入功能，可以和Spring框架无缝集成。Dubbo是一款高性能、轻量级的开源JavaRPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。这是Dubbo的一个简单介绍，第一篇首先讲一下Dubbo是如何和Spring框架进行无缝集成的。在我们进行Spr

在前面的文章我们分析了一下dubbo远程服务暴露过程中通过Netty进行Socket服务暴露。使得远程客户端可以访问这个暴露的服务，这个只是解决了访问之前点到点的服务调用。对于分步式环境当中，越来越多的服务我们如何管理并且治理这些服务是一个问题。因此dubbo引入了注册中心这个概念，把服务暴露、服务调用的信息保存到注册中心上面。并且还可以订阅注册中心，实现服务自动发现。因为dubbo远程暴露里面的

前面两篇文章已经分析了provider和consumer之间的通信过程，那么还有几个问题：由于请求是异步的，provider返回结果到客户端之后，consumer怎么知道该结果是哪个请求的？由于请求是异步的，为何Dubbo能同步等待结果？由于请求是异步的，provider返回结果到客户端之后，consumer怎么知道该结果是哪个请求的？先看下第一个问题，因为provider返回结果也是一次网络请求

从如下代码中还是分析StringsayHello=demoService.sayHello("123123");我们知道demoService实际上是一个代理对象，那么假设使用的是JDK的代码，看看获取代理的地方publicclassJdkProxyFactoryextendsAbstractProxyFactory{@SuppressWarnings("unchecked")publicTget

在上一篇文章我们讲解了一下dubbo服务暴露过程中的本地暴露。它只是一个开胃小菜，主要是为我们后面讲解远程暴露开个头。下面就来分析一下dubbo在远程暴露里面发生了哪些事。因为dubbo远程暴露里面的过程还是比较复杂的，所以我就分为三个文章来讲解dubbo的远程暴露：dubbo远程暴露--Netty暴露服务dubbo远程暴露--Zookeeper连接dubbo远程暴露--Zookeeper注册&订

DispatcherDispatcher是决定事件如何派发的策略，即将哪些事件派发线程池，还是说直接在当前线程中执行。先看下接口的定义@SPI(AllDispatcher.NAME)publicinterfaceDispatcher{@Adaptive({Constants.DISPATCHER_KEY,"dispather","channel.handler"})//后两个参数为兼容旧配置Cha

在上一篇文章我们分析了一下dubbo在服务暴露发生了哪些事，今天我们就来分析一下整个服务暴露中的本地暴露。(PS:其实我感觉本地暴露蛮鸡肋的)。本地暴露需要服务提供方与服务消费方在同一个JVM。下面我们来写一个本地暴露使用的例子：DemoService.javapublicinterfaceDemoService{StringsayHello(Stringname);}DemoServiceImp

如果大家看过之前的dubbo内核SPI实现--2.dubbo源码分析之内核SPI实现,有可能还是一头雾水,下面我讲一下dubbo的具体应用。最典型的应用就是Protocol接口。

1、程序员要有自己的格调虽然我们都乐忠于称自己只是一个搬砖的码农，但是我们内心一定要有自己的格调，在代码的世界里，我们就是神一样的存在，我们就是上帝。当然神也有成长过程，大致分为以下几个阶段。2、打字阶段这个阶段，就是从0开始。什么变量，什么方法，什么类，什么对象。都是些什么鬼不知道。我们只能乖乖按教科书一个字符一个字符键盘敲打，不错过任何一个空格，然后小心翼翼按下执行操作。要么成功，要么再一个个

下面我们来分析一下Dubbo的Router机制。Dubbo的路由规则就是根据路由规则从多个Invoker中选出一个子集AbstractDirectory是所有目录服务实现的上层抽象，它在list列举出所有invokers后，会在通过Router服务进行路由过滤。先来看一下AbstractDirectory的setRouters方法protectedvoidsetRouters(Listrouter

FutureFilter主要是用来处理事件通知的过滤器，这么讲可能不太清楚，先看下下面的demo先定一个是事件通知的类：publicclassNotify{publicvoidoninvoke(Stringmsg){System.out.println("oninvoke:"+msg);}publicvoidonreturn(Stringmsg){System.out.println("onret

目录原理概述为什么设计@Adaptive注解dubbo源码中哪些地方什么时候使用到了，具体如何体现@Adaptive扩展加载过程源码分析总结原理概述首先看以下官网的关于自适应扩展的描述：在Dubbo中，很多拓展都是通过SPI机制进行加载的，比如Protocol、Cluster、LoadBalance等。有时，有些拓展并不想在框架启动阶段被加载，而是希望在拓展方法被调用时，根据运行时参数进行加载。这

1.简介本篇文章，将开始分析Dubbo集群容错方面的源码。集群容错源码包含四个部分，分别是服务目录Directory、服务路由Router、集群Cluster和负载均衡LoadBalance。这几个部分的源码逻辑相对比较独立，我们将会分四篇文章进行分析。本篇文章作为集群容错的开篇文章，将和大家一起分析服务目录相关的源码。在进行深入分析之前，我们先来了解一下服务目录是什么。服务目录中存储了一些和服务

在之前的dubbo源码分析中我们分析了dubbo的服务暴露。

Dubbo采用微内核+插件体系，使得设计优雅，扩展性强。那所谓的微内核+插件体系是如何实现的呢！大家是否熟悉spi(serviceproviderinterface)机制，即我们定义了服务接口标准，让厂商去实现（如果不了解spi的请谷歌百度下）,jdk通过ServiceLoader类实现spi机制的服务查找功能--Java规范SPI。1、为什么不使用JDKSPI在dubbo中它实现了一套自己的SP

先思考下，如果要实现服务消费，需要做哪些事情？生成远程服务的代理获得目标服务的url地址实现远程网络通信实现负载均衡实现集群容错客户端无外乎就这几件事，但是总的来说，客户端代码比服务端复杂的多，所以分了上下两章，接下来我们用源码分析来论证我们的猜想image.png服务的消费消费端的代码解析是从下面这段代码开始的注解的方式的初始化入口是ReferenceAnnotationBeanPostProc

在前面一篇博客中分享了dubbo在网络通信当中的consumer的发送以及接收原理。通过集群容错最终选择一个合适的Invoke通过netty直联调用provider的服务。众所周知，netty是基于JavaNio的Reactor模型的异步网络通信框架，所以dubbo在consumer端把异步变成了同步。大概总结了consumer的发送与接收原理，下面我们来讨论一下dubbo网络通信当中provid

@(dubbo源码分析)[#rpc]dubbo源码分析（三）：dubbo服务暴露-本地服务暴露分析暴露过程分为两步将本地接口实现类转化为invoker将invoker转化为ExPorterimage.pngprivatevoidexportLocal

为什么要用Dubbo远程通信背景技术架构的发展从单体到分布式，是一种顺势而为的架构演进，也是一种被逼无奈的技术变革。架构的复杂度能够体现公司的业务的复杂度，也能从侧面体现公司的产品的发展势头是向上的。和传统的单体架构相比，分布式多了一个远程服务之间的通信，不管是SOA还是微服务，他们本质上都是对于业务服务的提炼和复用。那么远程服务之间的调用才是实现分布式的关键因素。而在远程通信这个领域，其实有很多

前言我们在往期文章中，曾经深入分析过Java的SPI机制，它是一种服务发现机制。具体详见：深入理解JDK的SPI机制在继续深入Dubbo之前，我们必须先要明白Dubbo中的SPI机制。因为有位大神（佚名）曾这样说过：要想理解Dubbo，必须要先搞明白DubboSPI机制，不然会非常晕。一、背景1、来源Dubbo的扩展点加载从JDK标准的SPI(ServiceProviderInterface)扩展

 上面使用的dubbo版本是2.6.2版本的，然后我分析源码时候使用的是gitHub上最新下载的版本2.7.1的版本。在自习对比之后发现了部分差异，但是大致的逻辑并没有太大的影响。接下来就进入分析。 在前面搭建环境的时候我们只是在启动类上面贴了一个EnableDubbo的注解。从这里开始着手。1.EnableDubbo标签@Target({ElementType.TYPE})@Retention(

前言在前面的章节中，我们已经完成Dubbo服务暴露的流程分析。今天我们一起来看Dubbo怎么引用这些服务的。关于服务引用，Dubbo有两种方式。一种是基于注册中心进行服务引用，一种是服务直连进行引用。服务直连主要用于测试联调阶段，生产环境不推荐使用。它的配置也比较简单，在消费者端指定服务url即可。本文将重点分析通过注册中心方式，服务引用的过程。开始之前，我们再回顾一下消费者端项目整体的XML文件

Dubbo示例packagecom.alibaba.dubbo.demo.consumer;importcom.alibaba.dubbo.demo.DemoService;importcom.alibaba.dubbo.demo.DemoService2;importorg.springframework.context.support.ClassPathXmlApplicationContex

一、概述本篇介绍自适应扩展，方法getAdaptiveExtension()的实现。ExtensionLoader类本身很多功能也使用到了自适应扩展。包括ExtensionFactory扩展。通俗的讲，自适应扩展要实现的逻辑是：调用扩展点的方法时，自动判断要调用那个扩展点实现类的方法。我们知道，一个扩展点通常有多个实现类，在配置文本文件中分多行配置，在前面的分析中，我们知道通过getExtensi

一、概述本篇文章是dubboSPI源码分析的第二篇，接着第一篇继续分析dubboSPI的内容，我们主要介绍getDefaultExtension()获取默认扩展点方法。由于此方法比较简单，我们略过示例部分，直接分析源码。二、源码分析获取默认扩展方法getDefaultExtension()是一个public、可对外提供调用的方法。我们知道，dubbo中扩展点接口必须要有@SPI注解修饰，@SPI注

一、概述dubboSPI在dubbo的作用是基础性的，要想分析研究dubbo的实现原理、dubbo源码，都绕不过dubboSPI，掌握dubboSPI是征服dubbo的必经之路。本篇文章会详细介绍dubboSPI相关的内容，通过源码分析，目标是让读者能通过本篇文章，彻底征服dubboSPI。文章的组织方式是先介绍SPI的概念，通过JavaSPI让大家了解SPI是什么，怎么用，有一个初步的概念，du

SPI扩展前言站在一个框架作者的角度来说，定义一个接口，自己默认给出几个接口的实现类，同时允许框架的使用者也能够自定义接口的实现。现在一个简单的问题就是：如何优雅的根据一个接口来获取该接口的所有实现类呢？JDKSPI正是为了优雅解决这个问题而生，SPI全称为(ServiceProviderInterface)，即服务提供商接口，是JDK内置的一种服务提供发现机制。目前有不少框架用它来做服务的扩展发

介绍上篇文章介绍了Directory，再次看一下dubbo调用的处理流程：本篇文章介绍调用的第二步，Router的实现。从图中可以看到，Router的实现有两种：Script和Condition，官网对其的描述为：Router负责从多个Invoker中按路由规则选出子集，比如读写分离，应用隔离等也就是说，第一步通过Directory选出当前可用的服务提供者，然后再通过Router按规则过滤出服务提

介绍在集群容错时，dubbo处理的流程如下图所示：下面是来自官网的介绍，各节点关系如下：这里的Invoker是Provider的一个可调用Service的抽象，Invoker封装了Provider地址及Service接口信息Directory代表多个Invoker，可以把它看成List，但与List不同的是，它的值可能是动态变化的，比如注册中心推送变更Cluster将Directory中的多个In

3072.png今天看到之前dubbo项目重启动的时候，遗留下来的一个bug。看了下代码被修复了，觉得自己对于dubbo的源码还不够熟练，复现该用户场景如下假设我们有一个DemoService接口:publicinterfaceDemoService{StringsayHello(Stringname);StringsayHello2(Stringname);}通过配置注解的parameters参

暴露服务的过程中，会涉及到两个ProtocolDubboProtocol主要是做网络通信相关初始化RegistryProtocol主要是做zk的注册和订阅相关在提供一个服务的时候，需要在配置文件里声明如下xmlregistryURLs=loadRegistries(true);//获取注册中心的urlfor(ProtocolConfigprotocolConfig:protocols){doExp

了解服务发布Dubbo官方文档说明了服务提供者暴露服务的主过程，如图所示：服务提供者暴露一个服务的详细过程首先ServiceConfig类拿到对外提供服务的实际类ref(如：HelloWorldImpl),然后通过ProxyFactory类的getInvoker方法使用ref生成一个AbstractProxyInvoker实例，到这一步就完成具体服务到Invoker的转化。接下来就是Invoker

先推荐别人两篇文章Dubbo源码分析：DirectoryDubbo源码分析：Router问题引入想自定义dubbo的行为，很可能绕不开这几类组件理解这几类组件的作用，才能根据定制需求，找准最合适的组件这几个组件的作用按

1.基于schema解析     dubbo的配置约束文件在dubbo-config/dubbbo-config-spring/src/main/resources/dubbo.xsd中。dubbo.xsd文件用来约束使用xml配置时的标签和属性。Spring在解析到自定义的namespace标签时，会查找META-INF下的spring.handlers和spring.schemas文件。通过D

1.ZookeeperRegistryFactorycom.alibaba.dubbo.registry.zookeeper.ZookeeperRegistryFactory ，实现AbstractRegistryFactory抽象类，ZookeeperRegistry工厂。代码如下：publicclassZookeeperRegistryFactoryextendsAbstractRegistr

消费端的代码解析是从下面这段代码开始的注解的方式的初始化入口是ReferenceConfifig.getpublicsynchronizedTget(){checkAndUpdateSubConfigs();//检查和修改配置if(destroyed){thrownewIllegalStateException("TheinvokerofReferenceConfig("+url+")hasalr

getRegistry1.把url转化为对应配置的注册中心的具体协议2.根据具体协议，从registryFactory中获得指定的注册中心实现那么这个registryFactory具体是怎么赋值的呢？finalURLregisteredProviderUrl=getRegisteredProviderUrl(providerUrl,registryUrl);ProviderInvokerWrapp

Dubbo插件化Dubbo的插件化实现非常类似于原生的JAVA的SPI：它只是提供一种协议，并没有提供相关插件化实施的接口。用过的同学都知道，它有一种java原生的支持类：ServiceLoader，通过声明接口的实现类，在META-INF/services中注册一个实现类，然后通过ServiceLoader去生成一个接口实例，当更换插件的时候只需要把自己实现的插件替换到META-INF/serv

 前面已经对Dubbo跟SpringBoot的结合原理的分析了[https://www.jianshu.com/p/7048774803d5](Dubbo源码分析----Dubbo在SpringBoot

前言我们在第2章节里面，已经讲到Dubbo的初始化流程。Dubbo的初始化是随着Spring容器Bean的实例化而进行的，今天我们重点看这样一个节点，它在配置文件中是这样的：它会完成Dubbo服务暴露的逻辑，我们先看下大概流程。一、开始上述配置文件中的节点信息对应的处理类是ServiceBean。我们先看下它的结构publicclassServiceBeanextendsServiceConfig

在集中式环境中服务的机器台只有一台，这样对于服务不仅存在服务单点故障问题而且还存在流量问题。为了解决这个问题，就引入的分布式与集群概念。分布式：一个业务分拆多个子业务，部署在不同的服务器上集群：同一个业务，部署在多个服务器上1、dubbo服务治理当请求来临时，如何从多个服务器中，选择一个有效、合适的服务器，这个集群所需要面对一问题。所以在集群里面就引申出负载均衡（LoadBalance），高可用（