Dubbo的使用和原理

目录

架构演进

分布式与RPC

Dubbo的使用

启动式检查

只订阅/只发布

分组/多版本控制

限流

多协议

声明式缓存

延迟暴露

隐式参数传递

泛化调用

异步调用

​编辑

Mock服务降级

本地存根

应用/配置实践

Dubbo的原理

架构设计

URL Bus

SPI扩展点 

Java SPI 

Dubbo SPI

服务限流

集群容错

failfast 

failover

failsafe

failback

forking

broadcast

服务降级

分组多版本

多协议/注册中心

服务暴露 

服务引用

负载均衡

服务调用

double协议

Filter原理

优雅停机 

总结

---

架构演进

在早期，IT系统以All In One的单体架构为主，所有的服务都部署在同一台机器上，所有的功能都在一个应用中开发，这种架构的好处是能够对需求进行快速的响应，对运维部署和团队协作更友好，但是这样架构下系统各个模块之间的耦合度过大，牵一发动全身，如果服务体积不断增加，一次部署所需要的时间越来越长，此时就需要根据服务的功能特点进行拆分。

对单体架构的拆分，可以根据系统的特点采用横向拆分或纵向拆分，如果模块与模块之间的耦合度不大，那么就可以采用纵向拆分，把每个功能独立成一个服务，如果服务与服务之间的耦合度比较大，那就只能进行横向拆分，横向拆分后，就形成了一种面向服务的SOA架构，如果再往前进化就到了分布式微服务架构，基于dubbo构建的分布式服务是一种在SOA和微服务之间的一种架构模式，因为并没有清晰的界限，完全看具体的实现方式。

对于IT系统的架构来说，并不是架构越复杂越好，而是需要根据当前的业务发展情况、公司的人力资源以及相应的运维能力等做综合的判断，最后选择一种合适的架构。对于分布式架构来说，虽然说它能够提供更强的性能和可扩展性，但是这也是有前提的，比如团队要有很强的运维能力，相比于All In One的单体架构来说，分布式架构会带来很多额外的挑战，比如：

• 分布式配置
• 分布式任务
• 调用链跟踪
• 项目交付方式的变化
• 团队协作模式的变化
• 技术成本的提高

所以，对于一个IT系统来说，能不拆就不拆，如果非拆不可，能简单拆就简单拆，否则会为团队和公司带来很大的不确定性，当然对于新构建的系统，完全可以根据实际情况采用合适的架构模式。

分布式与RPC

分布式是技术发展和业务发展的产物，对于分布式系统来说，它由多个节点组成一个整体对外提供服务，那么远程通信能力就成了它的一个基础，比较常见的的远程通信方式有两种，一种是基于http协议，另一种是一系列的基于TCP构建的长连接协议，比如dubbo、thrift、grpc、hession等，这些协议都被称为是RPC协议。

• 降级：服务降级属于通用业务模块，当服务出现问题时，返回给客户端一个缓存结构或伪结果，保证用户体验，服务降级一般分为大粒度和小粒度，大粒度一般是针对整个服务的降级，小粒度一般是针对单个请求的降级。 
• 负载均衡：在及群众均摊流量，增加系统的吞吐量。
• 容错：当一个请求发送错误时，如何进行有效的补救，使得业务最终能够成功。
• 熔断：熔断一般分为客户端熔断和服务端熔断，核心目的是保证系统的最佳负载或最大吞吐量，在测试阶段找到系统负载的临界点，当系统负载超过临界点时多余的负载就快速失败。
• 限流：限流的目的是为了保证系统的可用性（RPS Request Pre Second）

• • 客户端限流
    • 信号量限流
    • 连接数限流
  • 服务端限流
    • 线程池限流（隔离手段）
    • 信号量限流（非隔离手段）
    • 连接数限流（TCP Socket数量）

Dubbo的使用

启动式检查

只订阅/只发布

在开发阶段经常用到这个特性。

分组/多版本控制

一般用在灰度发布中。

限流

tcp socket限流：客户端connections，服务端accept

线程池限流：客户端active， 服务端executes

多协议

能够更好的在异构环境下进行系统集成。

声明式缓存

延迟暴露

• 服务预热
• 平滑发布（provider注册到注册中心后不一定马上可用）

隐式参数传递

RpcContext.getContext().setAttachment(key, value)；
RpcContext.getContext().getAttachment(key,value)；

隐式参数传递用于传递在API接口之外的一些信息，比如做dubbo调用链跟踪的的时候就可以通过隐式参数来传递traceId。

泛化调用

GenericService genericService=ref.get();
Object result=genericService.$invoke(“methodName”, new String[{“java.lang.String”}], new Object[{“hello world”}])

泛化调用指的是不通过API接口来调用服务提供者，一般用在异构系统集成或没有API接口支持的场景中。

异步调用

service.sayHello();
Future hello=RpcContext.getContext().getFuture()
Hello result = hello.get();

 消费者端的用户线程不需要进行同步等待。

Mock服务降级

   在接口所在包下找ServiceNameMock
  直接指定Mock类

   抛出指定的异常

不调用服务，直接强制走mock逻辑：

Mock是一种服务降级策略，但是dubbo的mock只有在抛出RpcException是才被触发，有一定的局限性，有时候会用Hystrix来做服务降级。

/**
 * 隔离策略：
 *  为什么要设置隔离？
 *
 *  线程隔离：（开销比较大，注意使用ThreadLoaca时的问题）
 *      线程隔离策略 通过线程池 中的线程数量来控制并发访问量，线程池的大小和等待队列
 *      可以通过参数进行配置，如果等待队列也满了，那么就会有一部分请求走fallback逻辑
 *
 *      由于使用了线程池，需要进行线程的上下文切换以及参数传递等，相对于信号量隔离 开销比较大
 *
 *      线程隔离策略比较适合那种计算量比较大的服务，因为支持异步和超时
 *
 *  信号量隔离（不支持超时、异步、线程切换，开销比较小）
 *      信号量隔离策略 通过制定信号量的数量 来控制对资源的并发访问数量
 *      超过信号量数量的请求一部分会进入队列等待，队列满后，其他的请求会走fallback逻辑
 *
 *      信号量隔离 自始至终都使用请求线程，没有线程切换，开销比较小。
 *
 *      信号量隔离策略 比较适合能快速响应的轻量级服务，不适合计算量比较大的接口
 *
 * */
@HystrixCommand(fallbackMethod = "error", commandProperties = {
        //线程隔离模式 or 信号量隔离模式
        @HystrixProperty(name = "execution.isolation.strategy", value = "THREAD"),
        //如果请求超过5秒没有返回，则进入熔断降级
        @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "5000"),
        //接口调用失败次数如果超过10次，则进入熔断降级
        @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "10")
},
    threadPoolProperties = {
        @HystrixProperty(name="coreSize", value = "10"),
            @HystrixProperty(name = "maxQueueSize", value = "10"),
            @HystrixProperty(name = "keepAliveTimeMinutes", value = "1000"),
            @HystrixProperty(name = "queueSizeRejectionThreshold", value = "10")
    }
)

本地存根

本地存根类似于dubbo接口的静态代理，本地存根类实现业务接口，并提供一个依赖于业务接口的构造函数，在运行时真实的业务对象就会被注入进来，可以在stub内部完成一些额外的逻辑，比如参数校验等。

本地存根是运行在客户端的，所以本地存根一般存放在api的依赖包中。

应用/配置实践

• api和model放到同一个jar包中，共享给各个依赖项目；
• 修改api接口及model时，一定要做到向下兼容，如果不能兼容，必须通知所有服务调用方，制定上线计划；
• 把api接口的参数封装到bean中，这样参数修改的时候只修改bean对象中的字段就行了；
• 对于bean中的参数字段，只增加不删除；
• 基于版本号实现api接口的平滑升级，但在实现上如果不能做到上下兼容，还是要通知所有调用方；

Dubbo的原理

架构设计

这是官方网站给出的dubbo的总体逻辑架构，主要包含四个部分：Consumer服务消费者、Provider服务提供者、Registry服务注册中心和Monitor服务管控中心。

Provider启动后异步向注册中心注册自己，Consumer异步从注册中心拉取服务列表，当Provider发生变化时，注册中心异步通知Consumer，Provider和Consumer异步向Monitor上报监控信息，Consumer以同步的方式调用Provider。

 这是dubbo的微观架构，按照不同的职责，dubbo在代码实现层面分成了多层：

• Service：业务层，定义了业务接口和具体的实现类
• Config：Consumer和Provider的配置层，ReferenceConfig和ServiceConfig
• Proxy：封装了对接口调用的代理和服务暴露的代理
• Registry：注册层，负责与注册中心交互，实现服务的注册与发现
• Cluster：集群层，提供服务路由、集群容错、负载均衡等功能
• Monitor：监控层，负责与dubbo管控中心交互
• Protocol：对rpc协议进行了封装，屏蔽底层通信细节
• Exhange：转换层，把对业务接口的调用转换成Request-Respone模式
• Transport：网络通信层，Netty、Mina；
• Serialize：序列化层，在数据发送到网络前和从网络接收后进行序列化和反序列化

在微观层面，dubbo采用一种微内核架构，每一种组件都是一个SPI扩展点，dubbo内核通过SPI机制把这些扩展点组装起来，形成一个整体，这为dubbo提供了非常好的扩展性。

URL Bus

URL Bus是dubbo的核心设计思想，它的作用于两个，对外提供资源定位能力，对内通过与SPI机制配合动态串联各个组件。dubbo中的很多参数都是通过URL Bus来传递。

URL：protocol://username:password@host:port/path?key=value&key=value

Dubbo URL的构造函数（与URL格式完全相同）：

protected URL() {
    this.protocol = null;
    this.username = null;
    this.password = null;
    this.host = null;
    this.port = 0;
    this.address = null;
    this.path = null;
    this.parameters = null;
    this.methodParameters = null;
}

在实际的使用中zookeeper协议的url和dubbo协议的url最常见。Dubbo中的URL可以包含非常多的扩展点参赛，URL作为上下文信息贯穿整个扩展点体系。

SPI扩展点 

从微观上看，dubbo采用的是一种微内核架构，各个服务组件通过SPI机制组合在一起，还可以通过SPI机制对Dubbo进行扩展。

Java SPI 

在Java中也提供了SPI机制，使用方式也比较简单

• 首先创建用于提供服务的接口和实现类

public interface IHelloService {
    String hello(String name);
}
//定义两个实现类
public class HelloService1 implements IHelloService {
    @Override
    public String hello(String name) {
        return "HelloService1:" + name;
    }
}
public class HelloService2 implements IHelloService {
    @Override
    public String hello(String name) {
        return "HelloService2:" + name;
    }
}

• 然后在META-INF/services目录下创建于接口全名称为名字的配置文件

com.learn.dubbo.chapter1.echo.server.spi.IHelloService

• 在配置文件中指定接口的实现了，用换行符分隔

com.learn.dubbo.chapter1.echo.server.spi.HelloService1
com.learn.dubbo.chapter1.echo.server.spi.HelloService2

• 通过ServiceLoader获取实现类的实例对象

ServiceLoader helloServices = ServiceLoader.load(IHelloService.class);
for (IHelloService helloService : helloServices) {
            System.out.println(helloService.hello("zhangsan"));
}

输出：
HelloService1:zhangsan
HelloService2:zhangsan

java spi的底层原理其实很简单，就是读取配置文件信息，然后对每一个实现类进行实例化后，添加到LinkedHashMap中缓存起来，其中Key是实现类的全名称，value是对应的实例对象。但java spi并不好用，首先它无法按需实例化对象，其次无法按需获取对象的实例，只能通过遍历来获取，所以dubbo并没有使用java api，而是实现自己的dubbo spi。

Dubbo SPI

相对于java spi，dubbo spi有以下的特性

• 能够按需实例化实例对象和按需获取
• 提供了IoC和Aop功能
• 支持基于参数的动态加载机制

@SPI("helloService1")   //指定默认的SPI接口实现
public interface IHelloService {
     //通过URL中的helloService参数对应的值进行自适应，主要为了配置setter实现依赖注入
    @Adaptive("helloService")
    String hello(URL url, String name);
}

//第一个实现类
public class HelloService1 implements IHelloService {
     @Override
    public String hello(URL url, String name) {
        return "HelloService1:" + name;
    }
}

//第二个实现类
public class HelloService2 implements IHelloService {
    @Override
    public String hello(URL url, String name) {
        return "HelloService2:" + name;
    }
}

//第三个实现类
public class MyHelloService implements IHelloService {
    
    private IHelloService helloService;
    //这里有一个setter依赖注入，具体注入的对象是由URL中的参数决定的
    public void setHelloService(IHelloService helloService) {
        this.helloService = helloService;
    }
    @Override
    public String hello(URL url, String name) {
        System.out.println("my hello service ");
        return helloService.hello(url, name);
    }
}

//这是一个具有AOP功能的实现类
public class HelloServiceWrapper implements IHelloService{
    private IHelloService helloService;
    //构造方法中如果右依赖的扩展点，就会为对每个实例进行包装
    public HelloServiceWrapper(IHelloService helloService) {
        this.helloService = helloService;
    }
    @Override
    public String hello(URL url, String name) {
        System.out.println("before...");
        String result = helloService.hello(url, name);
        System.out.println("after...");
        return result;
    }
}

//配置文件 com.learn.dubbo.chapter1.echo.server.spi.IHelloService
helloService1=com.learn.dubbo.chapter1.echo.server.spi.HelloService1
helloService2=com.learn.dubbo.chapter1.echo.server.spi.HelloService2
myHelloService=com.learn.dubbo.chapter1.echo.server.spi.MyHelloService
wrapper=com.learn.dubbo.chapter1.echo.server.spi.HelloServiceWrapper

//调用
IHelloService helloService = ExtensionLoader.getExtensionLoader(IHelloService.class).getDefaultExtension();
URL url1 = new URL("","",0);
System.out.println(helloService.hello(url1,"lisi"));

IHelloService helloService2 = ExtensionLoader.getExtensionLoader(IHelloService.class).getExtension("helloService2");
URL url2 = new URL("","",0);
System.out.println(helloService2.hello(url2,"wangwu"));

IHelloService helloService3 = ExtensionLoader.getExtensionLoader(IHelloService.class).getExtension("myHelloService");
Map p3 = new HashMap<>();
p3.put("helloService","helloService2");
URL url3 = new URL("","",0, p3);
helloService3.hello(url3, "zhaoliu");

• @SPI注解标记一个借口为SPI扩展点
• @Adaptive实现基于URL Bus的自适应机制
• @Active 激活组件

getExtension(beanName)的作用是通过指定的key获取实例对象，整个过程主要分为四步

• 加载配置文件，通过反射得到接口实现类的Class对象并进行缓存
• 创建Class的实例对象
• 通过setter方法进行依赖注入
• 通过构造函数处理Aop

在加载配置文件的过程中，dubbo兼容了java spi，会从META-INF/services、META-INF/dubbo、META-INF/dubbo/internal这三个目录中加载配置文件，并对普通扩展类、自适应扩展类、@Active修饰的扩展类和包装器扩展类分别缓存，方便后续处理，紧接着通过指定的bean名称得到Class对象，然后通过反射创建类的实例对象。

对依赖注入的处理其实很简单，就是得到setter的方法名称后截取掉set，将剩下的内容的首字母小写后作为key再到SPI上下文中找对应的实例对象，然后再通过反射调用setter方法，注入实例对象。aop的处理逻辑是通过构造函数实现的，在解析的过程中dubbo对存储依赖该接口的构造函数的类单独进行了缓存，当通过spi获取实例对象时，最后都会通过反射将真实的实例对象包装到这些Wapper类中，实现一种静态的aop功能。

getAdaptiveExtision()实现了dubbo spi的自适应机制，把URL Bus作为参数的载体。

@SPI
public interface AdaptiveService {
    @Adaptive("impl")
    void adaptive(URL url, String msg);
}
public class AdaptiveServiceImpl implements AdaptiveService {
    @Override
    public void adaptive(URL url, String msg) {
        System.out.println("msg");
    }
}

配置文件：com.learn.dubbo.chapter1.echo.server.spi.AdaptiveService
impl1=com.learn.dubbo.chapter1.echo.server.spi.AdaptiveServiceImpl

调用
AdaptiveService adaptiveService = ExtensionLoader.getExtensionLoader(AdaptiveService.class).getAdaptiveExtension();
Map p5 = new HashMap<>();
 p5.put("impl","impl1");
 URL url5 = new URL("","",0, p5);
 adaptiveService.adaptive(url5, "aaaaa")：
输出：
aaaaa

这里把想要获取的bean的id作为URL中的参数，然后dubbo api就会从URL中获取用@Adaptive注解指定的key从而拿到这个值，底层的实现原理比较简单，dubbo底层会动态生成一个Xxx$Adaptive类，在这个类中，会从url中获取对应的key的值，然后再通过getExtension(name)得到具体的扩展点对象。

package com.learn.dubbo.chapter1.echo.server.spi;
import com.alibaba.dubbo.common.extension.ExtensionLoader;
public class AdaptiveService$Adaptive implements com.learn.dubbo.chapter1.echo.server.spi.AdaptiveService {
public void adaptive(com.alibaba.dubbo.common.URL arg0, java.lang.String arg1) {
    if (arg0 == null) throw new IllegalArgumentException("url == null");
    com.alibaba.dubbo.common.URL url = arg0;
    String extName = url.getParameter("impl");
    if(extName == null)
        throw new IllegalStateException("Fail to get extension(com.learn.dubbo.chapter1.echo.server.spi.AdaptiveService) name from url(" + url.toString() + ") use keys([impl])");
    com.learn.dubbo.chapter1.echo.server.spi.AdaptiveService extension = (com.learn.dubbo.chapter1.echo.server.spi.AdaptiveService)ExtensionLoader.getExtensionLoader(com.learn.dubbo.chapter1.echo.server.spi.AdaptiveService.class).getExtension(extName);
    extension.adaptive(arg0, arg1);
    }
}

上面这段代码是一个字符串，然后再通过动态编译技术编译成字节码。

getActiveExtension()的作用是获取所有被标注了@Active的扩展点

@SPI
public interface IActivateService {
    void active();
}
@Activate(order = 1, group = "test")
public class ActiveService1 implements IActivateService {
    @Override
    public void active() {
        System.out.println("Active1");
    }
}
@Activate(order = 2, group = "test")
public class ActivateService2 implements IActivateService {
    @Override
    public void active() {
        System.out.println("active2");
    }
    
配置：com.learn.dubbo.chapter1.echo.server.spi.IActivateService
activateService1=com.learn.dubbo.chapter1.echo.server.spi.ActiveService1
activateService2=com.learn.dubbo.chapter1.echo.server.spi.ActivateService2
调用
Map m = new HashMap<>();
m.put("activate1", "activateService1");
m.put("activate2", "activateService2");
URL url6 = new URL("","",0, m);

List activateService = ExtensionLoader.getExtensionLoader(IActivateService.class).getActivateExtension(url6, "activate1,activate2", "test");
for (IActivateService a : activateService) {
            a.active();
 } 

Dubbo内置的Filter大量使用了@Active，因为它可以同时加载多个扩展点实例对象，比如限流组件@ExecuteLimitFilter/@ActiveLimitFilter，然后通过group来区分consumer或group。

服务限流

限流的目的是保证系统的可用性，避免因为负载超过系统能够承受的上限造成不可用或雪崩，dubbo提供了两种类型的限流方式，一种是在tcp连接数上限流（connections/accepts），一种是在处理请求的线程数上限流（active/exectes）。在客户端会为每一个服务接口创建多个tcp连接，connections这个属性就是在进行服务引用与服务端创建tcp连接的时候处理的，服务引用是通过DubboProtocol的refer方法实现的。

public  Invoker refer(Class serviceType, URL url) throws RpcException {
    this.optimizeSerialization(url);
    DubboInvoker invoker = new DubboInvoker(serviceType, url, 
        //创建DubboInvoker的时候，会用到与服务端的TCP连接
        this.getClients(url), this.invokers);
    this.invokers.add(invoker);
    return invoker;
}
private ExchangeClient[] getClients(URL url) {
    boolean service_share_connect = false;
    //从URL Bus上获取connections参数
    int connections = url.getParameter("connections", 0);
    if (connections == 0) {
        //如果没有设置connections参数，就走共享连接，
        //也就是对于一个服务接口只创建一个TCP连接
        service_share_connect = true;
        connections = 1;
    }
    ExchangeClient[] clients = new ExchangeClient[connections];
    for(int i = 0; i < clients.length; ++i) {
        if (service_share_connect) {
            clients[i] = this.getSharedClient(url);
        } else {
            /**
                初始化TCP连接，DubboInvoker中如果右多个TCP连接的话，
                采用轮训的方式进行调用
                protected Result doInvoke(Invocation invocation) throws Throwable { 
                    ExchangeClient currentClient = this.clients[this.index.getAndIncrement() % this.clients.length];
                }
            */
            clients[i] = this.initClient(url);
        }
    }

    return clients;
}

accepts对应的服务端的限流方案，它主要限制的是一个接口对应的NettyServer的客户端连接数的限制。

public class NettyServer extends AbstractServer implements Server {}

AbstractServer：
public void connected(Channel ch) throws RemotingException {
    if (!this.isClosing() && !this.isClosed()) {
        //这里获取客户端连接数
        Collection channels = this.getChannels();
        //如果服务端设置了accetps并且客户端连接数比accetps要大，就直接关掉多余的客户端连接
        if (this.accepts > 0 && channels.size() > this.accepts) {
            logger.error("Close channel " + ch + ", cause: The server " + ch.getLocalAddress() + " connections greater than max config " + this.accepts);
            ch.close();
        } else {
            super.connected(ch);
        }
    } else {
        logger.warn("Close new channel " + ch + ", cause: server is closing or has been closed. For example, receive a new connect request while in shutdown process.");
        ch.close();
    }
}

actives和executes属于限制并发请求数的限流方式，是通过Filter实现的，ActiveLimitFilter和ExecuteLimitFilter。

//在服务端应用
@Activate(group = {"provider"},value = {"executes"})
public class ExecuteLimitFilter implements Filter {
    public Result invoke(Invoker invoker, Invocation invocation) throws RpcException {
        URL url = invoker.getUrl();
        String methodName = invocation.getMethodName();
        //获取配置的executes参数
        int max = url.getMethodParameter(methodName, "executes", 0);
        //如果并发请求数超过了配置的最大数量，直接抛出异常
        if (!RpcStatus.beginCount(url, methodName, max)) {
            throw new RpcException("Failed to invoke method " + invocation.getMethodName() + " in provider " + url + ", cause: The service using threads greater than  limited.");
        } else {
            long begin = System.currentTimeMillis();
            boolean isSuccess = true;

            Result var9;
            try {
                //处理请求
                var9 = invoker.invoke(invocation);
            } catch (Throwable var13) {
                isSuccess = false;
                if (var13 instanceof RuntimeException) {
                    throw (RuntimeException)var13;
                }
                throw new RpcException("unexpected exception when ExecuteLimitFilter", var13);
            } finally {
                //请求处理结束后，把并发请求的数量减回去
                RpcStatus.endCount(url, methodName, System.currentTimeMillis() - begin, isSuccess);
            }
            return var9;
        }
    }
}


@Activate(group = {"consumer"},value = {"actives"})
public class ActiveLimitFilter implements Filter {
    public Result invoke(Invoker invoker, Invocation invocation) throws RpcException {
        URL url = invoker.getUrl();
        String methodName = invocation.getMethodName();
        //获取设置的actives参数
        int max = invoker.getUrl().getMethodParameter(methodName, "actives", 0);
        RpcStatus count = RpcStatus.getStatus(invoker.getUrl(), invocation.getMethodName());
        /**
            如果超过了最大请求的数量，先计算超时时间，如果没超时
            会不断尝试比较连接数，如果仍然大于最大连接数，则在count上等待
            直到被正在处理的线程唤醒，
            如果醒过来以后发现等地时间超过了配置的超时时间则抛出RpcException
        */
        if (!RpcStatus.beginCount(url, methodName, max)) {
            long timeout = (long)invoker.getUrl().getMethodParameter(invocation.getMethodName(), "timeout", 0);
            long start = System.currentTimeMillis();
            long remain = timeout;
            synchronized(count) {
                while(!RpcStatus.beginCount(url, methodName, max)) {
                    try {
                        count.wait(remain);
                    } catch (InterruptedException var31) {
                    }

                    long elapsed = System.currentTimeMillis() - start;
                    remain = timeout - elapsed;
                    if (remain <= 0L) {
                        throw new RpcException("Waiting concurrent invoke timeout in client-side for service:  " + invoker.getInterface().getName() + ", method: " + invocation.getMethodName() + ", elapsed: " + elapsed + ", timeout: " + timeout + ". concurrent invokes: " + count.getActive() + ". max concurrent invoke limit: " + max);
                    }
                }
            }
        }
        /**
            这里是处理没有达到最大并发请求数的任务
        */
        boolean isSuccess = true;
        long begin = System.currentTimeMillis();
        boolean var27 = false;
        Result var10;
        try {
            var27 = true;
            //调用远程服务
            var10 = invoker.invoke(invocation);
            var27 = false;
        } catch (RuntimeException var30) {
            isSuccess = false;
            throw var30;
        } finally {
            if (var27) {
                //将并发数量还回去
                RpcStatus.endCount(url, methodName, System.currentTimeMillis() - begin, isSuccess);
                if (max > 0) {
                    //唤醒在count上等待的线程
                    synchronized(count) {
                        count.notifyAll();
                    }
                }

            }
        }
        RpcStatus.endCount(url, methodName, System.currentTimeMillis() - begin, isSuccess);
        if (max > 0) {
            synchronized(count) {
                count.notifyAll();
            }
        }
        return var10;
    }
}

集群容错

集群容错指的是如何避免因为服务提供者不可用或处理过程中出现异常操作对请求响应的异常，dubbo提供了6中集群容错策略，分别是failfast、failover、failsafe、failback、forking和broadcast。dubbo的集群容错策略都是在客户端进行的，由ClusterInvoker完成。

为了保证服务的高可用，一个服务一般会部署两个以上的节点，Cluster的作用是将多个服务实例代表的Invoker合并成ClusterInvoker，ClusterInvoker内部封装的容错和负载均衡，实现了对上层的透明。

failfast 

failfast是一种快速失效的容错策略，即发生异常情况后直接返回不再进行重试或其他后续操作，failfast适合非幂等性操作的服务，或者高并发场景（因为在高并发下如果采取其他容错策略的话，会造成计算资源的紧张，容易造成请求的堆积或服务雪崩）。

FailfastClusterInvoker.java

public Result doInvoke(Invocation invocation, List> invokers, LoadBalance loadbalance) throws RpcException {
    this.checkInvokers(invokers, invocation);
    Invoker invoker = this.select(loadbalance, invocation, invokers, (List)null);
    try {
        /**
            调用远程服务，如果出现异常，直接抛出RpcException，
            不足任何后续处理
        */
        return invoker.invoke(invocation);
    } catch (Throwable var6) {
        if (var6 instanceof RpcException && ((RpcException)var6).isBiz()) {
            throw (RpcException)var6;
        } else {
            throw new RpcException(var6 instanceof RpcException ? ((RpcException)var6).getCode() : 0, "Failfast invoke providers " + invoker.getUrl() + " " + loadbalance.getClass().getSimpleName() + " select from all providers " + invokers + " for service " + this.getInterface().getName() + " method " + invocation.getMethodName() + " on consumer " + NetUtils.getLocalHost() + " use dubbo version " + Version.getVersion() + ", but no luck to perform the invocation. Last error is: " + var6.getMessage(), var6.getCause() != null ? var6.getCause() : var6);
        }
    }
}

failover

failover容错策略需要与retries配合使用，由于存在重试，所以接口的调用时长会增大，在使用这种容错策略时，需要适当调整timeout时间。在高并发场景尽量不要使用failover，会造成请求的堆积甚至服务雪崩。

FailoverClusterInvoker.java

public Result doInvoke(Invocation invocation, List> invokers, LoadBalance loadbalance) throws RpcException {
    List> copyInvokers = invokers;
    this.checkInvokers(invokers, invocation);
    String methodName = RpcUtils.getMethodName(invocation);
    //获取重试次数，默认是2次，总数在retries的基础上 + 1，因为第一次请求不能算在重试次数上
    int len = this.getUrl().getMethodParameter(methodName, "retries", 2) + 1;
    //如果retries被设置成负数，对数据进行修正 ※
    if (len <= 0) {
        len = 1;
    }
    RpcException le = null;
    List> invoked = new ArrayList(invokers.size());
    Set providers = new HashSet(len);

    for(int i = 0; i < len; ++i) {
        if (i > 0) {
            this.checkWhetherDestroyed();
            //得到最新的可用Invoker
            copyInvokers = this.list(invocation);
            this.checkInvokers(copyInvokers, invocation);
        }
        /**
            通过LoadBalancer选出一个Invoker进行调用
        */
        Invoker invoker = this.select(loadbalance, invocation, copyInvokers, invoked);
        invoked.add(invoker);
        RpcContext.getContext().setInvokers(invoked);
        try {
            Result result = invoker.invoke(invocation);
            /**
                这里将上次出现的异常打印到日志
            */
            if (le != null && logger.isWarnEnabled()) {
                logger.warn("Although retry the method " + methodName + " in the service " + this.getInterface().getName() + " was successful by the provider " + invoker.getUrl().getAddress() + ", but there have been failed providers " + providers + " (" + providers.size() + "/" + copyInvokers.size() + ") from the registry " + this.directory.getUrl().getAddress() + " on the consumer " + NetUtils.getLocalHost() + " using the dubbo version " + Version.getVersion() + ". Last error is: " + le.getMessage(), le);
            }

            Result var13 = result;
            return var13;
        } catch (RpcException var18) {
            if (var18.isBiz()) {
                //如果是业务异常直接抛出去，跳出重试
                throw var18;
            }
            le = var18;
        } catch (Throwable var19) {
            //如果是其他异常，封装成RcpException并记录
            le = new RpcException(var19.getMessage(), var19);
        } finally {
            providers.add(invoker.getUrl().getAddress());
        }
    }

    throw new RpcException(le.getCode(), "Failed to invoke the method " + methodName + " in the service " + this.getInterface().getName() + ". Tried " + len + " times of the providers " + providers + " (" + providers.size() + "/" + copyInvokers.size() + ") from the registry " + this.directory.getUrl().getAddress() + " on the consumer " + NetUtils.getLocalHost() + " using the dubbo version " + Version.getVersion() + ". Last error is: " + le.getMessage(), (Throwable)(le.getCause() != null ? le.getCause() : le));
}

failsafe

failsafe这种容错策略简单理解就是直接忽略异常，一般用在处理不重要的数据的场景中。

FailSafeClusterInvoker.java

public Result doInvoke(Invocation invocation, List> invokers, LoadBalance loadbalance) throws RpcException {
    try {
        this.checkInvokers(invokers, invocation);
        Invoker invoker = this.select(loadbalance, invocation, invokers, (List)null);
        return invoker.invoke(invocation);
    } catch (Throwable var5) {
         //出现异常直接记录日志后，返回一个人假的成功结果，没有做任何处理
        logger.error("Failsafe ignore exception: " + var5.getMessage(), var5);
        return new RpcResult();
    }
}

failback

failback这种策略是通过把失败的任务添加到定时任务定进行定时的重试。

FailbackClusterInvoker.java

//记录失败的任务
private void addFailed(LoadBalance loadbalance, Invocation invocation, List> invokers, Invoker lastInvoker) {
    if (this.failTimer == null) {
        synchronized(this) {
            if (this.failTimer == null) {
                //初始化Timer定时器
                this.failTimer = new HashedWheelTimer(new NamedThreadFactory("failback-cluster-timer", true), 1L, TimeUnit.SECONDS, 32, (long)this.failbackTasks);
            }
        }
    }
    //创建用于重试的定时任务
    FailbackClusterInvoker.RetryTimerTask retryTimerTask = new FailbackClusterInvoker.RetryTimerTask(loadbalance, invocation, invokers, lastInvoker, this.retries, 5L);
    try {
        //启动定时，每个5秒钟执行一次
        this.failTimer.newTimeout(retryTimerTask, 5L, TimeUnit.SECONDS);
    } catch (Throwable var7) {
        logger.error("Failback background works error,invocation->" + invocation + ", exception: " + var7.getMessage());
    }

}

protected Result doInvoke(Invocation invocation, List> invokers, LoadBalance loadbalance) throws RpcException {
    Invoker invoker = null;

    try {
        this.checkInvokers(invokers, invocation);
        invoker = this.select(loadbalance, invocation, invokers, (List)null);
        return invoker.invoke(invocation);
    } catch (Throwable var6) {
        logger.error("Failback to invoke method " + invocation.getMethodName() + ", wait for retry in background. Ignored exception: " + var6.getMessage() + ", ", var6);
        //开启定时重试
        this.addFailed(loadbalance, invocation, invokers, invoker);
        return new RpcResult();
    }
}

forking

并行调用多个服务提供者，只只要有一个返回即算调用成功，适合对实时性要求比较高的幂等性操作。

public Result doInvoke(final Invocation invocation, List> invokers, LoadBalance loadbalance) throws RpcException {
    try {
        checkInvokers(invokers, invocation);
        final List> selected;
        final int forks = getUrl().getParameter(FORKS_KEY, DEFAULT_FORKS);
        final int timeout = getUrl().getParameter(TIMEOUT_KEY, DEFAULT_TIMEOUT);
        //如果forks的值小于0或比服务提供者的数量多，那么选择的范围就是全部的服务提供者
        //对应的Invoker
        if (forks <= 0 || forks >= invokers.size()) {
            selected = invokers;
        } else {
            //否则，利用负载均衡，选出指定数量的Invoker，参加forking调用
            selected = new ArrayList<>();
            for (int i = 0; i < forks; i++) {
                Invoker invoker = select(loadbalance, invocation, invokers, selected);
                if (!selected.contains(invoker)) {
                    //Avoid add the same invoker several times.
                    selected.add(invoker);
                }
            }
        }
        RpcContext.getContext().setInvokers((List) selected);
        //定义一个计数器，用来记录调用失败的数量
        final AtomicInteger count = new AtomicInteger();
        //定义一个阻塞队列，用于存在每个invoker调用返回的结果
        final BlockingQueue