深入理解Dubbo源码(一)，如何高效的阅读Dubbo框架源码

这几天一直在探索Dubbo源码，本来也想写一系列Dubbo源码分析文章的，但觉得没必要，因为官方文档的源码导读就介绍了怎么去阅读Dubbo的源码，今年也出了本书《深入理解Apache Dubbo与实战》，也有前辈写了几篇Dubbo源码分析的文章。我可能也会写几篇，但不会系统的去分析。

说个题外话。喜欢去旅行的朋友，你们是否都会在出发之前做好攻略？即便是一场说走就走的旅行，也至少会去设计路线，才能顺利到达目的地。旅游，我们需要提前想好，都玩哪些景点，路线是什么，选择什么交通方式去，预算是花多少。选择景点就是非常明确的需求，我就是想去看布达拉宫，还有去青藏高原骑马(一本正经的胡说八道)。路线就是实现需求的计划，是先去布达拉宫还是青藏高原。选择交通方式就是技术选型，是搭飞机呢还是高铁转火车呢，这涉及到成本以及其它因素的考虑。景点内的消费则属于不可预测的需求。

笔者最近的一次重构项目选择用dubbo去实现服务间的调用，选择dubbo作为分布式的RPC远程服务调用框架，但笔者在使用的过程中遇到了很多疑难问题，网上搜不到一篇能解决我疑问的文章，无奈，只能选择自己从源码中寻找答案。

项目重构后，高并发的服务接口响应时间明显延长很多，可以说是翻倍，意味着QPS下降，与高并发低时延达的目标背道而驰。如果说，同样的机器数量、硬件配置，服务在重构前能抗下的并发量，重构后需要添加机器，虽然说重构后系统的扩展性更强，但收益不变而成本增加，在短期看来是愚蠢的操作。

使用Dubbo的过程中，我有很多的疑问，比如，服务消费端配置的长连接数是否生效，是轮询方式每次请求拿其中一个连接还是随机的，同一个消费服务多处地方引用同一个提供者接口，那配置的长连接数是用谁配置的？这些都关系到性能调优。这里可以给大家一个肯定的答案，比如配置20个长连接，那么每次请求调用次数都会加1，然后用调用次数与连接数取模拿到连接数组的下标。连接会在生成引用代理的时候创建所有连接，如果是惰性连接，则需要用到时才去建立连接。

那么，我是如何去分析源码的呢。我不记得我是在哪篇文章写过如何去看框架源码了，但还是那句话，不要一开始就扎进框架源码，不然你会迷失在复杂的代码迷宫中。在做新需求的时候，会有技术选型，而技术选型要求架构师必须要掌握多种技术框架，了解其优缺点。了解一个框架，首先要知道它提供的功能是什么，它都帮我们做了哪些活，它的工作流程是什么。对，就是去了解一个框架的工作原理，或者说是设计原理。只有了解它的工作原理，才能在迷宫中找到前进的方向。

如何更高效快速的去掌握一个框架的源码，我们可以在了解其工作原理之后，我们可以借鉴前人分享的经验。比如，找这个框架的源码分析教学视频、文章，一般主流的框架都会有，看些比较系统性的，理解多少看个人，但至少，你对这个框架又多了一些了解，也从别人那学到看这个框架源码的一个思路。

最后是带着问题去看源码。首先，跟着官方介绍的设计原理，去源码找一下大体流程的代码，最好是看官方的，官方的靠谱。比如，dubbo服务消费者调用提供者接口的一个大体流程。你能找出来，说明去一个目的地的大体路线你已经知道了，那么接下来就带着疑问去看。比如，消费者调用提供者接口时，失败是怎么重试的。去目的地的大体路线知道了，就是搭飞机直达，那得要知道怎么去机场。

总结就是一句话，从整体到细节。其实道理非常简单，我们开发一个项目，总是先搭建框架，再去实现业务细节。你想一下，任何一个框架，肯定都是为解决某一需求而设计的，那它的目的就很简单，就是实现什么样的功能，实现功能之前就是框架的搭建，最后是支持各种各样的功能，框架大体不变，读源码的流程就不变。比如spring，spring最初的设计应该是作为一个ioc容器，那它肯定是围绕着实现ioc容器这一目标去做设计，实现框架代码的编写，不管版本怎么变，它都是一个ioc容器，而aop是在此基础上新增的支持。

可能很多人会陷入这样的误区，就是认为看源码一定要选最新的版本去看，其实没有必要的。一般来说，一个框架越早的版本，它的实现越简单，越容易看懂，结合你们公司的项目理解，是不是现在的版本比刚开发完成时候的复杂很多，臃肿很多，但是整体的架构是没有多大变化的。所以，我们找早先的版本去看，看懂后再去看新的版本，针对性的去看，比如新版本增加了什么功能那就去看新增加的功能的代码，比如某些实现上有过大的改动，那就去看改动后的代码。除了更容易看懂框架源码外，更能收获到该框架改进上的一些思想。

在此，我要感谢简书作者：八哥帮你改bug。看了他分析dubbo源码分析系列文章后，对dubbo有了初浅的了解，为我阅读dubbo源码铺了路，感谢！有兴趣想要阅读dubbo源码的朋友，推荐阅读这位读者写的dubbo源码分析系列文章。官方文档有源码导读，要想深入去了解源码，看官方的源码导读文档就非常的有必要。文章开头也给大家推荐了《深入理解Apache Dubbo与实战》这本书，我也买了一本，但我不是特别想推荐。最重要的一点，还是要坚持。

有朋友在后台给我留言：最近我在看《深入理解计算机系统》，也讲到了汇编，也算看懂，这些东西感觉接近了底层实现，才感到真实，编程的真实。不然连一个函数的调用都不了解，对我而言实在是一种迷失编程的痛苦。

为他点赞！说实话，这个留言让我产生了共鸣。为什么说基础最重要，越了解底层在技术这条道路上才会越好走。

就拿dubbo源码分析来说，为什么我能短短几个晚上的时间就能看懂，因为dubbo底层使用的netty我非常了解，甚至是Socket通信，tcp协议，netty源码，我也用netty写过很多项目，比如笔者现在负责的项目中，高并发的服务就是用自己基于netty封装的http服务引擎，比如最近写的服务监控项目，也是用的netty，其中远程调用获取响应结果用的跟dubbo一个实现原理，而在此之前我是没看过dubbo源码的。所以，我看dubbo源码非常的容易理解。基础越扎实，越容易接受新事物，但是也不要心急，基础是靠慢慢积累的。

你是否也迷失在盲目追求学习新框架的道路上？那么，我建议你停下脚步，调整方向，补基础、补基础、补基础！想读dubbo源码的朋友，如果还不懂netty，还要先学习netty，用好netty，再看dubbo，不然你很难理解dubbo底层的远程服务调用流程。

如何快速的看懂dubbo框架源码，其实没有什么捷径，只要多下点功夫，多少会有所收获，提前是姿势要正确。

今天是我第二次"白写一天代码"，伤筋动骨的事情干不了。只要涉及数据库的改动，就是寸步难行。不得不说，这系统设计得确实烂。管理后台写得，就像小孩的玩具屋，那场面，你懂的。权限管理像根刺一样，想拔都拔不掉。所以，系统的设计，不要只是一味的把功能堆积起来就行了，一定要考虑到扩展性，性能的追求也应该是建立在系统良好的扩展性之上。下一篇介绍，jdk与dubbo的SPI，dubbo使用SPI机制实现高可扩展性，学习一下优秀框架的设计思想。