7、Nacos 服务注册服务端源码分析（总结篇）

本篇主要是总结一下服务端注册的整体流程。之前的几篇可能是在在跟踪代码流程的过程中，对代码中的各个重点逐个击破，并没有完整的叙述过程的全貌，可能都只是分析冰山的一角。但是我们应该站在更高的角度去审视整个框架，整个流程。去思考哪些地方可以值得我们去借鉴。假如你是作者，你也会如此设计么，或者为什么作者要这么设计。

注册流程V1

首先理解一下服务端是做什么用的。注册中心，代码里面是NameServer，翻译过来是名字服务。也就是一个服务，存储这各个客户端（这个客户端可以是生产者，也可以是消费者）的服务名，通过服务名去获取到各个客户端的连接信息（包括ip、端口、权重、元数据等）。这样在需要使用服务的时候，就可以获取到对应的服务。然后客户端通过一定的负载策略，去连接一个客户端，完成数据的交互。那这个整体框架就好理解了。就是客户端将信息注册到服务端，服务端需要存储信息，存储的方式有多种，比如内存，磁盘，外部数据库等。最基本的要求是能保证存储下来不丢失，然后能够承担一定的并发，保证其性能。服务端存储信息后，其他客户端需要获取这部分服务端的信息。也有两种方式：

1. 通过客户端轮询的方法拉取信息
2. 服务端发现信息变动后直接推送给客户端。

这两种方式各有利弊。

拉取的优势是代码更容易编写，成本低。缺点是需要做很多无用功。

推送的优势是可以及时准确的处理，缺点是成本高，写法复杂。

那Nacos是怎么做的呢？

Nacos2.X采用了Grpc的方式进行通信。Grpc有着以下几大优点：

1. 长连接模型，双向数据数据传递，感知连接的异常（比如断线）
2. 性能高，采用protobuf，序列化方式快
3. 跨语言，可以支持各种语言的客户端，这样可以让其他语言也方便使用Nacos，比如go，Python，C等

确定了网络模型和序列化快速式后，就可以成功的让客户端到达服务端了。

下面通过流程图来直观的表现一下最精简版的注册流程（client->server->client)

注册流程V2

服务端看似简单的存储信息。如果都是直接请求直接存储。当客户端连接多，性能肯定是扛不住。所以需要快速的处理，提升性能。这里引入了一个重要的组件NotifyCenter。

NotifyCenter是一个订阅-发布的组件，我更愿意称之为一个订阅-发布平台。我们可以利用这个平台，将生产者和发布者联系起来。然后它里面包含了一个publisherMap,它的value是EventPublisher。而EventPublisher又是一个线程。在不断的接受事件，并通知订阅者处理。其流程图我们可以变为V2版本。细化服务端的通知中心。

注册流程V3

看到这里，心想着订阅者可以直接处理事件了。但是这里并没有直接这么处理。而是再次引入了一个新的概念TaskExecuteEngine。其将事件又再次分解，分解成两类任务，一类是立即需要执行的，一类是可以合并后延迟执行的。那什么是可以延迟执行的呢？针对一些超时，有问题的任务是可以延迟执行的。Task就是我们真正的处理逻辑了。然后这个流程图可以变为了V3版本。

从这个图来看下来，结构还是很清晰的。你可以根据下面这个流程去找你感兴趣的逻辑。

request -> requestHandler -> event -> onEvent -> taskEngine -> process-> taskk

总结

通过之前的几篇文章源码分析和本篇的图解。相信在读的小伙伴对整个服务注册流程有了更深的理解。我并没有在逻辑部分去扣很多细节，而是在整体的框架流程上进行分析。大家可以跟着这个思路自己去分析其他功能的源码。比如分析一下心跳检测的功能，获取服务信息的功能。相信有了整体认识后，分析源码就会变得更加轻松一些了。所以不管是看源码还是他人的代码，都可以按照下面思路来分析。

1. 找到入口，这个入口可以是一个方法，一个客户端调用，一个定时任务等等
2. 找到入口后，就跟着逻辑分析，但一开始要太针对细节部分，要先看流程，省略一些非核心代码，比如校验，获取配置信息等
3. 找到核心逻辑后将整个流程理顺。也就是从请求到返回的一系列过程。必须要跟踪到返回才行。
4. 整体流程了解清楚后，再一步步分析里面的核心逻辑，重点逻辑。
5. 学习作者的优秀写法，优秀设计。然后进行自我思考。最好学以致用，将其转化为自己的知识。写一个类似的demo，或者用于工作中，提升自己的能力和水平。