Nacos服务注册简要流程

本文详细介绍了如何使用Nacos2.1.0-SNAPSHOT进行服务实例注册,包括示例代码、客户端执行流程和服务端执行流程。客户端通过NamingService注册服务实例到Nacos服务器,服务端接收到请求后由GrpcRequestAcceptor处理。文章还探讨了gRpc协议、服务注册的数据结构、存储位置以及相关事件的目的。

以下内容基于Nacos 2.1.0-SNAPSHOT

1. 服务实例注册示例

当nacos服务已经启动后,可以使用以下示例代码向nacos注册服务实例

@Test
public void testRegisterInstance() throw Exception {
    // nacos地址,用户和密码
    Properties properties = new Properties();
    properties.put(PropertyKeyConst.SERVER_ADDR, "127.0.0.1:8848");
    properties.put(PropertyKeyConst.USERNAME, "nacos");
    properties.put(PropertyKeyConst.PASSWORD, "nacos");
   
    // 构建服务实例
    Instance instance = new Instance();
    instance.setIp("1.1.1.1");
    instance.setPort(800);
    instance.setWeight(2);
    Map<String, String> map = new HashMap<>();
    map.put("netType", "external");
    map.put("version", "2.0");
    instance.setMetadata(map);
    
    // 创建NamingService
    NamingService namingService = NacosFactory.createNamingService(properties);
    // 通过NamingService注册服务实例,并指定服务名为 nacos.test.1
    namingService.registerInstance("nacos.test.1", instance);
}

2. 客户端执行流程

1. 相关的接口和类

  • NamingService定义了与服务实例相关的方法,我们可以通过NamingService完成服务实例的注册、注销、获取,目前只有一个实现类NacosNamingService。在NacosNamingService中持有一个NamingClientProxy的属性,并由NamingClientProxy来完成服务实例相关的操作。

  • NamingClientProxy封装了nacos客户端与服务端的交互细节。主要有两个实现类:

    • NamingHttpClientProxy采用gRpc协议与服务端进行交互

    • NamingGrpcClientProxy采用Http协议与服务端进行交互

    当需要服务实例Instance的属性ephemeral为true时,将使用NamingHttpClientProxy与服务端进行交互。

  • RpcClient抽象远程客户端,用以连接服务器,发起请求,接受响应。

2. 时序图

 

3. 服务端执行流程

1. 相关接口和类

  • GrpcRequestAcceptor类用于统一接受grpc请求,在request方法中,根据请求元数据中的type属性来判断由哪个RequestHandler来处理

  • RequestHandler抽象类用于Nacos请求处理,其中子类InstanceRequestHandler用于处理服务实例注册和注销请求

  • ClientOperationService接口提供客户端操作(实例注册,实例注销,订阅服务,取消订阅),有以下两个实现类:

    • PersistentClientOperationServiceImpl:对持久的客户端和服务提供操作

    • EphemeralClientOperationServiceImpl:对临时的客户端和服务提供操作

    在构建Instance时,可以通过ephemeral属性来指定为持久实例,还是临时实例,ephemeral默认为true

  • ClientManager用于管理Nacos naming Client

  • NotityCenter统一事件通知中心

2. 时序图

 

4. 待解惑

  1. gRpc协议是什么?

  2. 服务注册请求数据结构长什么样?

  3. 服务注册成功后,存储在哪里?

  4. 发布ClientOperationEvent.ClientRegisterServiceEvent事件和MetadataEvent.InstanceMetadataEvent事件的目的是什么

<think>好的,用户之前让我介绍了Spring Cloud的常用组件,现在他们想了解服务注册发现的流程。我需要先回顾一下之前提到的Eureka和Nacos,确保流程的准确性。 首先,用户可能是刚接触微服务架构,需要了解服务注册发现的基本概念和步骤。他们可能想知道服务是如何注册到中心的,以及如何被其他服务发现和调用。需要分解流程,分步骤解释,可能还要对比不同的组件,比如Eureka和Nacos的区别。 用户可能有实际项目需求,或者在学习准备面试,需要详细但清晰的解释。要注意使用简单的中文,避免技术术语过于复杂。同时,按照之前的格式,使用分点和代码示例,可能用LaTeX公式或代码块来展示交互过程。 需要确保每个步骤逻辑清晰,比如服务启动时的注册,心跳机制,服务消费者如何获取实例,以及下线处理。此外,补充一些注意事项,比如高可用性和健康检查,帮助用户理解实际应用中的关键点。 还要检查是否有遗漏的步骤,比如客户端缓存、负载均衡策略等,是否需要提及。不过根据问题,可能集中在注册发现的流程本身,不需要深入负载均衡细节。最后,确认是否要对比不同注册中心,但用户的问题可能更关注通用流程,所以可以简要提到替代方案,但以Eureka为例说明。</think>### 服务注册与发现流程详解 服务注册与发现是微服务架构的核心机制,用于动态管理服务实例的地址和状态。以 **Eureka** 为例,流程如下: --- #### **1. 服务注册(Service Registration)** - **触发时机**:服务(如订单服务、用户服务)启动时,向注册中心发送注册请求。 - **注册内容**:包含服务名(`spring.application.name`)、实例 ID、IP 地址、端口、健康状态等元数据。 - **示例请求**: ```bash POST /eureka/apps/ORDER-SERVICE { "instance": { "instanceId": "order-service-1:8080", "hostName": "192.168.1.10", "port": 8080, "status": "UP" } } ``` --- #### **2. 注册中心维护服务列表(Registry Maintenance)** - **存储结构**:注册中心(如 Eureka Server)以键值对形式存储服务名与实例列表的映射: $$ \text{Registry} = \{ \text{"ORDER-SERVICE": [Instance1, Instance2], "USER-SERVICE": [Instance3]} \} $$ - **心跳机制**: - 服务实例每隔 **30秒**(默认)向注册中心发送心跳(`PUT /eureka/apps/{serviceName}/{instanceId}`),证明自身存活。 - 若注册中心 **90秒** 未收到心跳,标记实例为 `DOWN`,并在后续清理周期(默认 60秒)移除该实例。 --- #### **3. 服务发现(Service Discovery)** - **消费者行为**: 1. 服务消费者(如支付服务)启动时,从注册中心拉取全量服务列表并缓存到本地。 2. 后续每隔 **30秒**(默认)增量更新服务列表,避免频繁请求注册中心。 - **动态获取实例**: 消费者通过服务名(如 `USER-SERVICE`)查询可用实例,结合负载均衡策略(如 Ribbon 的轮询、随机)选择目标实例。 ```java // Feign 声明式调用示例 @FeignClient(name = "USER-SERVICE") public interface UserServiceClient { @GetMapping("/users/{id}") User getUser(@PathVariable Long id); } ``` --- #### **4. 服务下线(Service Shutdown)** - **主动下线**:服务关闭前发送 `DELETE` 请求,通知注册中心移除自身实例。 - **被动下线**:注册中心检测到心跳超时后,自动将实例状态置为不可用,避免流量路由到故障节点。 --- #### **核心交互流程图** ```plaintext +-------------+ +-------------------+ +-----------------+ | 服务提供者 | | 注册中心 | | 服务消费者 | | (Provider) | | (Eureka/Nacos) | | (Consumer) | +-------------+ +-------------------+ +-----------------+ | | | | 1. 启动后注册服务 | | |------------------------->| | | | | | 2. 周期性发送心跳 | | |------------------------->| | | | | | | 3. 消费者拉取服务列表 | | |<-----------------------------| | | | | | 4. 消费者调用服务(负载均衡) | | |----------------------------->| | | | | 5. 关闭前主动下线 | | |------------------------->| | ``` --- ### **关键注意事项** 1. **高可用性**:注册中心需集群部署(如 Eureka Server 多节点互相注册),避免单点故障。 2. **健康检查**: - Eureka 依赖客户端心跳,Nacos 支持主动探测(如 TCP/HTTP 检查)。 3. **多级缓存**: - 消费者本地缓存服务列表,即使注册中心短暂不可用,仍能继续调用服务。 4. **最终一致性**: - 服务列表更新存在短暂延迟(通常 <1 分钟),需容忍临时的不一致。 --- ### **不同注册中心对比** | **组件** | **一致性模型** | **健康检查** | **附加功能** | |------------|----------------|-------------------|-------------------------| | Eureka | AP(高可用) | 客户端心跳 | 简单易用,Spring Cloud 原生集成 | | Nacos | AP/CP 可切换 | 心跳 + 主动探测 | 集成配置中心,支持动态 DNS | | Consul | CP(强一致) | 主动 HTTP/TCP 检查 | 多数据中心支持,ACL 权限控制 | --- ### **总结** 服务注册与发现通过 **注册中心** 实现微服务的动态管理,核心流程为: 1. 服务启动时注册元数据 2. 通过心跳维持实例健康状态 3. 消费者按需查询可用实例 4. 异常实例自动剔除 此机制解耦了服务提供者与消费者,支撑了微服务的弹性扩缩容和故障自愈能力。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值