前面我说过技术 leader 的几个特质， 明天还想跟大家分享下，作为技术 leader ，还要懂得研讨和引入技术，引入的 前提一定是要 Hold 住。怎样才叫 hold 住呢？就是能知晓运用它，可以深化了解它的架构、原理，可以剖析它的中心源代码。
以研讨 Nacos 为例，这次我分享下研讨技术的办法，授之以渔，希望大家有所播种，当然也欢迎留言共同讨论更好的技巧。
01 官方文档，搭建demo运用
很多人喜欢买书看，看别人的博客，其实都是吃剩饭，别人也是看了官方文档写的。一名合格的技术人员， 尽量从源头看，看官方的文档，原汁原味的，耐烦点一点点看。
Nacos 的官方文档，怎样看这个进程我就不讲了，基本上就是按目录过一遍，然后依据官方例子搭建起来，知道它的基本功用运用。
重点看看外面的架构设计、模型概念。
02 了解功用设计主线，确定研讨主线，高维度笼统功用模型
看完官方文档，基本会用后，要确定深化研讨的主线。 Nacos 不只仅包含了效劳管理功用，还包含了配置管理，元数据管理。看到这里其实也能明白为什么 Nacos 未来会成为注册中心的趋向，由于它同时包含了微效劳的两个套件：注册中心、配置中心，用了它能少部署一个配置中心。下图来自官方文档：
图片来源： nac os 官方文档
这篇文章我们研讨的主线是注册中心，所以只研讨它如何完成注册中心的。 这个时分，我们要高维度看，注册中心需求哪些功用？这些功用，是任何注册中心都需求完成的功用，要把这些掌握清楚。显然，注册中心通用的功用模型包含：
1. 效劳注册
2. 效劳心跳保活
3. 效劳下线（正常下线、异常下线）
4. 效劳发现
基本上完成下面四点，一个单体的注册中心就完成了。然后假设思索散布式，还要设计它如何完成 CP/AP 形式。
03 下载源代码，提取精髓
很多人看源码，学源码，往往都是看了一个寂寞，为了寂寞而寂寞。 究竟要看什么？
1. 源码看什么？
看源码，要看作者怎样架构、怎样设计、怎样完成，并思索为什么要这么完成，经过源码看到了它外面的精髓，才算真看了源码。不然就是看了个西瓜，吃了就没了，就是个吃瓜群众。相反，看源代码 ，提炼模型、原理、机制、设计形式、并发阅历、网络阅历、 OS 存储机制等 ，那你才算真看了源码，吸收了它的营养。
2.源代码怎样看呢？
抛开技术积聚和阅历要素外，办法也是很重要的一个部分。很多看源代码都没有阅历，看到源代码复杂，代码又多，一看就懵逼，也不知道从哪里看起。
我先分享 3 个阅历：
（ 1 ）找源头，就是启动的中央， 这个普通从脚本里看可以到，大部分中间件都是封装了启动脚本的，你就从这个启动脚本里找启动类，让源码能跑起来，后续可以 debug 验证。
（ 2 ）只看主线代码。 就是我们下面提炼的功用模型。那些日志、统计剖析、异常分支、非主线分支第一次都不要看。
（ 3 ）先静态看源码， 不要静态 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 来隔离这些不同的环境。
(责任编辑：admin)