浅谈对Dubbo框架的认识

目录

Dubbo是什么

Dubb服务注册和上下线感知

---

工作前两年一直在使用的基本都是Cloud体系里的组件，都是基于cloud体系内提供的 Feign 组件来进行内部服务通信。最近这半年接触了新的技术栈，半年的工作中 感觉对分布式服务架构又有了更深的理解，分布式不一定要用Cloud所谓的微服务去构建，比如基于Dubbo服务再加上其他的一些像配置中心等组件去构建也是一样能实现分布式架构和服务治理的。

Dubbo是什么

从用途方面来说，Dubbo框架类似于SpringCloud体系中的Feign+Ribbon+Hystrix等组件，都是针对于分布式系统的通信和服务治理。

Dubbo框架是支持多协议的，如Dubbo、Rmi、http等，默认使用的是Dubbo协议，利用Netty通信框架基于TCP协议进行通信传输。这一点与Feign是存在区别的，Dubbo是基于TCP的传输层，而Feign则是基于Http协议，所以在性能和效率上Dubbo显然更高一些。

另外，Dubbo框架不需要依赖其他组件直接提供了四种负载均衡策略，分别是随机策略、轮询策略、最少活跃调用数策略和一致性 Hash策略。默认情况下为随机策略。

负载均衡源码位于org.apache.dubbo.rpc.cluster.loadbalance包下

• 随机 按权重设置随机概率。在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
• 轮询 按公约后的权重设置轮询比率。存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
• 最少活跃调用数 相同活跃数的随机，活跃数指调用前后计数差。使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
• 一致性 Hash 相同参数的请求总是发到同一提供者。当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

Dubb服务注册和上下线感知

Dubbo通过集成注册中心，来动态地治理服务发布和服务调用。Dubbo的注册中心有好多种，包括Multicast、Zookeeper、Redis、Simple等。Dubbo官方推荐使用Zookeeper注册中心。

Dubbo的服务注册就是在服务提供者启动后把信息注册到ZK中，注册后ZK会通过心跳机制来检查服务是否健康，如果服务出现异常就会剔除异常无效的服务注册信息。

之前写过一篇关于Zookeeper的Watch机制的文章，Dubbo就是借助于Watch机制实现了对消费者服务上下线的动态感知能力，当有昕服务注册后通过Watch机制通知到客户端刷新服务可用列表，同样当服务被剔除客户端也可以感知，保证被ZK剔除的服务不会再次被消费者调用。