Dubbo学习笔记

       在阿里的大神同学说阿里内部早已不再使用Dubbo了，已转为新研发出的分布式框架。不得不感慨阿里的技术研发真的是走在整个中国的前端呀，无比崇拜进入阿里工作的大神同学（星星眼~）。虽然dubbo已经退出了阿里的舞台，但目前依然是中小型企业的分布式解决方案首选，丰富的中文文档支持和应用经验，依然是十分火热的~此处鄙视一下自己，身在制造业传统IT四年时间里，竟然到今年才开始接触Dubbo，尚无实际开发经验，自愧不如啊……

       好好学习，天天向上~

       以下整理一些优秀文章的讲解：

 

1. 协议

   Dubbo默认使用的是dubbo协议，

• 连接个数：单连接
• 连接方式：长连接
• 传输协议：TCP
• 传输方式：NIO 异步传输
• 序列化：Hessian 二进制序列化
• 适用范围：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用 dubbo 协议传输大文件或超大字符串。
• 适用场景：常规远程服务方法调用

Dubbo不适合高并发传输大文件的原因（以下是我一些个人的理解，可能有误，望指正~）：

NIO本身是异步IO传输，这一特性导致了线程在读取数据的处理就更为复杂，当传输的文件太大时，必然导致判断数据传输完成轮询次数增加，在高并发场景下加大了线程的开销和阻塞的可能性，影响速度和数据正确性。

2. 注册中心的选择

目前官方推荐使用的注册中心是zookeeper，当然这也不是唯一的选择，还有multicast，redis，simple都是dubbo支持的注册中心。

zookeeper是一个树型的目录服务，支持变更推送，适合作为Dubbo服务的注册中心，工业强度较高，可用于生产环境，推荐使用

流程说明：

1. 服务提供者启动时

向/dubbo/com.foo.BarService/providers目录下写入自己的URL地址。

2. 服务消费者启动时

订阅/dubbo/com.foo.BarService/providers目录下的提供者URL地址。

并向/dubbo/com.foo.BarService/consumers目录下写入自己的URL地址。

3. 监控中心启动时

订阅/dubbo/com.foo.BarService目录下的所有提供者和消费者URL地址。

支持以下功能：

• 当提供者出现断电等异常停机时，注册中心能自动删除提供者信息。
• 当注册中心重启时，能自动恢复注册数据，以及订阅请求。
• 当会话过期时，能自动恢复注册数据，以及订阅请求。
• 当设置<dubbo:registry check="false" />时，记录失败注册和订阅请求，后台定时重试。
• 可通过<dubbo:registry username="admin" password="1234" />设置zookeeper登录信息。
• 可通过<dubbo:registry group="dubbo" />设置zookeeper的根节点，不设置将使用无根树。
• 支持*号通配符<dubbo:reference group="*" version="*" />，可订阅服务的所有分组和所有版本的提供者

此处插入一个问题（摘抄自：关于dubbo的一个面试题）：当注册中心的服务器全部宕机时，dubbo是否还可以正常提供RPC服务？

答案：会，因为dubbo程序在启动后接收到来自注册中心的服务信息并且以cache文件的形式保存到本地，

文件内容为服务的地址信息：

因此在注册中心无法使用后，dubbo也能使用本地的缓存信息继续调用服务。

 

未完待续~