街头小瘪三的专栏

本来想着一篇文件分析完dubbo主流程源码的，但是写完以后发现，源码中存在大量的Dubbo SPI思想，不说清楚Dubbo SPI, 源码是看不下去的。因此，紧接着我又补了2篇Dubbo SPI的博客。所以有了前3篇博客的铺垫，再次来谈源码，详细会简单很多。

本篇将围绕Dubbo消费端的主流程进行讲解，其中会涉及到过滤器、容错、复杂均衡进行重点分析。首先，我们需要认识几个重要的接口 Filter、Cluster、LoadBalance，分别对应过滤器、容错、复杂均衡。下面会这几个接口进行初步介绍。随着debug的深入，我们发现它首先调用的是容错组件的子类：而在容错组件的深入过程中，我们发现在容错组件的调用过程中，我们又调用到了负载均衡的策略：最后继续走到方法的最后一行，又调用了doInvoke方法。其实，这就是负载均衡的详细逻辑。

就是找到最佳的子实现类的，其实就是默认的类。这个注解可以打在类上方，那么dubbo SPI机制通过接口获取实例类，就是获取到有@Adaptive注解的实现类。个人觉得，这种适配的方式可以动态的根据URL选择具体的实现类，很灵活。但是，老是需要在方法中定义URL，这样静态代理类才能够根据Dubbo的适配方式去选择具体的实现类，写起来有点累赘。我们看到步骤3中得到一个String code，而这个code就是我们拼接出来的一个静态代理类，它负责根据URL中的key调用具体的业务实现类。

在上一篇中, 我们已经初步了解了Dubbo SPI的 key - value 结构。接下来将会继续分享Dubbo SPI其他功能的使用方式，并且从源码的角度去一谈究竟。参数名 效果String[] group() URL中的分组如果匹配则激活String[] value() URL中如果包含该key值，则会激活String[] before() 填写扩展点列表，表示哪些扩展点要在本扩展点之前激活。

Dubbo的服务注册与发现机制，核心动作就2个。) 将服务给暴露出去， protocol.refer(DemoService.class, registryUrl)将网络上的服务引入进来。1. 服务端启动，我们会将配置好的Dubbo需要暴露的Bean对象生成ServiceBean，然后包装成Invoker对象发送到注册中心。2. 消费端引入到invoker对象，会先生成一个ReferenceBean对象，而这个对象的ref会指向一个代理对象，这个代理对象是有Invoker生成的。

其实Dubbo的官方文档非常强大，里面的各种各样的标签都会介绍到，但是最新版的官方文档好像找不那么多详细的使用了。

开放一个业务类：服务端加载配置：

RPC是解决不同JVM之间数据调用的一个思想，比如说现在有2台不同的机器，业务代码需要在这2台机器间调用后台业务代码，RPC就可以解决这2台机器业务代码调用的问题：而RPC实现流程是什么样的呢？下图就可以很好的说明这些：1. 如果开放一个接口，这个接口需要继承Remote类这样服务端代码就全部写好了，直接启动等着消费端调用就好了。只要这2台机器网络是相通的，端口是开放的，很容易就可以实现A服务调用B服务，并且B服务返回结果给A服务这样的过程。特定场景，RPC有用处的。