服务注册与发现机制
候选人小张在面试阿里中间件团队时,面试官问:"你们的服务注册与发现是怎么实现的?Eureka 的心跳机制是什么?"
小张说:"就是服务启动时注册到 Eureka,然后定时发送心跳..." 面试官追问:"心跳续约的间隔是多少?多久不续约会被剔除?续约失败了会怎样?"
小张说:"好像是 30 秒?"面试官继续追问:"那注册表是客户端拉取还是服务端推送?拉取的间隔是多少?"
小张支支吾吾答不上来。
面试官又问:"Nacos 和 Eureka 在一致性协议上有什么区别?"
小赵彻底卡住。
【面试官心理】
这道题我用来测试候选人对服务发现底层机制的理解深度。知道"注册"和"心跳"概念的占 80%,能说出具体时间的占 50%,能解释注册表同步机制和 Nacos CP/AP 双模式差异的只有 20%。服务注册中心是微服务的基础设施,这些细节决定了生产环境的行为模式。
一、为什么需要服务注册发现 🔴
1.1 硬编码地址的问题
问题:
- 地址变更需要改代码:服务实例 IP 变了,所有调用方都要改
- 无法负载均衡:每次都调同一台机器
- 无法健康检查:不知道目标服务是否还活着
1.2 服务发现的核心流程
二、Eureka 服务注册与发现 🔴
2.1 服务注册流程
2.2 心跳续约机制
Eureka 的租约机制:客户端每 30 秒续约一次,Server 端 90 秒没收到续约就认为实例过期。但实际清理是后台线程扫描,过期实例不会立即被剔除,而是等到自我保护评估时一起处理。
2.3 注册表拉取机制
Eureka Client 端会缓存注册表到本地内存,即使注册中心挂了,Client 依然能使用本地缓存的实例列表继续发起调用。这保证了注册中心不可用时的容错能力,但也意味着短时间内可能调用到已下线的实例。
2.4 Eureka 架构图
三、Nacos 服务注册与发现 🔴
3.1 Nacos vs Eureka 的核心差异
3.2 Nacos 注册流程
3.3 Nacos 健康检查机制
3.4 Nacos Distro 协议
Distro 协议特点:
- 最终一致性:不保证强一致,但保证最终一致
- 分片负责:每个节点只负责部分服务的注册信息
- 异步同步:注册信息通过异步任务同步到其他节点
- 容错设计:单节点故障不影响其他服务
四、客户端负载均衡 🔴
4.1 服务发现 + 负载均衡的协作
4.2 健康检查与实例过滤
五、常见翻车现场 🔴
❌ 翻车点一:Eureka 自我保护导致服务已下线但仍可调用
生产环境常见问题:某个服务实例已异常退出,但由于 Eureka 进入了自我保护模式,该实例迟迟未被从注册表中剔除。调用方拿到的是已下线的实例地址,导致调用失败。
❌ 翻车点二:Nacos 和 Eureka 健康检查机制混用
有些项目在 Nacos 中配置了健康检查探针,但服务实例的 actuator 端点配置不完整,导致 Nacos 认为实例不健康但实际可用。
❌ 翻车点三:服务实例注册时序问题
服务启动时,如果注册中心不可用,服务可能会"裸奔"启动——即没有注册到注册中心,但已经开始接收请求。此时调用方获取不到该实例。
:::tip 💡 生产环境建议:
- 配置
spring.cloud.nacos.discovery.fail-fast=true,注册失败时快速失败 - 开启注册中心的健康检查,主动探测实例健康状态
- 服务启动时设置
spring.cloud.nacos.discovery.register-enabled=false,等待应用完全启动后再注册 :::
【面试官心理】
这道题我会从服务注册流程开始,逐步深入到心跳机制、注册表同步、负载均衡协作。能说出基本流程的占 60%,能解释 Eureka 和 Nacos 差异的占 40%,能说清楚 Distro 协议和生产避坑的只有 15%。服务注册中心是微服务架构的第一块基石,能把这些讲清楚的候选人,对分布式系统有较深的理解。