怎么看源代码？
2023-02-26 17:34:05
今天想跟大家分享下，作为技术Leader，要懂得研究和引入技术，引入的前提一定是要Hold住。怎么才叫Hold住呢？就是能精通使用它，能够深入了解它的架构、原理，能够剖析它的核心源代码。
以研究Nacos为例，这次我分享下研究技术的方法，授之以渔，希望大家有所收获，当然也欢迎留言共同讨论更好的技巧。
— 1—
官方文档，搭建demo使用
很多人喜欢买书看，看别人的博客，其实都是吃剩饭，别人也是看了官方文档写的。一名合格的技术人员，尽量从源头看，看官方的文档，原汁原味的，耐心点一点点看。
Nacos的官方文档，怎么看这个过程我就不讲了，基本上就是按目录过一遍，然后根据官方例子搭建起来，知道它的基本功能使用。
重点看看里面的架构设计、模型概念。
— 2—
了解功能设计主线，确定研究主线，高维度抽象功能模型
看完官方文档，基本会用后，要确定深入研究的主线。Nacos不仅仅包含了服务管理功能，还包含了配置管理，元数据管理。看到这里其实也能明白为什么Nacos未来会成为注册中心的趋势，因为它同时包含了微服务的两个套件：注册中心、配置中心，用了它能少部署一个配置中心。下图来自官方文档：
图片来源：Nacos官方文档
这篇文章我们研究的主线是注册中心，所以只研究它如何实现注册中心的。这个时候，我们要高维度看，注册中心需要哪些功能？这些功能，是任何注册中心都需要实现的功能，要把这些掌握清楚。显然，注册中心通用的功能模型包含：
- 服务注册
- 服务心跳保活
- 服务下线（正常下线、异常下线）
- 服务发现
基本上实现上面四点，一个单体的注册中心就实现了。然后如果考虑分布式，还要设计它如何实现CP/AP模式。
— 3—
下载源代码，提取精华
很多人看源码，学源码，往往都是看了一个寂寞，为了寂寞而寂寞。到底要看什么？
源码看什么？
看源码，要看作者怎么架构、怎么设计、怎么实现，并思考为什么要这么实现，通过源码看到了它里面的精髓，才算真看了源码。不然就是看了个西瓜，吃了就没了，就是个吃瓜群众。相反，看源代码，提炼模型、原理、机制、设计模式、并发经验、网络经验、OS存储机制等，那你才算真看了源码，吸收了它的营养。
源代码怎么看呢？
抛开技术积累和经验因素外，方法也是很重要的一个部分。很多看源代码都没有经验，看到源代码复杂，代码又多，一看就懵逼，也不知道从哪里看起。
我先分享3个经验：
- 找源头 ，就是启动的地方。这个一般从脚本里看可以到，大部分中间件都是封装了启动脚本的，你就从这个启动脚本里找启动类，让源码能跑起来，后续可以debug验证。
- 只看主线代码 ，就是我们上面提炼的功能模型。那些日志、统计分析、异常分支、非主线分支第一次都不要看。
- 先静态看源码 ，不要动态debug，因为debug，很容易陷入细节，陷入各种分支，几绕几绕就懵逼了，然后就放弃了。静态看源代码，就是不断锻炼自己，让自己只看主线代码，那种明显是分支的直接跳过不看，这样快速的过主线。实在有疑惑了，然后debug验证下。
我们来看看Nacos的源码，版本是1.4.2，分析下我是怎么看的。
1、服务注册如何实现的？如何确保高并发？
客户端启动的时候，会通过http请求发送注册请求，请求链接采用RESTful模式。服务端接受到注册请求后，会把请求参数封装放到一个阻塞队列里，然后基于一个线程不断的获取这个阻塞队列的信息，放入到注册表中。
可以看到高并发设计的一个关键点：异步。这里还可以对比延伸，ZooKeeper如何实现的？Eureka如何实现的？这些实现之间有什么优劣？它们能否做到高并发？是否也是异步？这些就留给读者探索了。
2、服务注册表是如何设计的？为什么这么设计？以及怎么防止多节点的读写并发冲突？
Nacos支持CP和AP模式，如果不懂CP和AP的自己百度了，这种简单的概念我就不科普了。
①AP模式下，是基于内存存储的，底层其实是一个双重的map结构。CP模式下，数据是存储到文件的。这里我们主要还是研究AP模式。因为大多数场景下，我们注册中心更适合AP模式。
百万 源码 资源看到这个map结构，有没有思考过为什么这么设计？namespace的目的是？group的目的是什么？如果有一定DevOps经验的同学知道，我们一个项目环境往往可能有多套，比如开发环境、测试环境、预发布环境、线上环境等。如果每一套环境都部署一个注册中心，是不是很麻烦。所以这里namespace的目的，就是可以用同一套注册中心，基于namespace来隔离这些不同的环境。
那么group的目的是什么呢？如果我们用过Dubbo就知道这个概念了，对服务进行分组。有时候我们一个服务刚开始是一个大服务，但随着业务扩展，有时候需要拆成几个小服务，这样就可以设置为一个group。
这些都是基于可扩展性来考虑设计的。我们看看官方文档的数据模型：
