DUBBO源码解析(6)-summarize

一、总结

为期六期的Dubbo源码解析，这是最后一期《总结》

1、性能：我一直觉得讨论性能，是程序员界的俗人才做的事情。

A程序调用100万次130秒，B程序调用100万次68秒，因此说B程序的性能高。---这是新时代的盲人摸象

实际上，程序性能影响因素至少包括了CPU、磁盘IO、带宽、网络碰撞、通讯质量等等诸多因素。我大可夸夸其谈的说：根据数据统计A的CPU使用率较低，而B的CPU使用率较高，A的磁盘IO少，而B的磁盘IO多，因此说明A的代码逻辑合理性有待改善，还有优化空间；而B在网络带宽表现不佳，因此如果我们能把50M的网速升级到100M则会提升较大的稳定性，而随着服务器的增多，网络碰撞也是我们需要考虑的，我们需要按照网段和应用进行隔离，保证每个网段之间的冲突减少到最小……

此等夸夸其谈我能谈几夜不休，但是实际操作的时候，我还是得看实际效果的。

有人和我评价是Dubbo的性能较差，我觉得吧，够用就好。在同等代码质量的前提下，代码越多性能越差，可以这么认为：

在相同的代码质量下，性能是和代码数量成正比的。比谁的性能好不过是在比谁的代码更少而已。

前段时间我写了个KB的RPC调用，绝对的原生态，绝对的高性能，但是我坚决不会用它……

2、实用性：我觉得Dubbo的实用性还是比较优秀的，Dubbo是服务治理的代表，从其作者梁飞的博文http://javatar.iteye.com/blog/1345073《服务治理过程演进》

1. 服务注册与发现 
2. 软负载均衡与容错 
3. 服务监控与统计 
4. 服务容量评估 
5. 服务上线审批 -->DUBBO并未实现，但是无影响
6. 服务下线通知 -->DUBBO并未实现，但是无影响 
7. 服务负责人   -->DUBBO已实现，但是实用性堪忧
8. 服务文档    -->DUBBO并未实现，但是无影响 
9. 服务路由     -->DUBBO已实现，但是使用较少
10. 服务编排    
11. 服务黑白名单 
12. 服务权限控制 -->DUBBO并未实现，但是无影响
13. 服务依赖关系 -->DUBBO并未实现，但是无影响
14. 服务分层架构 
15. 服务调用链跟踪 -->DUBBO并未实现，但是无影响-->需要第三方插件实现
16. 故障传导分析   -->DUBBO并未实现，但是无影响
17. 服务降级         -->DUBBO并未实现，但是无影响
18. 服务等级协定   -->DUBBO并未实现，但是无影响
19. 服务自动测试   
20. 服务伪装容错     ->DUBBO并未实现，但是无影响
21. 服务兼容性检测     ->DUBBO并未实现，但是无影响
22. 服务使用情况报告 
23. 服务权重动态调整 
24. 服务负载均衡调整 
25. 服务映射 
26. 服务模板工程 
27. 服务开发IDE     ->DUBBO并未实现，但是无影响
28. 服务健康检测 ->DUBBO并未实现，但是无影响
29. 服务容器     ->需要第三方方案
30. 服务自动部署 ->需要第三方方案
31. 服务资源调度 ->需要第三方方案

可以总结，Dubbo最重要的是实现了如下功能：

1、服务注册与发现
2、软负载均衡与容错
3、服务监控与统计 
4、服务容量评估
5、服务编排
6、服务黑白名单
7、服务权重动态调整
8、服务负载均衡调整

这些功能已经足够解决大型公司的各组织机构的项目耦合、人员效率、系统稳定性，系统扩展性和伸缩性等问题。

3、Dubbo框架设计：

3.1 紧凑

在Dubbo框架设计中，全局围绕着URL,Protocol,Exportor,Invoker等概念进行。

一切资源都是URL，根据URL可以选择不同的协议如:ZookeeperRegistry、RegistryProtocol,DubboProtocol，进而生成DubboExporter或者DubboInvoker，进而调用底层的HeaderExchange进行数据发送与接受，底层通过异步通讯框架进行通讯

整个框架显得很紧凑，作者费了很多心血在各个对象之间的交互上面。

3.2 面对对象

但局部的风格我认为写的太复杂，不是给人类看的……

我一直不喜欢面对对象式开发，一是因为我认为面对对象用在Java中是浪费，二是面对对象的领域太多人写个god就开始.do

举例：dubbo中的invoke.invoke，单看代码是看不懂的，只有在实际运行中，联系上下文才能知道这究竟是一个AbstractCLusterInvoker.invoke以获取zookeeper中的数据，还是一个DubboInvoker.invoke以进行服务器调用，甚至同一个FailoverClusterInvoker.invoke，你都需要根据param,getUrl().getProtocol()等一系列操作才能看懂究竟调用的是哪个函数。

此外我还有比较不赞同的一点，Dubbo中有一些代理类，例如ProtocolAdaptive等Adaptive类，这些类属于拿着源码也看不懂的类型，你必须得用Dump工具，在进程中把这些动态类的字节码dump下来，反编译完成后才能看懂究竟这些类是什么含义

Dubbo硬生生的把java写成了javascript这样的动态语言–>只有在运行时根据对象才能知道调用的方法是什么。

3.3 工具

dubboAdmin我挺喜欢的，如果有短信报警或者邮件报警就更好了。从工具的角度看，Dubbo已经成为了一个“生态化”的产品，大量的公司在使用原生或者衍生的Dubbo，一系列的服务治理工具，监控工具，流量控制等插件也越来越多，能用到的地方是比较多的。