什么是 Eureka？
- 标签：Spring Cloud、微服务、注册中心、后端
🏛 业务架构师
Eureka 是 Netflix 开源的服务注册中心，Spring Cloud Netflix 套件的核心组件：服务提供者启动时向 Eureka Server 注册（服务名 + IP + 端口 + 元数据），消费者按服务名拉取实例列表发起调用，配合 Ribbon/Feign 完成负载均衡。
核心机制：
- 心跳续约：客户端每 30 秒发心跳，90 秒没收到就剔除实例——故障实例自动摘除；
- 服务拉取：客户端每 30 秒增量拉取注册表，本地缓存——调用不走注册中心（去中心化调用路径），注册中心挂了短时间不影响存量调用；
- 自我保护机制（设计精髓）：15 分钟内心跳丢失比例超过 85% 时（大概率是网络分区而非集体宕机），Eureka 停止剔除实例、保留现有注册表——宁可用可能过期的列表，也不让注册表被"清空风暴"打崩所有调用。
AP 取舍：Eureka 是 AP 系统——网络分区时各节点各自可用、数据可能不一致。这个选择对业务正确：注册中心的职责是"找到大致健康的实例"，配合客户端负载均衡与熔断容错单点失败；CP 强一致反而会在分区时让注册不可用。
2026 现状（必须主动说）：Eureka 2.x 闭源、Netflix 套件全面停更，新项目应选 Nacos。我保留对它的尊重：它定义了注册中心的产品形态（注册、心跳、自保护、客户端缓存），Nacos 们的身上都是它的影子。面试讲清它的 AP 设计取舍，比背它的 API 更有价值。
🏗 系统架构师
定义：Netflix 开源的 AP 型注册中心，Spring Cloud Netflix 生态的核心组件。CS 架构：Eureka Server 集群（对等复制，无主从）加 Eureka Client（注册、心跳续约、拉取列表）。
关键机制：
- 注册：启动时上报服务信息（IP、端口、实例 ID）；
- 续约：客户端 30s 心跳，Server 90s 未收到即剔除；
- 复制：Server 之间异步复制注册表，最终一致；
- 自我保护：15 分钟内心跳丢失超阈值（85% 存活线）——判定可能是网络分区而非服务全挂，停止剔除保可用，这是 AP 的精髓；
- 客户端缓存：列表本地缓存加增量拉取（delta）。
架构评价：Eureka 用「列表短暂过时」换「分区时注册中心整体可用」——配合客户端 LB 的重试与熔断，是很成熟的权衡。但 2.x 闭源停止演进、无配置中心能力，国内已被 Nacos 全面替代。我讲它更多是讲 AP 注册中心的设计思想——这套思想在 Nacos 临时实例模式（心跳加自动摘除）里被完整继承。
💻 全栈开发专家
Eureka 是 Netflix 开源的服务注册中心，Spring Cloud Netflix 生态核心，AP 系统（自我保护机制是标志设计）。
核心角色：Eureka Server（注册中心，集群对等复制）+ Eureka Client（提供方注册+心跳，消费方拉取+本地缓存）。
关键数字要背：客户端 30s 心跳续约；Server 90s 无心跳剔除实例；客户端 30s 拉取增量注册表并缓存本地——调用不走 Server 直接打本地列表，所以拉取挂了短期不影响调用；Server 间异步复制注册表（最终一致）。
自我保护机制：15 分钟内心跳数低于阈值（85%）时——大概率是网络分区而不是服务真挂——Server 暂停剔除所有实例，保住可用性（宁有过期，不可不可用）。这是 AP 的极致体现；代价是可能把流量路由到僵尸实例，调用方必须配超时 + 重试 + 熔断兜底。
现状必须说：Eureka 2.x 闭源停更，Spring Cloud 2020.0 起 Netflix 系（Ribbon/Hystrix/Zuul）移出默认生态。新项目选 Nacos；存量 Eureka 的迁移动力是维护风险与性能（HTTP 轮询 vs Nacos 长连接推送）。