服务发现与注册可靠性：注册中心
服务发现与注册，说白了就是微服务架构的“通讯录”。
没有它，服务之间就像蒙着眼找人。我见过不少团队，服务拆分做得漂亮，结果栽在注册中心上。服务挂了，调用方还在傻傻地发请求，整个系统瞬间雪崩。
今天咱们聊聊注册中心的几个主流选手：Eureka、Consul、Nacos。以及围绕它们的健康检查、服务摘除、自我保护机制。这些都是实战中绕不开的坎。
一、注册中心的核心职责
注册中心要干三件事：
- 服务注册：服务启动时，把自己的IP和端口告诉注册中心。
- 服务发现：调用方从注册中心拿到目标服务的地址列表。
- 健康检查：定期确认服务是否还活着。死了就摘掉。
听起来简单，但高并发下，任何一个环节出问题，都是灾难。
二、三大主流注册中心对比
| 特性 | Eureka | Consul | Nacos |
|---|---|---|---|
| CAP模型 | AP（可用性+分区容忍） | CP（一致性+分区容忍） | AP/CP可切换 |
| 健康检查 | 客户端心跳 | 服务端主动探测 | 心跳+主动探测 |
| 自我保护 | 内置，防止网络抖动误摘 | 无 | 内置，可配置 |
| 一致性协议 | 最终一致性 | Raft | Raft（CP模式） |
| 管理界面 | 简单 | 丰富 | 丰富 |
我个人习惯：如果团队对一致性要求不高，选Eureka或Nacos的AP模式。如果对数据强一致有要求，比如配置中心场景，Consul或Nacos的CP模式更合适。
三、健康检查：别让“僵尸服务”活着
健康检查是注册中心的命脉。服务挂了，注册中心必须知道。
Eureka 用的是客户端心跳。服务每隔30秒发一次“我还活着”。如果连续3次没收到，Eureka会等90秒才摘除。为什么等这么久？
嗯，这里要注意。Eureka的设计哲学是“宁可保留坏的服务，也不误杀好的”。这在网络抖动时特别有用。我曾经在双11大促时，网络短暂波动，Eureka的自我保护机制救了我们一命。
Consul 则是服务端主动探测。它定期去请求服务的健康端点。这种方式更准确，但会增加网络开销。
Nacos 两者都支持。我建议用心跳+主动探测的组合。心跳保活，探测兜底。
核心原则：健康检查的间隔和超时，要根据业务场景调整。太频繁浪费资源，太稀疏延迟发现故障。
四、服务摘除：优雅下线，别搞“突然死亡”
服务摘除分两种：主动摘除和被动摘除。
- 主动摘除：服务关闭前，主动通知注册中心“我要走了”。比如Spring Cloud的@PreDestroy注解里调用Eureka的shutdown()。
- 被动摘除：健康检查失败，注册中心强制摘除。
我曾经踩过一个坑：服务直接kill -9，没来得及主动摘除。结果调用方还在疯狂重试，导致请求堆积。后来我们加了优雅关闭的钩子，确保服务下线前，先摘除注册信息，再处理完存量请求。
避坑指南：服务摘除后，调用方的本地缓存可能还有旧地址。建议调用方开启定时刷新，比如每30秒拉一次最新列表。
五、自我保护机制：关键时刻的“保命符”
自我保护机制，说白了就是“宁可错留，不可错杀”。
Eureka的自我保护机制很经典。当它发现心跳失败的比例超过阈值（默认85%），就会进入自我保护模式。此时它不再摘除任何服务实例。
为什么？因为网络分区时，可能是注册中心自己出了问题，而不是服务挂了。如果贸然摘除，反而会造成大面积误杀。
Nacos也有类似机制。我建议生产环境开启自我保护，但阈值要根据实际网络状况调整。我见过一个团队把阈值设成99%，结果网络一抖，所有服务都被摘了，那叫一个惨。
个人经验：自我保护机制不是银弹。如果服务真的挂了，自我保护反而会延迟故障发现。建议配合外部监控（比如Prometheus）一起使用。
六、核心逻辑流程图
下面这张图，展示了服务注册、健康检查、服务摘除、自我保护的整体流程。你想想看，每个环节都环环相扣。
七、实战建议
- 选型要匹配业务：如果服务数量少、网络稳定，Consul的强一致性很香。如果服务多、网络复杂，Eureka或Nacos的AP模式更靠谱。
- 健康检查要分层：除了注册中心的心跳，业务层也要有健康端点。比如检查数据库连接池、缓存是否正常。
- 自我保护阈值别乱调：默认85%是经过验证的。调太高容易误杀，调太低失去保护意义。
- 优雅下线必须做：用PreDestroy钩子，或者K8s的preStop hook。别让服务“暴毙”。
一句话总结：注册中心是微服务的“心脏”。健康检查是“脉搏”，服务摘除是“手术”，自我保护是“ICU”。每个环节都要精心设计。
好了，今天就聊到这儿。记住，没有完美的注册中心，只有最适合你业务的方案。