Dubbo总结

是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案

Dubbo能做什么？

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

Dubbo分两块

• 高性能和透明化的RPC远程服务调用方案
• SOA服务治理方案

Dubbo的通信基础

• Dubbo缺省协议采用单一长连接和NIO异步通讯,适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况
• 默认基于netty + hessian 交互
• 支持的协议
  • Dubbo协议
  • Hessian协议
  • HTTP协议
  • RMI协议
  • WebService协议
  • Thrift协议
  • Memcached协议
  • Redis协议

Dubbo架构原理

• 连通性说明

  • 注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小；监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示。
  • 服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销；服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销。
  • 注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外；注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者；注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表；注册中心和监控中心都是可选的，服务消费者可以直连服务提供者。

• 健状性说明

  • 监控中心宕掉不影响使用，只是丢失部分采样数据
  • 数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务
  • 注册中心对等集群，任意一台宕掉后，将自动切换到另一台
  • 注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯
  • 服务提供者无状态，任意一台宕掉后，不影响使用
  • 服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复

• 伸缩性说明

  • 注册中心为对等集群，可动态增加机器部署实例，所有客户端将自动发现新的注册中心
  • 服务提供者无状态，可动态增加机器部署实例，注册中心将推送新的服务提供者信息给消费者

注册中心分类

• Simple注册中心
• Multicast注册中心
• Redis注册中心
• zookeeper注册中心
  使用zookeeper作为服务中心为例， 服务提供者启动后会在zookeeper的/dubbo节点下创建提供的服务节点，包含服务提供者ip、port等信息。 服务提供者关闭时会从zookeeper中移除对应的服务

集群容错

当服务调用失败时（比如响应超时），根据我们的业务不同，可以使用不同的策略来应对这种失败

• failover: 当调用失败时，自动切换到其他服务提供者去调用，当失败次数超过指定重试次数，那么就抛出错误
• failfast: 如果第一次调用失败，立即报错，不需要重试
• failsafe: 出现错误，直接忽略，不重试也不报错
• failback: 失败后不报错，会将该失败请求，定时重发(适合消息通知类型的服务)
• forking: 并行调用多个服务器，只要在某一台提供者上面成功，那么方法返回， 适合实时性要求较高的查询服务， 但是要牺牲性能。因为每台服务器会做同一个操作
• broadcast: 广播调用所有服务提供者，逐个调用，任意一台报错则报错。(适合于更新每台提供者上面的缓存,这种类型的服务)

服务版本、服务分组

通过服务版本可以控制服务的不兼容升级， 当同一个服务有多种实现时，可以使用服务分组或版本进行区分

负载均衡(dubbo的软负载策略)

• random: 随机选提供者，并可以给提供者设置权重
• roundrobin: 轮询选择提供者
• leastactive: 最少活跃调用数。相同活跃数的随机。活跃数指调用前后计数差。使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大
• consistenthash: 一致性hash，相同参数的请求发到同一台机器上