注册中心因系统地位特殊而同时需要高可用与高可靠

服务发现要完成三件必需的事：服务注册（启动时把坐标通知注册中心，可以 是应用自注册，也可以是Kubernetes等第三方代为注册）、服务维护（持续做 健康检查，把宕机/断网导致的失联服务从注册表中剔除，因为没人能保证服务 每次都优雅下线）、服务发现（消费者把符号转换成真实坐标）。这三件事本身 不复杂，复杂的是注册中心在系统中的特殊地位：概念模型里它和服务提供者、 消费者是平等的一员，但现实中它”不依赖其他服务，却被所有其他服务共同 依赖”，是最基础的服务，几乎无法在业务层面容错——一旦注册中心崩溃， 整个系统都不可用，这逼着它必须尽最大努力保证可用性。但用户同时还期望 访问注册中心任意节点都能拿到可靠一致的数据，而不是被告知的服务地址其实 早已下线——这个”永远可用”和”数据永远准确”的双重期望，正是CAP矛盾在 服务发现这个具体场景里的体现，而且这里两个需求都无法轻易舍弃：舍弃可用 性等于让整个系统停摆，舍弃一致性等于消费者可能拿到失效地址、增加故障 处理复杂度。这解释了为什么生产环境的注册中心普遍要以三、五（最多七） 节点集群部署——节点数不是越多越好，日志复制开销会随节点数增长。