Dubbo原理总结

Dubbo主要的节点角色及之间的关系

1. 主要的节点角色：
   
   • Provider：暴露服务的服务提供者
   • Consumer：调用远程服务的服务消费者
   • Registry：服务注册与发现的注册中心
   • Monitor：统计服务调用次数和调用时间的监控中心
   • Container：服务运行容器
2. 节点角色之间的关系：
   
   • 服务容器负责加载、运行服务提供者。
   • 服务提供者在启动时，向注册中心注册自己提供的服务。
   • 服务消费者在启动时，向注册中心订阅自己所需的服务。
   • 注册中心返回服务提供者地址列表给服务消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
   • 服务消费者，从服务提供者列表中，基于软负载均衡算法，选择其中一个提供者进行调用，如果调用失败，再基于失败策略进行重试或忽略。
   • 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次给监控中心。
3. Dubbo采用的nio异步的通信，通信协议默认为netty，当然也可以选择 mina、grizzy。在服务端（provider）在启动时主要是开启netty监听，在zookeeper上注册服务节点，处理消费者请求，返回处理后的消息给消费者，消费者使用服务时主要是订阅服务的节点，监听zookeeper节点目录，服务端的变化时zookeeper会推送给消费者，消费者重新缓存服务地址等。服务者、消费者、zookeeper三者之间都是长连接。

Dubbo的集群容错方案

1. Failover：失败自动切换重试其他服务器，多用于读操作。可通过retries来设置重试次数。默认方案。
2. Failfast：失败后立即报错返回，不进行重试，多用于幂等性的写操作，如新增记录。
3. Failsafe：失败后直接忽略，不影响后续操作，多用于记录日志。
4. Failback：失败后记录失败请求，定时重发，多用于消息通知。
5. Forking：并行调用多个服务器，只要一个成功即返回，多用于实时性要求高的都操作。
6. Broadcast：广播所有提供者，逐个调用，任意一台报错则报错，多用于通知所有提供者更新缓存货日志等本地资源信息。

Dubbo负载均衡策略

1. 随机负载均衡：先统计所有服务器上该接口方法的权重总和，然后对这个总和随机nextInt一下，看生成的随机数落到哪个段内，就调哪个服务器上的该服务。
2. 轮询负载均衡：如果所有服务器的该接口方法的权重一样，则直接内部的序列计数器（sequences）+1然后对服务器的数量进行取模来决定调用哪个服务器上的服务；如果服务器的该接口方法的权重不一样，则找到其中最大的权重，然后将内部的权重计数器（weightSequences）+1并对该最大权重数取模，然后再找出权重比该取模后的值大服务器列表，最后通过内部的序列计数器（sequences）+1然后对服务器列表数量进行取模来决定调用哪个服务器上的服务。缺点是存在慢的提供者堆积请求的问题。
3. 最少活跃负载均衡：每个接口和接口方法都对应一个RpcStatus对象，记录了他们的活跃数、失败数等等相关统计信息，此种负载均衡方式是在活跃数最低的服务器中对其权重的总和取模来看结果是在哪个权重段中，则选择该服务器来调用，开始调用时活跃数+1，调用结束时活跃数-1，所以活跃值越大，表明该提供者服务器的该接口方法耗时越长，而消费能力强的提供者接口往往活跃值很低。最少活跃负载均衡保证了“慢”提供者能接收到更少的服务器调用。
4. 一致哈希负载均衡：一致性哈希算法的负载均衡保证了同样的请求（参数）将会落到同一台服务器上，Dubbo中默认采用了160个虚拟节点，因为Dubbo的请求URL中除了我们使用的参数，还有些额外的系统调用参数，比如timestamp、loadbalance、pid和application等。
5. 源码可参考：http://blog.csdn.net/hdu09075340/article/details/53169461

多注册中心

指同一个服务消费者，可以连接两个不同的服务注册中心，不同的服务注册中心中可以提供同一个服务的不同实现版本。

服务容错性设计

1. 可以从两个方面思考，微观角度和宏观角度。
2. 从微观角度思考（单纯从服务出发）：
   
   • 超时timeout（consumer端）：保护服务，尽量让消费端保持原有的性能。超时时间的选取，一般根据业务的正常响应时间+一个缓冲时间。
   • 重试retry（consumer端）：失败后重试，可以减少因为网络的偶尔抖动导致的失败。但重试对于一些类似新增的有幂等性要求的接口就必须注意。
   <