WannaRunning的博客

Dubbo框架本身是支持参数校验的，同时也是基于JSR303去实现的。dubbo框架的资源文件org.apache.dubbo.rpc.Filter中定义了默认会生效框架自带的一系列Filter。其中就包含下面说的ValidationFilter。

目录Dubbo是什么Dubb服务注册和上下线感知工作前两年一直在使用的基本都是Cloud体系里的组件，都是基于cloud体系内提供的 Feign 组件来进行内部服务通信。最近这半年接触了新的技术栈，半年的工作中 感觉对分布式服务架构又有了更深的理解，分布式不一定要用Cloud所谓的微服务去构建，比如基于Dubbo服务再加上其他的一些像配置中心等组件去构建也是一样能实现分布式架构和服务治理的。Dubbo是什么从用途方面来说，Dubbo框架类似于SpringCloud体系中的Feign+Ri

了解过Dubbo框架后就可以知道Dubbo服务本身其实是不需要web容器的。而且Dubbo框架内部内置了Spring Container、Jetty Container、Jetty Container三种服务容器。对于Dubbo来说，集成到SpringBoot项目中后Dubbo和Boot应用也是两个不同的端口，互不干涉。引入Dubbo的starter依赖包 <dependency> <groupId>org.apache.dubbo</g

IO线程组Dubbo默认的底层网络通讯是使用Netty框架实现的，所以说白了Dubbo的线程模型其实就是Netty的主从Refactor模型。主Refactor（Boss EventLoopGroup）主要用来建立与客户端的连接，子Refactor（worker EventLoopGroup）用于监听所有事件进行处理。这两个线程组统称为Dubbo中的IO线程组，I/O线程数默认是CPU的个数+1Dispatch配置Dispatcher是dubbo中的调度器，用来决定操作是在IO中执行还是业务..

文章部分内容摘录自Dubbo官方文档应用级服务发现 | Apache Dubbohttps://dubbo.apache.org/zh/docs/examples/service-discovery/Triple协议和新的服务注册发现机制，很大程度上都是出于适配云原生。一方面新的协议对应云原生中跨语言的要求，使得Dubbo服务不再局限于特定的开发语言，通过新协议都可以兼容通信。在Cloud Native的潮流下，跨平台、跨厂商、跨环境的系统间互操作性的需求必然会催生基于开放标准的RPC技术，而gRPC.

文章基于dubbo 2.7.8分析，不同版本代码可能有所不同。@DubboComponentScan注解这个注解是配置Dubbo服务扫描的包路径的，风格与boot中的自动装配类似，注解中引入了DubboComponentScanRegistrar这个配置类。DubboComponentScanRegistrar之所以说这个类是一个配置类，是因为它实现了ImportBeanDefinitionRegistrar接口。这个类的用途与@Configuration 注解的类是一样的，通过重写

在SpringBoot项目中集成Dubbo的模式下,在boot项目启动时Dubbo也会完成服务接口的对外发布和消费者引用。

消费者在发起一次调用的时候时序图如下。

Dubbo整个集群容错层的实现在模块，它包含很多组件，例如：Cluster、ClusterInvoker、Directory、LoadBalance等等。Cluster是集群容错接口，它的功能仅仅是将一组Invoker聚合成一个具备集群容错能力的ClusterInvoker。在2.7.8版本中，Dubbo内置了十种集群容错策略，默认策略是Failover，对应的类是FailoverCluster，它会创建FailoverClusterInvoker。

AbstractDirectory中封装了Invoker列举流程，具体的列举逻辑则由子类实现，如AbstractDirectory类定义了doList方法,在StaticDirectory和RegistryDirectory两个子类中重写了doList方法。这是典型的模板模式;

开头讲到Router一般都是由对应的RouterFactory而来,具体一点说,在消费者启动过程中是基于SPI机制加载各个RouterFactory来初始化加载router列表的。所以如果要自定义Router路由也是基于SPI机制来集成。实现org.apache.dubbo.rpc.cluster.router.AbstractRouter接口并实现route方法即可@Slf4j@Overridelog.error("执行自定义的router对服务列表进行过滤");

之前的文章介绍了,即实现org.apache.dubbo.rpc.Filter接口及内部子接口Listener，或继承ListenableFilter抽象类就可以进行自定义Dubbo Filter。

通过实现org.apache.dubbo.rpc.Filter接口可以自定义Filterimport org.apache.dubbo.rpc.Filter;import org.apache.dubbo.rpc.Invocation;import org.apache.dubbo.rpc.Invoker;import org.apache.dubbo.rpc.Result;import org.slf4j.Logger;import org.slf4j.LoggerFactory;@Ac

之前简单写了一下，了解了Dubbo底层是基于NIO的Netty框架实现的，通过IO线程池和Work线程池实现了请求和业务处理之间的异步。这篇文章要写的是Dubbo对于消费端调用和服务端接口业务逻辑处理的异步，在2.7版本中Dubbo实现了基于CompletableFuture的异步支持。

参数相关的配置室友优先级的，方法级配置高于接口级配置，消费端配置高于服务提供者的配置。服务提供者provider参数配置服务提供者的相关配置大部分都可以在@DubboService注解中进行直接配置。具体参数如下：iothreads: io线程池大小(固定大小)。限制的是io线程池大小，该线程池线程用于处理Dubbo框架自身业务逻辑，默认值是cpu个数+1，一般不会调整此参数。 threads：业务线程池大小(固定大小)，就是Dubbo服务端处理请求的线程数，默认值200，默认使用固定大小线

group和version是@DubboService和@DubboReference注解中共有的两个属性,我理解这两个属性其实都是用于区分接口的不同实现的;group适用于在区分不同应用中的实现,version使用与在同一应用内区分不同的实现。version的使用如果某个接口的实现只存在于某个应用中,我觉得可以直接使用version来实现多版本解决接口不兼容升级的场景,不同version的提供者和消费者都不会互相引用定义一个新的接口实现类并指定新的版本,升级后当前应用可以同时对外提供这两个版