微服务服务发现

引言

在分布式微服务架构中，服务实例的 IP 和端口通常是动态变化的（例如因为弹性扩缩容、滚动更新或机器故障）。服务发现（Service Discovery）机制使得各个服务实例能够自动注册自身信息，并动态感知其他服务的存在，从而消除了硬编码配置的弊端。

注册中心的核心工作流

1. 服务注册 (Service Registration)

当一个服务实例启动时，它会将自己的服务名称、IP 地址、端口号以及健康检查 URL 发送给注册中心。

2. 心跳与健康检查 (Heartbeat)

为了防止将流量分发到已挂掉的实例，注册中心会要求服务实例定期发送心跳（或主动去探测实例）。如果在规定时间内未收到心跳，注册中心会将其从可用实例列表中移除。

3. 服务发现 (Service Discovery)

当服务 A 需要调用服务 B 时，它会向注册中心查询服务 B 的可用实例列表。

• 客户端服务发现：服务 A 本地缓存实例列表，并自己在客户端通过轮询、随机等算法实现负载均衡（如 Nacos、Eureka）。
• 服务端服务发现：服务 A 统一调用一个中间代理（如 Nginx、网关），由代理去注册中心查询并完成分发。

核心产品对比与 CAP 抉择

注册中心	开发语言	CAP 理论	健康检查方式
Eureka	Java	AP	客户端心跳机制
Consul	Go	CP	主动探测 (HTTP/TCP/gRPC)
Nacos	Java	AP / CP 可切	客户端心跳 + 服务端探测

AP 与 CP 的权衡

• AP 模式（可用性优先）：在网络分区（Network Partition）发生时，注册中心即便无法同步最新数据，依然允许读取本地旧数据，宁可提供过时的服务列表，也不直接报错拒绝服务。这符合大多数业务微服务发现的诉求（Eureka/Nacos 默认）。
• CP 模式（一致性优先）：在网络分区时，为了保证全局数据绝对一致，会拒绝部分写入和读取请求，直到集群达成共识。这适用于对数据准确性要求极高的场景（Consul/ZooKeeper）。