Nacos服务端源码浅析

首先看一下nacos项目源码结构：

 包含的模块有点多，入口就是nacos-console

查看该模块的相关依赖，如下截图所示：

在做源码分析之前，请注意：nacos客户端和服务端通信入口在哪里？

在前面分析client源码时，有关于通信的解析，最终发送消息的入口如下：

 通过上一篇文章的讲解，可以知道这是grpc通信框架的api，具体的底层原理，这里暂时不做讨论

那么在nacos的服务端是在哪里接收这个请求的呢？

首先我们查看一下:grpcFutureServiceStub是什么东西？

 根据我们之前关于proto buf 的使用经验，肯定在.proto的文件中定义了如下service

service Request (Payload)  returns (Payload) 而且根据该类的pack信息

 于是在nacos-all项目中全局搜索：option java_package = "com.alibaba.nacos.api.grpc.auto";

查看到如下的.proto文件：

 由以上.proto文件定义证实了之前的猜测。再有之前的使用经验看，肯定有个类，实现了:

RequestGrpc.RequestImplBase(Grpc的生成规则)

于是全局搜索：

 如上截图，相信该类即是nacos客户端和服务端交互的rpc通信入口类(由注释也可佐证得到)

 

GrpcRequestAcceptor是如何接收请求，并且分发请求的？

相信有源码阅读经验的同学看到如下代码，一般就会明白：

 RequestHandler是一个接口，实现类有如下截图：

 在这里，会根据请求类型的不同，匹配不同的处理器，如果是做配置请求，发送的请求类型是：

ConfigQueryRequest---》ConfigQueryRequestHandler

 通过从参数中获得dataId，groupId等等信息，最终把请求委托给persistService实现：

 最后通过数据库查询，返回数据，这就是nacos中关于客户端和服务端通信分析逻辑。

同理，如果在nacos的管理页面查询，是通过http请求调用到服务端接口的：

最终的请求还是有persistService.findConfigInfo(dataId,group,tenant)实现

至此，客户端同服务端通信和页面请求分析完毕

nacos服务端的服务启动代码入口在哪里？

 如上截图，BaseRpcServer的实现类GrpcSdkServer，和GrpcClusterServer均是spirng容器中的bean，在初始化时既会启动grpc的服务，用于监听请求(具体的底层通信，这里不做分析)

 

以上完整的分析了nacos作为配置中心时的服务端和客户端通信全过程，在来简单分析一下nacos作为注册中心时的通信过程，相信会更简单了

 以上就是nacos客户端往服务端注册过程。

 最终把注册请求委托给了NamingGrpcClientProxy的rpcClient通信完成。这里和配置时的通信策略一样，最终发起请求还是调用的

只是此时，发送的请求类型变成了： 

 相应的在服务端的处理器也变成了：

 大致逻辑已经梳理完毕

注册中心的心跳维护时在哪里发起的？频率是多少？

如下的类继承关系：

 NacosNamingService在初始化时，会初始化NamingClientProxyDelegate---》NamingGrpcClientProxy--》RpcClient

初始化RpcClient之后，会调用RpcClient的start方法

此时会启动2个定时任务：

消费连接事件

 

 这里即是关于心跳事件维护：

 从源码中可以看出，心跳事件是5000L(5秒)，同理，也是基于Grpc发起的rpc调用，发送的请求类型是：HealthCheckRequest

在服务端处理该请求的handler是：

至此，关于nacos的源码分析基本完成。

创作不易，如果觉得有用，请点赞关注！