全网最细的nacos服务端服务注册：没有之一

本文主要是介绍全网最细的nacos服务端服务注册：没有之一，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

服务端注册入口

BaseRpcServer

由于有@PostConstrct注解，也就是说在构造方法后会执行，startServer会由它的子类BaseGrpcServer.startServer重写

BaseGrpcServer.startServer

addServices：

其中grpcCommonRequestAcceptor和grpcBiStreamRequestAcceptor就是实现了nacos_grpc_service.proto的两个子处理类
public class GrpcRequestAcceptor extends RequestGrpc.RequestImplBase {
�public class GrpcBiStreamRequestAcceptor extends BiRequestStreamGrpc.BiRequestStreamImplBase {
�
对应nacos_grpc_service.proto中的两个方法处理

service Request {// Sends a commonRequestrpc request (Payload) returns (Payload) {}
}service BiRequestStream {// Sends a biStreamRequestrpc requestBiStream (stream Payload) returns (stream Payload) {}
}

GrpcRequestAcceptor.request

这里最终会调用到InstanceRequestHandler.handle方法，不用猜基本上就知道要做什么，实例相关的操作

InstanceRequestHandler.handle

最终会调用到EphemeralClientOperationServiceImpl.registerInstance

EphemeralClientOperationServiceImpl.registerInstance

具体做了几件事：

1. 从ServiceManger里面通过service来获取service（包含namespace,group,name,ephemeral=true），我们来看一下ServiceManger具体是什么样子的存储结构？

更加形象的是这样：

2. 从ClientManger通过clientId获取Client，这里我们来看一下clientId、ClientManger、Client分别是什么？

ClientId:

ClientManger: 专门用来管理客户端连接的组件

Client：客户端信息
上图中connectionBasedClientManger里面的clients属性 ，里面存储的key、value，key为clientId，value为客户端信息，也就是上面的ConnectionBasedClient

3. 创建发布信息，并将发布信息放到ConnectionBasedClient中

将Service和publishInfo放到publishers中，实际的数据如图：

4. 发布ClientRegisterServiceEvent�事件，具体需要看看这个事件是由谁来处理，其实很好找，看看这个那个类使用了这个事件就行，最终找到了ClientServcieIndexesManger
   

ClientServiceIndexesManager.handleClientOperation

这里总结一下做了几件事：

1. 将service以及clientId放到publisherIndexes中，存储的格式就是<Service,Set>,更加形象的图如图：

2. 发布ServiceChangedEvent事件，这个事件最终会被NamingSubscriberServiceV2Impl给处理

NamingSubscriberServiceV2Impl.onEvent

这里会将事件封装成PushDelayTask，然后使用delayTaskEngine，这里的delayTaskEngine是PushDelayTaskExecute

PushDelayTaskExecuteEngine�.addTask

PushDealyTaskExecuteEngine继承了NacosDelayTaskExecuteEngine，最终会调用到父类的addTask方法



其实这里比较简单，就是把task加入到ConcurrentHashMap里面去，key就是Servcie，value就是pushDelayTask

加入到这个ConcurrentHashMap肯定是要被处理的，那我们看看是在哪里被处理？

1. NacosDelayTaskExecuteEngine在构造方法里面创建了一个定时调度的线程池，里面有一个被定时调度的任务，每隔100ms被调度执行

2. NacosDelayTaskExecuteEngine.processTask

遍历上面的concurrentHashMap，然后通过taskkey然后找到处理类，因为我们没有设置，所以这里的NacosTaskProcessor就是子类PushDelayTaskExecuteEnginge里面设置的PushDelayTaskProcessor

3. PushDelayTaskProcessor.process

这里的NacosExecuteTaskExecuteEngine还是需要详细分析一下

到这里用图总结一下从NamingSubscriberServiceV2Impl.onEvent到此处：

NacosExecuteTaskExecute.addTask

NacosExecuteTaskExecute.addTask

逻辑比较简单，先看看它有没有对应的NacosTaskProcessor，实际就是没有的（key没有，默认也没有设置），接下来就直接通过getWorker来处理

从executeWorkers中取一个TaskExecuteWorker给这个task来执行，所以我们要看一下这个executeWorkers到底是什么？

这里的TaskExecuteWorker就是一个单线程执行器

TaskExecuteWorker.process

又是似曾相识的套路，往queue里面塞东西，那具体在哪里处理的？
里面有内部单线程处理：

也就说最终还是会调用到传进来task的run方法，看到这里感觉无比的累啊，应该快结束了

到这里也拿一张图总结一下：

PushExecuteTask.run

总结一下做了几件事：

1. 生成推送数据：generatePushData
   1. 通过serviceIndexesManger + service能找到service对应那些clientId

2. 通过clientManger+ clientId能找到client对应的发布信息publishers，再通过publishers+service能找到这个service对应的Instance

我们来看一下实际debug得到的数据：

3. 往serviceClusterIndex.put(service, clusters)

4. 往serviceDataIndexes.put(service, serviceInfo)

2. 推送给目标客户端
   1. getTargetClients: 通过ClientServiceIndexManger+ service来获取这个订阅这个service所有clientId

2. 遍历订阅这个service的所有clientId，通过ClientManger+ clientId找到这个客户端，再通过这个客户端的subsribers+ service就能知道这个客户端订阅这个service的详情了

3. 最后调用doPushWithCallback往订阅客户端推送数据

这篇关于全网最细的nacos服务端服务注册：没有之一的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---