Dubbo 介绍-工作过程-集群容错及负载均衡

Dubbo 是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。
Dubbo采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。

其核心部分包含：

• 远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。
• 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
• 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

Dubbo 能做什么？

• 透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。
• 软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。
• 服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。

Dubbo 框架工作过程是怎样的？

1. 系统运行时,服务提供方与服务调用方分离运行,当服务运行容器中服务提供方开始提供服务时,向注册中心注册使用者的服务、地址、调用方式等基本信息。服务调用方在需要调用服务时,向注册中心申请调用服务,注册中心将服务提供者信息返回给调用者,通过这些信息调用服务运行容器中的服务。
2. 服务运行过程中,监控机构监控双方情况,定期统计服务调用次数与服务调用时间等信息,以保证服务持续运行。如果服务提供者对服务有增减或变更,会及时通知注册中心,由注册中心与服务运行容器协作提供集群容错、软负载均衡等功能。

Dubbo 集群容错，并说明起作用以及应用场景

我知道的有六种，但不知道是否全面

1. Failover Cluster：失败重试
   当服务消费方调用服务提供者失败后自动切换到其他服务提供者服务器进行重试。这通常用于读操作或者具有幂等的写操作，需要注意的是重试会带来更长延迟。可通过 retries="2" 来设置重试次数（不含第一次）。
   接口级别配置重试次数方法 <dubbo:reference retries="2" /> ，如上配置当服务消费方调用服务失败后，会再重试两次，也就是说最多会做三次调用，这里的配置对该接口的所有方法生效。如果细化的方法的级别，可以把重试的参数加到方法的配置上。
2. Failfast Cluster：快速失败
   当服务消费方调用服务提供者失败后，立即报错，也就是只调用一次。通常这种模式用于非幂等性的写操作。
3. Failsafe Cluster：失败安全
   当服务消费者调用服务出现异常时，直接忽略异常。这种模式通常用于写入审计日志等操作。
4. Failback Cluster：失败自动恢复
   当服务消费端用服务出现异常后，在后台记录失败的请求，并按照一定的策略后期再进行重试。这种模式通常用于消息通知操作。
5. Forking Cluster：并行调用
   当消费方调用一个接口方法后，Dubbo Client会并行调用多个服务提供者的服务，只要一个成功即返回。这种模式通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks=“2” 来设置最大并行数。
6. Broadcast Cluster：广播调用
   当消费者调用一个接口方法后，Dubbo Client会逐个调用所有服务提供者，任意一台调用异常则这次调用就标志失败。这种模式通常用于通知所有提供者更新缓存或日志等本地资源信息。
   如上，Dubbo本身提供了丰富的集群容错模式，但是如果您有定制化需求，可以根据Dubbo提供的扩展接口Cluster进行定制。

Dubbo 的负载均衡

1. Random LoadBalance：随机策略。
   按照概率设置权重，比较均匀，并且可以动态调节提供者的权重。
2. RoundRobin LoadBalance：轮询策略。
   轮询，按公约后的权重设置轮询比率。会存在执行比较慢的服务提供者堆积请求的情况，比如一个机器执行的非常慢，但是机器没有挂调用（如果挂了，那么当前机器会从Zookeeper的服务列表删除），当很多新的请求到达该机器后，由于之前的请求还没有处理完毕，会导致新的请求被堆积，久而久之，所有消费者调用这台机器上的请求都被阻塞。
3. LeastActive LoadBalance：最少活跃调用数。
   如果每个提供者的活跃数相同，则随机选择一个。在每个服务提供者里面维护者一个活跃数计数器，用来记录当前同时处理请求的个数，也就是并发处理任务的个数。所以如果这个值越小说明当前服务提供者处理的速度很快或者当前机器的负载比较低，所以路由选择时候就选择该活跃度最小的机器。如果一个服务提供者处理速度很慢，由于堆积，那么同时处理的请求就比较多，也就是活跃调用数目越大，这也使得慢的提供者收到更少请求，因为越慢的提供者的活跃度越来越大。
4. ConsistentHash LoadBalance：一致性Hash策略。
   一致性Hash，可以保证相同参数的请求总是发到同一提供者，当某一台提供者挂了时，原本发往该提供者的请求，基于虚拟节点，平摊到其他提供者，不会引起剧烈变动。