面经策

Eureka 的实现原理说一下？ ​

  • 标签：Spring Cloud、微服务、注册中心、后端

🏛 业务架构师 ​

Eureka 的实现原理我按"存储、同步、可用"三块讲：

1. 注册表存储（两级缓存 + 内存 registry）：

  • 核心是内存中的 registry（ConcurrentHashMap<应用名, 实例列表>），写操作（注册、续约、下线）直接走它并加锁；
  • 读远多于写（客户端 30 秒拉一次），所以前面挂两级缓存：ReadOnlyCache（响应客户端拉取，默认 30 秒同步一次）+ ReadWriteCache（guava 缓存，写后失效更新）——读性能用缓存挡，注册中心扛万级实例的关键设计。

2. 同步机制（Peer to Peer 复制）：

  • Server 集群无主从，节点对等互相复制：写请求扩散到所有 peer 节点（带时间戳防旧数据覆盖新数据）；
  • 客户端可注册到任意节点——对等架构让部署和扩容简单，代价是强一致缺失（分区时各节点数据可能不同，最终趋同）。

3. 可用性三件套（AP 的落地）：

  • 心跳续约（30s）+ 没心跳 90 秒剔除；
  • 自我保护：心跳大量丢失（网络分区特征）时暂停剔除——保注册表不空，防连锁雪崩；
  • 客户端缓存：注册中心全挂，消费者靠本地缓存快照继续调用——注册中心故障降级为"变更不可用、存量调用可用"。

架构师视角的总结：Eureka 的设计哲学是**"注册中心只需尽最大努力，调用可靠性由客户端负载均衡 + 重试 + 熔断兜底"**——整个体系的可用性是分层的，不指望单点完美。这套思维（弱中心 + 端侧容错）在我设计任何"中心化平台"时都是参照。

🏗 系统架构师 ​

三层缓存架构是理解 Eureka 的钥匙：

  1. 注册表（Registry）：内存中的真实数据，写后异步复制到 peer；
  2. 读写缓存（readWriteCacheMap，180s 过期）：更新即刷新；
  3. 只读缓存（readOnlyCacheMap）：默认 30s 从读写缓存同步一次，直接响应客户端查询。

由此推出关键数字——新实例上线最大可见延迟 ≈ 客户端拉取间隔（30s）加只读缓存同步（30s）加复制延迟，接近 1~2 分钟；下线同理。做弹性扩缩容与滚动发布时必须把这个窗口算进故障预算：优雅停机（先反注册再处理存量请求）加消费端 LB 重试兜底。

设计解读（架构视角）：

  • 多级缓存 = 用一致性换读吞吐：注册中心读远多于写（每实例每 30s 拉一次），牺牲秒级实时性保护注册表与网络——教科书级的读写分离权衡；
  • 自我保护阈值防网络分区误杀整片服务；
  • 增量拉取加 hash 比对兜底，降低带宽。

这套「最终一致注册表加客户端缓存加心跳剔除」的模型，是后来所有 AP 注册中心（含 Nacos）的共同蓝本。

💻 全栈开发专家 ​

Server 端三层核心结构：

  1. 注册表存储：双层 Map 结构——应用名 → 实例ID → 租约信息（心跳时间、续约阈值）
  2. 多级缓存（扛高并发拉取的关键）：注册表读多写少，直接读大 Map 有锁竞争，所以设计了**ReadWriteCacheMap（Guava）+ ReadOnlyCacheMap（每 30s 同步）**两级响应缓存，客户端查询只读 ReadOnly，几乎无锁。代价：新实例注册后最长约 30s+30s 才对消费方可见——"最终一致"的体感来源
  3. Peer-to-Peer 复制：Server 集群无主从，注册/心跳/下线事件异步批量复制给 peer 节点，牺牲强一致换可用；分区时各节点数据可能分叉，恢复后靠心跳对账收敛

客户端四件事：注册、心跳（30s）、发现（拉增量 delta + 定期全量对齐）、下线，全部带本地缓存 + 定时刷新线程。

排查工具：/eureka/apps 直接看注册表、/eureka/status 看自我保护状态与心跳阈值、客户端 DiscoveryClient DEBUG 日志看拉取。

这套"多级缓存 + 对等复制"即使今天不用 Eureka，仍是答"注册中心如何扛读流量"的通用素材。