禅与计算机
sharkchili
2026-03-25
目录

Nacos服务注册原理全解析

@[toc]

# 引言

本着引导性启发的理念，笔者将以个人调试阅读的角度带读者了解一下笔者如何完成nacos服务注册模块阅读，希望对你有帮助。

我是 SharkChili ，Java 开发者，Java Guide 开源项目维护者。欢迎关注我的公众号：写代码的SharkChili，也欢迎您了解我的开源项目 mini-redis：https://github.com/shark-ctrl/mini-redis (opens new window)。

为方便与读者交流，现已创建读者群。关注上方公众号获取我的联系方式，添加时备注加群即可加入。

# 从自动装配入手

# 基于配置定位装配信息

一般来说我们服务进行注册时都会引入nacos服务发现的starter：

 <!-- nacos服务注册 -->
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
            <version>${revision}</version>
        </dependency>
1
2
3
4
5
6

通过引入这个依赖，服务启动时就会将自己的信息发送给nacos从而完成服务注册，结合spring boot自动装配的工作机制，我们不难猜出这个依赖的spring.factories文件肯定存在某个完成服务注册的bean。

于是我们查看spring-cloud-starter-alibaba-nacos-discovery的spring.factories文件就看到了NacosServiceRegistryAutoConfiguration这个带有服务自动注册的bean：

# NacosServiceRegistry注册器的装配

先来说说第一个装配的bean即nacosServiceRegistry，通过对整个类的结构和内部逻辑我们可知晓，它会基于我们如下的服务启动的配置参数完成初始化：

# 服务名称
spring.application.name=nacos-provider
# 服务注册地址
spring.cloud.nacos.discovery.server-addr=127.0.0.1:8848
1
2
3
4

在spring boot启动后并发布ServletWebServerInitializedEvent这个web初始化事件之后，spring cloud的AbstractAutoServiceRegistration就会调用register方法完成服务注册，此时该方法内部就会走到我们的NacosAutoServiceRegistration的register从而完成服务注册：

对此我们也给出NacosServiceRegistry 的初始化装配函数，可以看到它的入参就是和服务注册相关的属性配置和管理类：

@Bean
	public NacosServiceRegistry nacosServiceRegistry(
			NacosServiceManager nacosServiceManager,
			NacosDiscoveryProperties nacosDiscoveryProperties) {
		//基于服务管理类和服务注册属性配置完成初始化	
		return new NacosServiceRegistry(nacosServiceManager, nacosDiscoveryProperties);
	}
1
2
3
4
5
6
7

查看其实现的register方法也可以看出，本质上NacosServiceRegistry就是基于namingService获取注册中心地址，然后拿着服务的id（serviceId）、分组（group ）等信息通过通过注册中心实例的registerInstance发起RPC调用完成服务注册：

@Override
	public void register(Registration registration) {

	//......
		//解析出服务的id和服务使用的分组
		NamingService namingService = namingService();//获取name server
		String serviceId = registration.getServiceId();
		String group = nacosDiscoveryProperties.getGroup();
		//基于注册信息生成实例信息
		Instance instance = getNacosInstanceFromRegistration(registration);

		try {
			//向nacos发起服务注册
			namingService.registerInstance(serviceId, group, instance);
			//......
		}
		catch (Exception e) {
			//......
		}
	}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# NacosRegistration的装配

随后这个装配会执行NacosRegistration 的初始化，这个类我们着重了解nacosDiscoveryProperties 和 ApplicationContext 参数即可，所以我们大体可以推测出这个bean是基于spring上下文完成一些服务注册的元信息的维护：

/**
	 * 
	 * @param registrationCustomizers
	 * @param nacosDiscoveryProperties 服务发现属性配置
	 * @param context spring上下文
	 * @return
	 */
	@Bean
	@ConditionalOnBean(AutoServiceRegistrationProperties.class)
	public NacosRegistration nacosRegistration(
			ObjectProvider<List<NacosRegistrationCustomizer>> registrationCustomizers,
			NacosDiscoveryProperties nacosDiscoveryProperties,
			ApplicationContext context) {
		return new NacosRegistration(registrationCustomizers.getIfAvailable(),
				nacosDiscoveryProperties, context);
	}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

这一点我们可直接通过该装配bean的init方法查看其作用，可以看到这个类做了如下几件事：

  1. 通过nacosDiscoveryProperties拿到一些元信息配置存入metadata，这个bean默认情况下这些信息都是空，所以没有做什么很核心的事情
  2. 通过Spring context拿到环境变量配置

对应NacosRegistration的init源码如下，读者可参考注释了解：

@PostConstruct
	public void init() {

		Map<String, String> metadata = nacosDiscoveryProperties.getMetadata();
		//基于上下文拿到环境的配置
		Environment env = context.getEnvironment();
		//元信息存入 management.endpoints.web.base-path即actuator的基本路径
		String endpointBasePath = env.getProperty(MANAGEMENT_ENDPOINT_BASE_PATH);
		if (StringUtils.hasLength(endpointBasePath)) {
			metadata.put(MANAGEMENT_ENDPOINT_BASE_PATH, endpointBasePath);
		}
		//基于spring上下文拿到管理端口号
		Integer managementPort = ManagementServerPortUtils.getPort(context);
		//......
		//完成一些心跳、超时、ip过期删除等元信息的维护
		if (null != nacosDiscoveryProperties.getHeartBeatInterval()) {
			metadata.put(PreservedMetadataKeys.HEART_BEAT_INTERVAL,
					nacosDiscoveryProperties.getHeartBeatInterval().toString());
		}
		if (null != nacosDiscoveryProperties.getHeartBeatTimeout()) {
			metadata.put(PreservedMetadataKeys.HEART_BEAT_TIMEOUT,
					nacosDiscoveryProperties.getHeartBeatTimeout().toString());
		}
		if (null != nacosDiscoveryProperties.getIpDeleteTimeout()) {
			metadata.put(PreservedMetadataKeys.IP_DELETE_TIMEOUT,
					nacosDiscoveryProperties.getIpDeleteTimeout().toString());
		}
		//......
	}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

# 服务注册执行者NacosAutoServiceRegistration的装配

最后一个就是比较核心的bean了，也就是NacosAutoServiceRegistration，它从spring的容器中拿到上述两个bean作为成员变量存入，同时继承了AbstractAutoServiceRegistration完成register的调用。也就是说第一个bean是以成员变量的方式聚合在当前bean被调用从而完成服务注册的：

我们首先看看这个bean的初始化逻辑：

/**
	 * 用上述两个bean作为入参，即NacosAutoServiceRegistration是服务注册的核心bean
	 * @param registry
	 * @param autoServiceRegistrationProperties
	 * @param registration
	 * @return
	 */
	@Bean
	@ConditionalOnBean(AutoServiceRegistrationProperties.class)
	public NacosAutoServiceRegistration nacosAutoServiceRegistration(
			NacosServiceRegistry registry,
			AutoServiceRegistrationProperties autoServiceRegistrationProperties,
			NacosRegistration registration) {
			//基于上述初始化的NacosServiceRegistry 和NacosRegistration完成初始化
		return new NacosAutoServiceRegistration(registry,
				autoServiceRegistrationProperties, registration);
	}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

其内部在spring完成web容器初始化之后就会调用一个start方法，该方法内部就会调用register方法最终走到第一个bean的注册逻辑：

public void start() {
		//......

		
		if (!this.running.get()) {
			this.context.publishEvent(new InstancePreRegisteredEvent(this, getRegistration()));
			//发起服务注册
			register();
			//......
			this.context.publishEvent(new InstanceRegisteredEvent<>(this, getConfiguration()));
			this.running.compareAndSet(false, true);
		}

	}
1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 服务注册请求

# 构建服务请求入参

基于上述步骤该register最终就会走到自动装配的第一个bean即NacosServiceRegistry发起RPC服务注册请求，如下图所示，可以看到NacosServiceRegistry会拿着当前服务的id、组号以及实例信息通过NacosNamingService的registerInstance方法发起服务注册：

# 发起RPC调用

最终NacosNamingService的registerInstance的内部会通过服务初始化的RPC客户端即clientProxy向nacos发起服务注册请求：

@Override
    public void registerInstance(String serviceName, String groupName, Instance instance) throws NacosException {
        NamingUtils.checkInstanceIsLegal(instance);
        //基于初始化得到的RPC客户端发起服务注册请求
        clientProxy.registerService(serviceName, groupName, instance);
    }
1
2
3
4
5
6

顺着这个代理的调用最终就会走到NamingGrpcClientProxy的doRegisterService方法，其内部的requestToServer就是实质发起请求的方法，该方法内部会组装RPC请求头并基于服务名称等入参信息组装RPC 请求头向9848端口发起服务注册请求：

public void doRegisterService(String serviceName, String groupName, Instance instance) throws NacosException {
		//基于服务名称、组名、实例信息生成入参
        InstanceRequest request = new InstanceRequest(namespaceId, serviceName, groupName,
                NamingRemoteConstants.REGISTER_INSTANCE, instance);
         //调用requestToServer发起RPC调用       
        requestToServer(request, Response.class);
        redoService.instanceRegistered(serviceName, groupName);
    }


private <T extends Response> T requestToServer(AbstractNamingRequest request, Class<T> responseClass)
            throws NacosException {
        try {
        	//基于服务名称等入参信息组装RPC header
            request.putAllHeader(
                    getSecurityHeaders(request.getNamespace(), request.getGroupName(), request.getServiceName()));
             // 发起RPC调用与获得响应      
            Response response =
                    requestTimeout < 0 ? rpcClient.request(request) : rpcClient.request(request, requestTimeout);
           //......
        } catch (NacosException e) {
            //......
        }
       //......
    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

对此笔者也通过抓包工具tcp.dstport==9848 && tcp.srcport==50155捕获到这个请求：

将data数据序列化解析之后即可看到这个请求的数据，很明显就是我们上文源码调试得到的入参：

{
  "headers": {},
  "namespace": "public",
  "serviceName": "nacos-provider",
  "groupName": "DEFAULT_GROUP",
  "type": "registerInstance",
  "instance": {
    "ip": "192.168.x.x",
    "port": 8080,
    "weight": 1.0,
    "healthy": true,
    "enabled": true,
    "ephemeral": true,
    "clusterName": "DEFAULT",
    "metadata": {
      "IPv6": "[240e:466:640:4adc:e06d:bf83:ef55:c3f]",
      "preserved.register.source": "SPRING_CLOUD"
    },
    "ipDeleteTimeout": 30000,
    "instanceHeartBeatInterval": 5000,
    "instanceHeartBeatTimeOut": 15000
  },
  "module": "naming"
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

# 服务端解析客户端注册请求

# 请求处理器的初始化

为了能够处理不同的RPC请求，nacos根据不同的请求创建了不同的请求处理器RequestHandler，启动时，RequestHandlerRegistry在ContextRefreshedEvent即容器刷新完成后被调用并执行扩展点函数onApplicationEvent，获取所有的RequestHandler并缓存，便于后续收到请求后直接基于这个缓存获取处理器处理：


@Service
public class RequestHandlerRegistry implements ApplicationListener<ContextRefreshedEvent> {
 /**
     * 基于扩展点遍历所有的 RequestHandler 包括注册实例的方法包括 instanceRequestHandler
     * @param event
     */
    @Override
    public void onApplicationEvent(ContextRefreshedEvent event) {
    //获取所有的RequestHandler
        Map<String, RequestHandler> beansOfType = event.getApplicationContext().getBeansOfType(RequestHandler.class);
        Collection<RequestHandler> values = beansOfType.values();
        for (RequestHandler requestHandler : values) {
            
          	//......
            
            try {
            	//.......
            //将rpc对应的请求处理器直接丢到registryHandlers这个map中
            registryHandlers.putIfAbsent(tClass.getSimpleName(), requestHandler);
        }

	//......
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

# 注册服务注册监听回调

我们再来说说nacos服务端，nacos服务端在启动初始化时就会初始化一个BaseGrpcServer来监听RPC请求。 而BaseGrpcServer是继承自BaseRpcServer，所以在启动时也沿袭父类的start调用startServer执行RPC服务端启动：

对应的BaseGrpcServer的startServer源码如下：

@PostConstruct
    public void start() throws Exception {
        String serverName = getClass().getSimpleName();
        Loggers.REMOTE.info("Nacos {} Rpc server starting at port {}", serverName, getServicePort());
        //启动服务
        startServer();
        
        //......
        
    }
1
2
3
4
5
6
7
8
9
10
11

而startServer内部执行如下步骤：

  1. addServices启动rpc请求处理器并存入缓存中
  2. 完成rpcServer基础构建
  3. 启动rpcServer
@Override
    public void startServer() throws Exception {
        final MutableHandlerRegistry handlerRegistry = new MutableHandlerRegistry();
        //handlerRegistry 记录注册服务的容器
        addServices(handlerRegistry, getSeverInterceptors().toArray(new ServerInterceptor[0]));
        //rpc 为nacos端口加上1000
        NettyServerBuilder builder = NettyServerBuilder.forPort(getServicePort()).executor(getRpcExecutor());
        
       //......
       //构建rpcserver
        server = builder.maxInboundMessageSize(getMaxInboundMessageSize()).fallbackHandlerRegistry(handlerRegistry)
                .compressorRegistry(CompressorRegistry.getDefaultInstance())
                .decompressorRegistry(DecompressorRegistry.getDefaultInstance())
                .keepAliveTime(getKeepAliveTime(), TimeUnit.MILLISECONDS)
                .keepAliveTimeout(getKeepAliveTimeout(), TimeUnit.MILLISECONDS)
                .permitKeepAliveTime(getPermitKeepAliveTime(), TimeUnit.MILLISECONDS).build();
        //启动rpcserver
        server.start();
    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

我们着重查看addServices的调用，它会创建一个处理异步RPC调用的ServerCallHandler。当客户端发起一个请求时，grpcCommonRequestAcceptor.request方法会被调用，从而解析请求并处理返回响应:


private void addServices(MutableHandlerRegistry handlerRegistry, ServerInterceptor... serverInterceptor) {
        
     	//创建一个处理异步RPC调用的ServerCallHandler。当客户端发起一个请求时，grpcCommonRequestAcceptor.request方法会被调用
        final ServerCallHandler<Payload, Payload> payloadHandler = ServerCalls.asyncUnaryCall(
                (request, responseObserver) -> grpcCommonRequestAcceptor.request(request, responseObserver));
        
        final ServerServiceDefinition serviceDefOfUnaryPayload = ServerServiceDefinition
                .builder(GrpcServerConstants.REQUEST_SERVICE_NAME).addMethod(unaryPayloadMethod, payloadHandler)
                .build();
        //将处理器存入缓存中
        handlerRegistry.addService(ServerInterceptors.intercept(serviceDefOfUnaryPayload, serverInterceptor));
       //...... 
    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 以策略模式的姿态处理服务注册请求

基于上述的铺垫，当nacos收到客户端的RPC请求时，grpcCommonRequestAcceptor的request就会收到这个请求并获取其类型，处理器的获取就以策略模式的姿态从requestHandlerRegistry底层的缓存registryHandlers(也就是我们上文说明的缓存处理器的容器)中获取对应的requestHandler：

@Override
    public void request(Payload grpcRequest, StreamObserver<Payload> responseObserver) {
        
		//......
        //需要使用的服务器类型，例如服务注册就是 InstanceRequest
        String type = grpcRequest.getMetadata().getType();
        long startTime = System.nanoTime();
        
       //......
        //基于type以策略模式的姿态到找到对应的请求处理器
        RequestHandler requestHandler = requestHandlerRegistry.getByRequestType(type);
        //......
        
        Request request = (Request) parseObj;
        try {
           //......
            //解析参数并处理该请求
            Response response = requestHandler.handleRequest(request, requestMeta);
          //......
        } catch (Throwable e) {
        //......
        }
        
    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

上述的解析最终会走到InstanceRequestHandler即实例请求处理器，同样的基于报文的细节定位到这个是服务注册请求，便直接调用registerInstance进行处理：

对应我们给出InstanceRequestHandler的handle方法解析和处理的逻辑，和上文说明一致，读者可参考注释了解一下：

@Override
    @TpsControl(pointName = "RemoteNamingInstanceRegisterDeregister", name = "RemoteNamingInstanceRegisterDeregister")
    @Secured(action = ActionTypes.WRITE)
    @ExtractorManager.Extractor(rpcExtractor = InstanceRequestParamExtractor.class)
    public InstanceResponse handle(InstanceRequest request, RequestMeta meta) throws NacosException {
        //基于请求元信息生成服务实例
        Service service = Service
                .newService(request.getNamespace(), request.getGroupName(), request.getServiceName(), true);
       	//......
        switch (request.getType()) {
            case NamingRemoteConstants.REGISTER_INSTANCE: //执行服务端的服务注册
                return registerInstance(service, request, meta);
           	//......
        }
    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# 缓存并通知刷新

基于上一步的调用我们来到的registerInstance方法，其内部逻辑为：

  1. 将注册实例信息解析并缓存后
  2. 发布服务注册事件告知订阅者服务更新
@Override
    public void registerInstance(Service service, Instance instance, String clientId) throws NacosException {
        NamingUtils.checkInstanceIsLegal(instance);
        //获取单例的服务信息
        Service singleton = ServiceManager.getInstance().getSingleton(service);
       	//......
        InstancePublishInfo instanceInfo = getPublishInfo(instance);
        //将服务信息缓存到publishers这个map中
        client.addServiceInstance(singleton, instanceInfo);
        client.setLastUpdatedTime();
        client.recalculateRevision();
        //发布服务注册事件通知感兴趣的客户端服务上线
        NotifyCenter.publishEvent(new ClientOperationEvent.ClientRegisterServiceEvent(singleton, clientId));
        NotifyCenter
                .publishEvent(new MetadataEvent.InstanceMetadataEvent(singleton, instanceInfo.getMetadataId(), false));
    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# 小结

自此我们从服务装配、nacos服务端初始化以及客户端自动服务注册三个角度的源码完成的Nacos服务注册原理的全解析，希望对你有帮助。

我是 SharkChili ，Java 开发者，Java Guide 开源项目维护者。欢迎关注我的公众号：写代码的SharkChili，也欢迎您了解我的开源项目 mini-redis：https://github.com/shark-ctrl/mini-redis (opens new window)。

为方便与读者交流，现已创建读者群。关注上方公众号获取我的联系方式，添加时备注加群即可加入。

# 参考

Nacos源码1：Nacos服务注册基本原理:https://juejin.cn/post/7381373703081508904 (opens new window)

Nacos源码分析-服务注册 :https://juejin.cn/post/7436204791620141095?searchId=2025040313575664C1B70ED3CFA47E1287#heading-16 (opens new window)

编辑 (opens new window)
上次更新: 2026/03/26, 01:05:31
一步一步教你：用 Docker Compose 完成 Seata 的整合部署
Nacos服务订阅流程全解析

← Nacos服务订阅流程全解析→

最近更新
01
基于EasyExcel实现高效导出
03-25
02
从开源框架中学习那些实用的位运算技巧
03-25
03
浅谈分布式架构设计思想和常见优化手段
03-25
更多文章>
Theme by Vdoing | Copyright © 2025-2026 Evan Xu | MIT License | 桂ICP备2024034950号 | 桂公网安备45142202000030
×
×