首先看一下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的源码分析基本完成。
创作不易，如果觉得有用，请点赞关注！