服务注册与发现：Consul、Nacos 与 Eureka

什么是服务注册与发现？

在微服务架构中，服务实例的网络位置是动态变化的（例如扩缩容、故障转移），服务消费者无法通过硬编码地址来调用服务。服务注册与发现正是解决这一问题的核心机制——它让服务能够自动注册自己的位置，并让调用方动态发现可用的服务实例。

简单来说，就是两个核心动作：

• 注册：服务启动时，将自己的元数据（IP、端口、健康状态等）上报到注册中心。
• 发现：调用方从注册中心获取目标服务的可用实例列表，实现负载均衡调用。

没有服务注册与发现，微服务之间的通信会退化为混乱的配置文件维护和脆弱的手动管理。

主流实现方案对比：Consul、Nacos 与 Eureka

目前业界常用的开源注册中心主要有三个：HashiCorp 的 Consul、阿里巴巴的 Nacos 以及 Netflix 的 Eureka。它们都实现了基本的服务注册与发现功能，但在架构、一致性和功能扩展上各有侧重。

基础架构与组件

• Eureka：采用 CS 架构，包含 Eureka Server（注册中心）和 Eureka Client（服务提供者/消费者）。Eureka Server 之间通过异步复制同步数据，没有主节点概念，所有节点平等。
• Consul：采用 Agent 模式，每个节点运行一个 Consul Agent，分为 Server 和 Client 两种模式。Server 节点通过 Raft 协议选举领导者，负责数据强一致性；Client 节点转发请求到 Server。
• Nacos：同样有 Server 和 Client 概念，但服务端支持 CP 和 AP 两种模式切换（通过 nacos.core.protocol.raft.data=... 配置），并且内嵌了配置管理功能。

健康检查机制

• Eureka：依赖客户端心跳（Renew）来判断服务是否存活。如果一段时间收不到心跳，Eureka 会进入自我保护模式，不再剔除任何实例（宁可保留错误信息也不丢失有效实例），这保障了 AP（可用性）但牺牲了强一致性。
• Consul：提供丰富的健康检查方式：HTTP/TCP 检查、脚本检查、甚至 gRPC 检查。服务端也会发起主动检测，失败后直接标记不可用，并可以通过 DNS 或 HTTP 接口屏蔽异常节点。
• Nacos：客户端上报心跳，同时支持服务端主动探测（TCP/HTTP/Mysql）。Nacos 可以自定义健康检查逻辑，临时实例使用心跳保活（AP），永久实例则由服务端探测（CP）。

数据一致性与 CAP 取舍

这是三者在架构设计上最本质的区别：

• Eureka：优先保证 AP（可用性和分区容错性）。网络分区时，即使节点间数据不一致，也保留所有服务信息，保证服务调用的可用性。这适合内部大规模、对一致性要求略低的场景。
• Consul：默认强一致性（CP）。使用 Raft 协议，所有写操作必须经过 Leader，网络分区时优先保证数据一致，可能牺牲部分可用性（非 Leader 节点不提供服务发现）。健康检查也参与一致性决策。
• Nacos：灵活切换 CP 或 AP。默认对临时实例采用 AP 模式（类似 Eureka），对永久实例采用 CP 模式。这为不同业务特征提供了更多选择。

功能维度扩展

如何选择适合你的注册中心？

以下是一些决策依据，帮助你在不同场景下做出选择：

选择 Eureka 的场景

• 团队主要使用 Spring Cloud 技术栈，且项目已经稳定运行多年。
• 对服务一致性要求不高，允许短暂的不一致（例如内部管理后台）。
• 无需配置中心，或已使用 Spring Cloud Config。
• 希望运维简单、学习成本低。Eureka 虽然停止新功能开发，但在 Netflix 大规模实践中已验证其高可用性。

选择 Consul 的场景

• 需要强一致性保证，例如金融交易、核心业务流程。
• 希望一套组件同时搞定服务发现与健康检查（多协议探测）。
• 多数据中心天然联通需求，或正在向服务网格（Consul Connect）演进。
• 对多语言微服务生态有要求（Consul 提供 DNS 发现方式，不限于特定 SDK）。

选择 Nacos 的场景

• 既要服务发现又需要动态配置中心，希望降低组件耦合。
• 业务需要灵活的流量控制，如灰度发布、权重路由。
• 微服务体系包含临时实例（例如弹性扩缩容）和永久实例（例如数据库），需要不同一致性策略。
• 项目主要基于 Spring Cloud Alibaba 或 Dubbo，Nacos 提供深度集成。

快速上手：Nacos 单机部署与 Spring Boot 集成

为了让你直观感受服务注册与发现，这里以 Nacos 为例（因为它功能全面且符合国内习惯），给出一个 15 分钟可完成的演示。

环境准备

• JDK 1.8+
• Maven 3.2+
• 一个干净的 Spring Boot 项目

第一步：启动 Nacos Server

从 Nacos GitHub Release 下载最新稳定版（例如 nacos-server-2.2.3.zip）。

解压后，进入 bin 目录：

# Linux/Mac
sh startup.sh -m standalone
# Windows
startup.cmd -m standalone

Standalone 模式用于开发测试。启动后访问 http://127.0.0.1:8848/nacos，默认账号密码都是 nacos。

第二步：创建服务提供者

在 Spring Boot 项目的 pom.xml 中添加依赖：

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    <version>2021.0.5.0</version>
</dependency>

编写启动类并添加 @EnableDiscoveryClient：

@SpringBootApplication
@EnableDiscoveryClient
public class ProviderApplication {
    public static void main(String[] args) {
        SpringApplication.run(ProviderApplication.class, args);
    }
}

在 application.yml 中配置 Nacos 地址和服务名：

server:
  port: 8081
spring:
  application:
    name: demo-provider
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848

编写一个简单的 REST 接口：

@RestController
public class HelloController {
    @GetMapping("/hello")
    public String hello() {
        return "Hello from provider!";
    }
}

启动项目，访问 Nacos 控制台的“服务管理”->“服务列表”，你会看到 demo-provider 已注册成功。

第三步：创建服务消费者

同理创建另一个项目，pom.xml 添加相同 Nacos 依赖，配置应用名 demo-consumer，同样添加 @EnableDiscoveryClient。

消费者需要调用提供者的接口，可以使用 Spring Cloud LoadBalancer 或 OpenFeign。这里用 OpenFeign 简化：

添加依赖：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>

启动类加上 @EnableFeignClients：

@SpringBootApplication
@EnableDiscoveryClient
@EnableFeignClients
public class ConsumerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConsumerApplication.class, args);
    }
}

编写 Feign 接口：

@FeignClient(name = "demo-provider")
public interface ProviderClient {
    @GetMapping("/hello")
    String hello();
}

在消费者的 Controller 中使用它：

@RestController
public class ConsumerController {
    @Autowired
    private ProviderClient providerClient;

    @GetMapping("/call")
    public String call() {
        return providerClient.hello();
    }
}

访问http://localhost:8082/call，你会看到成功返回 Hello from provider!。这就是一个最简单的服务发现调用链路。

你还可以多启动一个提供者实例（修改端口为 8083），再次调用 /call，观察 Nacos 的负载均衡效果。

常见问题与陷阱

• 自我保护模式误判：Eureka 开启自我保护后可能不剔除已宕机的实例，调用方需要启用重试或断路器。
• Nacos 1.x 的 CAP 模式：默认 AP，如果要 CP 需要配置命名空间且实例为永久实例，否则还是心跳模式。
• Consul 的心跳与健康检查重叠：如果同时使用 agent 的 TTL 检查和 HTTP 检查，可能因为 Leader 切换导致短暂不可用，需要合理设置检查间隔。
• 多注册中心共存：避免在同一个微服务中引入多个注册中心客户端，可能导致元数据冲突。

结语：回归本质

服务注册与发现是微服务治理的基石。无论选择哪一款工具，都要理解它们在 CAP 理论中的位置，以及健康检查、配置管理等功能对你的系统的影响。工具无优劣，合适才最好。希望这篇教程能帮助你在技术选型时，做出更自信的决策。