注册中心与服务发现

• Raft 用于服务数据一致性
• Gossip 用于成员发现与故障检测
• 健康检查类型（TCP/HTTP/Script/TTL）

Consul 采用双协议：Raft 协议用于服务注册数据的强一致性（CP），保证服务目录在集群节点间一致；Gossip 协议（Serf）用于节点成员发现、故障检测与集群信息传播，通过随机节点之间的心跳广播实现快速故障感知。健康检查支持多种类型：TCP 检查（探测 TCP 端口连通性）、HTTP 检查（请求 HTTP 端点判断返回码）、Script 检查（执行本地脚本判断）、TTL 检查（服务主动上报心跳，超时未上报即判定不健康）。检查结果影响服务的可用状态，服务不可用时从服务目录中标记为不健康，注册中心会将其摘除或标记。健康检查由 consul agent 在本地执行，结果汇总到服务目录。

Raft 保证服务数据一致，Gossip 保证故障快速检测，两者互补。健康检查是服务发现"剔除坏实例"的关键机制，TTL 检查适合主动心跳，TCP/HTTP 检查适合被动探测，应根据服务特性选择。

• Session 的生命周期
• Session 与 KV 的结合
• 基于 KV 的分布式锁

Consul 的 Session 是一个会话对象，绑定到节点，具有 TTL，客户端通过 heartbeat 续期。Session 可与 KV 结合实现分布式锁/选主：客户端创建一个 Session，然后通过 KV 的 acquire 操作在指定 key 上尝试获取锁——acquire 只在 key 无持有者或持有者会话已失效时成功；若 acquire 成功则获得锁，通过 Session 的 heartbeat 续期维持锁。若客户端崩溃，Session 到期，Consul 自动释放该 Session 关联的锁（key 的持有者被清除），其他客户端可通过 acquire 重新获取。释放锁用 release 操作，仅当前持有者能释放。该机制类似 etcd 的 lease+txn，实现崩溃自动让位的分布式锁与选主。

Session 提供"活性 + 自动失效"，KV 的 acquire/release 提供"原子抢占"，两者结合实现带自动释放的分布式锁。理解 Session 的 TTL 与心跳是掌握 Consul 锁可靠性的关键。

• Nacos 的推送机制
• Eureka 的增量拉取
• 延迟与一致性权衡

Nacos 2.x 采用 gRPC 长连接推送：服务端维护与客户端的连接，服务实例变化时主动推送更新，客户端缓存实时刷新，延迟低（毫秒级），一致性较好。Eureka 采用客户端轮询拉取：客户端定期（默认 30s）向服务端增量拉取注册表变化，本地缓存维护实例列表，延迟较高（秒级到分钟级），属最终一致。两者都维护客户端本地缓存：Nacos 的推送让缓存尽快更新，Eureka 的拉取让缓存周期更新。权衡的核心是"实时性 vs 服务端压力"：Nacos 推送实时性好但服务端需维护大量长连接与推送状态；Eureka 拉取简单、服务端压力小但延迟高。工程上应根据对"服务变更感知延迟"的要求选择，实时性要求高用 Nacos 推送，容错简单用 Eureka。

推送与拉取是"服务端主动 vs 客户端主动"的权衡。推送实时但复杂（连接管理、推送状态），拉取简单但延迟高。客户端缓存是两者共同的降级手段，保证注册中心不可用时仍能路由。

• 客户端负载均衡
• 注册中心缓存与实例列表
• 负载均衡策略

Spring Cloud LoadBalancer 是客户端负载均衡器：它从注册中心（Nacos/Eureka/Consul）获取服务的实例列表（通常来自注册中心缓存），在客户端本地按策略（轮询、随机、权重、最小连接等）选择一个实例发起请求。注册中心缓存协同：客户端从注册中心拉取实例列表并缓存到本地，负载均衡器基于缓存的列表选择实例，避免每次请求都查询注册中心。当实例异常时，负载均衡器通过重试、故障转移（切换到其他实例）与熔断实现容错。协同要点：负载均衡器依赖"缓存实例列表"进行选择，注册中心负责"实例发现与健康检查"，两者配合实现"发现 + 选择 + 容错"。实例权重、区域等元数据也用于负载均衡策略。

客户端负载均衡与注册中心缓存解耦了"发现"与"路由"：注册中心提供实例全量，负载均衡器在客户端做精细选择与容错。缓存提升了性能，但需通过健康检查与推送/拉取保持列表新鲜度。

• 优雅下线的三个阶段
• preStop/SIGTERM 钩子
• 注销时序与流量保护

服务优雅下线（K8s 场景）流程：K8s 下发 SIGTERM 信号，容器执行 preStop 钩子（可配置延迟等待），应用开始优雅停机。关键时序是"先摘除注册中心，再停止接收流量，最后释放资源"。具体：应用收到 SIGTERM 后，先主动向注册中心注销实例（或等待健康检查失败而摘除），使路由不再把新流量指向本实例；同时可通过 preStop 的 sleep 延迟等待负载均衡器与其他客户端感知下线；然后停止接受新请求（排空），等待在途请求完成，最后关闭连接池、线程池等资源。为避免摘除期间流量打到已下线实例，需保证：摘除注册优先于停止服务、预留摘除传播时间（推送/拉取延迟）、在途请求优雅排空。Nacos 推送/Consul/Eureka 摘除与 K8s 的 preStop 配合实现平滑下线。

优雅下线的核心是"先摘除再停服"的顺序与时序控制。摘除延迟（推送/拉取耗时）需通过 preStop 延迟或外部健康检查兜底，保证下线窗口内没有流量打到即将停止的实例。

• 本地快照（缓存文件）
• 服务端不可用的降级
• 缓存实例列表的使用

注册中心客户端（Nacos/Eureka/Consul）都会在本地保存一份服务实例列表的快照（Nacos 的 snapshot、Eureka 的缓存、Consul 的缓存）。客户端启动时从注册中心拉取实例列表并缓存到本地，同时将快照持久化到磁盘。当注册中心服务端不可用时，客户端回退到本地缓存/快照中的实例列表进行路由，保证服务调用不中断。降级策略的取舍：本地快照可能过期（实例已下线但仍在缓存中），导致调用失败，但能保证可用性（不会因注册中心故障而全崩）。注册中心恢复后，客户端重新同步最新的实例列表。实践上，应结合健康检查与熔断，对"快照中的失效实例"做调用失败重试与淘汰，并监控"注册中心连接状态"与"快照新鲜度"。

本地快照是服务发现"故障隔离"的关键，把注册中心的故障与业务调用解耦。它牺牲了"实例列表的新鲜度"换取"可用性"，配合健康检查与重试可减少对失效实例的无效调用。

• 续约与续约阈值
• 自我保护机制
• 驱逐暂停

Eureka 中，实例通过续约（renewal）向服务端上报心跳，服务端统计最近一小时的续约次数，计算期望续约阈值（renewalThreshold = 续约次数 * 自我保护系数）。当实际续约次数低于阈值的一定比例（默认 85%）时，Eureka 触发自我保护：不再驱逐（移除）过期实例，认为"可能是网络分区导致服务端与实例失联，而非实例真正下线"。自我保护期间，本应过期的实例不会被摘除，避免网络抖动导致大量实例被误删。renewalThreshold 会随实例数量与续约频率动态更新。自我保护是 Eureka 的 AP 取舍：宁可保留可能失效的实例、保证可用性，也不因为网络抖动误删实例、破坏一致性。

自我保护是 Eureka 应对"网络分区误删实例"的策略，通过"触发后暂停驱逐"保证可用性。renewalThreshold 是触发判定的依据，其动态更新保证判定与实例规模匹配。这体现了 Eureka 的 AP 优先设计。

• 自我保护机制
• AP 取舍
• 工程影响（误删/误留）

Eureka 的自我保护是 AP 取舍的体现：在发生网络分区时优先保证可用性（服务发现可用），而非一致性（实例列表准确）。自我保护触发后，Eureka 暂停驱逐过期实例，可能导致"不健康实例长时间保留在注册表"，调用方把流量打到已下线实例；反之，若关闭自我保护，则网络抖动时可能误删大量健康实例，导致服务发现不完整。工程影响：一是对"实例下线及时性"与"实例列表准确性"的两难；二是"误留"导致调用失败风险、"误删"导致路由缺失风险。应对策略：合理配置自我保护开关与阈值（生产通常保留自我保护但调优参数）、依赖客户端健康检查与熔断兜底（对失效实例快速失败）、结合监控判断是否误触发、采用 Nacos 等推送式注册中心降低感知延迟。

AP 取舍没有完美答案，自我保护是"宁留勿删"的默认选择。工程上要通过"客户端容错 + 监控 + 阈值调优"缓解自我保护带来的副作用，平衡可用性与准确性。

• 临时实例（AP）
• 持久实例（CP）
• 健康检查机制

Nacos 服务注册区分临时实例（ephemeral）与持久实例（persistent）。临时实例采用 AP 模式（Distro 协议）：注册数据在节点间最终一致，实例通过主动心跳（客户端上报）维持存活，心跳超时（默认 15s）判定实例不健康，超过删除超时（默认 30s）后移除实例，适合注册中心可用性优先、允许短暂不一致的场景。持久实例采用 CP 模式（Raft 协议）：注册数据强一致，实例不依赖心跳，服务端通过主动健康检查（TCP/HTTP 探测）判断存活，适合需要强一致、实例存活需服务端确认的场景。临时实例由客户端心跳驱动，持久实例由服务端探测驱动。健康检查机制上，临时实例用客户端心跳，持久实例用服务端主动探测。

临时/持久实例的差异本质是"一致性模型 + 健康检查方式"的差异：临时实例 AP+心跳，持久实例 CP+探测。选型取决于对可用性、一致性与注册方式的要求，临时实例更常见于微服务。

• Distro 协议
• 分区下接受写入
• 数据收敛与最终一致

Nacos 的 Distro 协议是 AP 模式的数据同步协议：每个 Nacos 节点负责一部分服务数据的写入，节点间通过异步同步（Distro sync）将数据分发到其他节点，实现最终一致。在网络分区下，Distro 协议仍允许各分区内的节点接受临时实例的注册写入（保证可用性），各分区各自维护已注册的实例数据，分区恢复后通过异步同步收敛数据。因此分区期间，不同分区看到的实例列表可能存在短暂差异（最终一致），但服务注册始终可用。这种设计牺牲了强一致性换取可用性，适合临时实例的场景。风险是分区恢复前可能有不一致的服务视图，需配合客户端容错。

Distro 的"分区内可用 + 分区间异步收敛"是典型的 AP 设计，与 Raft 的"分区时多数派可用"不同。理解"短暂差异可容忍、最终一致"是掌握 Nacos 临时实例行为的关键。

• 注册中心脑裂
• 同机房优先路由
• 跨机房容灾

注册中心脑裂（多机房场景）指集群在网络分区后分裂成多个无法通信的部分，各自独立提供服务。CP 型注册中心（Consul/ZK 的 Raft）通过多数派防止脑裂（少数派可能不可用）；AP 型（Nacos Distro/Eureka）允许分区各自可用、最终一致。多机房注册策略设计：一是同机房优先（同 region/zone 优先），通过实例元数据（区域、机房标签）在负载均衡时优先选择同机房的实例，降低跨机房延迟；二是跨机房容灾，当本地机房实例不可用时降级到其他机房实例，保证可用性。设计上：注册中心多机房部署（主备或每机房独立实例）、实例带区域元数据、路由支持按区域过滤与故障转移、跨机房数据同步与容灾。核心是"优先本地、故障跨区"。

脑裂防护取决于一致性模型（CP 多数派 vs AP 最终一致），多机房设计要在"同机房优先"与"跨机房容灾"间平衡。实例的机房元数据与区域感知路由是支撑多机房策略的关键。

• 本地缓存
• 快照持久化
• 注册中心故障降级

服务发现的容错设计：客户端在本地缓存服务实例列表（内存），并持久化快照到磁盘。正常时从注册中心拉取/推送更新缓存；注册中心故障时，客户端回退到本地缓存/快照的实例列表继续路由，保证服务调用不中断。容错还包括：对缓存中失效实例的调用失败重试与故障转移、负载均衡层面的熔断（对连续失败实例隔离）、以及注册中心恢复后的自动同步。降级策略的取舍：本地快照可能过期，但保证可用性；配合健康检查与重试可减少无效调用。工程上应监控"注册中心连接状态"与"快照新鲜度"，并平衡"缓存命中率"与"实例列表准确性"。

缓存+快照是服务发现容错的基石，把注册中心故障从"致命"降为"降级"。完整容错是"缓存保底 + 重试转移 + 熔断隔离"的组合，保证注册中心故障时业务仍可调用。

• Eureka 的 AP 表现
• Nacos 的 AP/CP 双模式
• Consul 的 CP 表现

分区故障下三者表现不同：Consul 是 CP 系统（Raft），分区时少数派无法形成 Quorum，无法提供写服务，可能不可用，但保证数据一致；Eureka 是 AP 系统，分区时各分区仍可提供服务，服务发现始终可用，但实例列表可能不一致（最终一致）；Nacos 支持模式切换，临时实例用 AP（Distro，分区可用、最终一致），持久实例用 CP（Raft，分区时可能不可用但一致）。对调用方的影响：Consul 分区时可能无法注册/发现新服务（可用性受损），但既有数据一致；Eureka/Nacos(AP) 分区时始终可用，但可能看到不一致的实例列表（可能路由到已下线实例）；Nacos(CP) 与 Consul 类似。调用方应根据注册中心的一致性模型设计容错（重试、缓存、熔断）。

分区表现的本质是 CAP 取舍：CP（Consul、Nacos 持久）牺牲可用性保一致性，AP（Eureka、Nacos 临时）牺牲一致性保可用性。调用方需根据注册中心模型准备相应的容错策略。

• 服务元数据
• 灰度路由（版本）
• 同机房优先（区域）

服务元数据是注册中心中服务实例附带的键值信息（如版本号、区域/机房、权重、标签），可用于精细路由。灰度路由：通过实例的版本元数据，负载均衡时按版本筛选，实现"新版本灰度、旧版本回退"（如 Nacos 的权重路由、版本匹配）。同机房优先：通过区域/机房元数据，优先选择同区域实例，降低跨机房延迟，区域不可用时跨机房容灾。权重路由：通过权重元数据，按权重比例分配流量，实现流量比例控制（如金丝雀发布）。实现上，注册中心保存实例元数据，负载均衡器基于元数据做筛选与排序（如按版本过滤、按区域优先、按权重随机）。元数据治理要求统一命名规范，保证路由策略稳定。

服务元数据是把"服务注册"升级为"精细路由"的开关。版本、区域、权重三类元数据分别支撑灰度、同机房优先与流量控制，是微服务治理（灰度发布、流量调度）的基础。

• gRPC 长连接
• 配置延迟降低
• 连接数优化

Nacos 2.x 用 gRPC 长连接替代了 1.x 的 HTTP 定时拉取/推送。客户端与服务端建立 gRPC 长连接，服务端通过长连接主动推送配置与服务变更，客户端也通过长连接上报心跳。影响：配置延迟大幅降低——HTTP 方案是定时轮询（秒级到分钟级延迟），gRPC 长连接是即时推送（毫秒级），配置变更的感知更实时；连接数优化——gRPC 长连接避免了 HTTP 的频繁建连，复用连接减少握手开销，同时支持多路复用与流式，服务端连接数更可控。但长连接需要维护连接状态与心跳保活，服务端需支撑大量长连接。总体而言，gRPC 长连接提升了配置推送的实时性与连接效率。

gRPC 长连接的核心价值是"推送实时性 + 连接复用"。相比 HTTP 轮询，它把配置延迟从秒级降到毫秒级，并减少连接建立开销，是 Nacos 2.x 性能提升的关键。

• Eureka 2.x 停止维护
• 迁移路径（Nacos/Consul）
• 兼容性评估

Eureka 2.x 已停止维护，存量系统需评估迁移路径。可选迁移目标：Nacos（Spring Cloud Alibaba 生态，注册+配置一体，支持 AP/CP，迁移成本低，与 Spring Cloud 集成好）、Consul（CP 强一致，功能完善，适合需要强一致的场景）。兼容性评估：迁移涉及客户端集成（@EnableDiscoveryClient 的注册中心实现）、注册数据模型（实例的 lease/心跳 vs Nacos 临时实例 vs Consul 服务）、配置中心整合（若同时使用配置）、以及监控与运维体系。迁移方案：先构建目标注册中心集群，双注册（同时注册到新旧）过渡，灰度切换服务实例，最后下线旧注册中心。评估重点：客户端兼容性、数据一致性模型差异、运维成本与团队技能。

迁移是渐进式而非一刀切。核心是兼容性评估（客户端、数据模型、生态）与灰度切换（双注册过渡）。Nacos 因与 Spring Cloud Alibaba 生态契合、迁移成本低，是多数 Java 微服务的首选。

• AP/CP 模式切换
• 临时实例（AP）
• 持久实例（CP）

Nacos 的一致性模式由实例类型决定：临时实例（ephemeral）使用 AP 模式（Distro 协议），保证可用性优先、数据最终一致，实例通过客户端心跳维持，适合微服务注册场景；持久实例（persistent）使用 CP 模式（Raft 协议），保证强一致，实例通过服务端主动探测维持，适合需要强一致性的数据。AP/CP 的"切换"体现在服务级别：用户在注册服务时指定实例类型（ephemeral 或 persistent），Nacos 据此选择对应的协议与一致性模型。不同的一致性模型对应不同的健康检查与故障行为：AP 临时实例分区时可用、心跳超时移除；CP 持久实例分区时可能不可用、依赖服务端探测。两者不可同时用于同一服务，需按场景选择。

Nacos 的 AP/CP 是"按实例类型选择协议"而非全局切换。临时实例 AP 保证可用性，持久实例 CP 保证一致性，理解这个对应关系是正确使用 Nacos 注册的关键。

• 推送机制（实时性）
• 轮询机制（周期性）
• 延迟对比

服务上下线感知的两种方式：推送（Nacos 2.x gRPC、Consul 的 watch）——服务端在实例变化时主动推送给客户端，感知延迟低（毫秒级），客户端缓存实时更新；轮询（Eureka 定时拉取、Nacos 1.x HTTP）——客户端周期性拉取注册表，感知延迟取决于轮询周期（Eureka 默认 30s，秒级到分钟级），一致性最终。延迟对比：推送实时性远优于轮询，轮询的延迟取决于周期。场景选择：对服务上下线感知要求高（如快速容灾、频繁发布）用推送式注册中心（Nacos/Consul）；对延迟不敏感、追求简单与低服务端压力用轮询式（Eureka）。工程上推送式注册中心能快速感知实例下线，减少调用失败，但需维护长连接；轮询式实现简单但上下线延迟高。

推送 vs 轮询是"实时性 vs 简单性"的权衡。推送让客户端快速感知上下线、减少失败调用，轮询延迟高但实现与运维简单。选择取决于对感知延迟与运维成本的权衡。