大数据领域如何优化Eureka的性能表现

大数据领域如何优化Eureka的性能表现

关键词：Eureka、服务发现、性能优化、微服务、大数据集群

摘要：在大数据场景下，微服务实例规模可能达到数千甚至上万个，作为核心服务发现组件的Eureka常面临注册表膨胀、心跳风暴、集群同步延迟等性能瓶颈。本文将从Eureka的核心原理出发，结合大数据场景的典型问题，通过生活化比喻、代码示例和实战案例，系统讲解Eureka性能优化的12个关键策略，帮助开发者在高并发、大规模集群中稳定运行Eureka。

背景介绍

目的和范围

随着大数据与微服务的深度融合，电商大促、物流实时调度等场景中，微服务实例规模呈指数级增长（如双11期间某电商平台微服务实例超2万个）。Eureka作为经典的服务发现组件，在传统中小规模集群中表现优异，但在大数据场景下常出现：

• 服务注册延迟（从50ms增至500ms）
• 注册表查询超时（单次查询耗时超1秒）
• 集群节点间同步阻塞（主从节点数据差超30秒）
  本文聚焦大数据场景下Eureka Server/Client的性能瓶颈与优化方法，覆盖配置调优、架构设计、监控实践等核心方向。

预期读者

• 微服务架构师（需优化大规模集群服务发现）
• 大数据平台运维工程师（需保障高并发下Eureka稳定性）
• 中级Java开发者（需理解Eureka底层机制）

文档结构概述

本文将按照“原理→问题→优化→实战”的逻辑展开：

术语表

核心概念与联系：用“快递驿站”理解Eureka

故事引入

假设你是“闪电快递”的区域负责人，管理着1000个快递点（微服务实例）。每个快递点需要：

最初驿站只有1个白板（单节点Eureka Server），但随着快递点增多，出现了问题：

• 每天9点报平安电话太多（心跳风暴），驿站电话占线；
• 白板写满了却没人擦（注册表膨胀），找一个快递点要翻很久；
• 总部驿站故障时，所有快递点都找不到彼此（单点失效）。

这就是大数据场景下Eureka的典型困境，我们需要优化“驿站”的管理方式。

核心概念解释（像给小学生讲故事）

1. Eureka Server：快递驿站的“智能白板”
Eureka Server是一个特殊的服务器，它的核心是一块“智能白板”（注册表Registry），专门记录所有快递点（服务实例）的信息，比如：

• 快递点名称（服务名，如order-service）
• 地址（IP:端口，如192.168.1.100:8080）
• 状态（正常/故障，由心跳判断）

2. Eureka Client：会“报平安”的快递员
每个快递点都安装了“报平安软件”（Eureka Client），它做两件事：

• 注册：快递点开业时，主动告诉驿站：“我是order-service，地址是192.168.1.100:8080”；
• 心跳：每30秒打一次电话（HTTP请求）：“我还活着！”（默认30秒一次，可调整）。

3. 自我保护机制：驿站的“防误删保险”
如果某天台风导致很多快递员没报平安（比如70%的心跳丢失），驿站会触发“自我保护”：

• 不清理白板上的旧记录（怕台风停了，快递员又活过来）；
• 同时在白板上标红：“当前可能网络异常，记录可能不准”。

核心概念之间的关系（用快递驿站比喻）

• Client与Server的关系：快递员（Client）和驿站（Server）是“报平安”与“记录”的关系。快递员必须定期联系驿站，否则会被从白板上擦掉。
• 注册表与心跳的关系：白板（注册表）的内容由快递员的“报平安”（心跳）维持。如果连续3次没收到心跳（默认90秒），驿站会擦掉该记录。
• 自我保护与注册表的关系：自我保护是“保护白板不被误删”的机制。当大量心跳丢失时（比如网络故障），即使有些快递员实际已倒闭，驿站也不清理白板，避免误删正常快递点。

核心概念原理和架构的文本示意图

Eureka架构核心流程：
客户端启动 → 向Server注册（POST /eureka/apps/{服务名}） → 每30秒发送心跳（PUT /eureka/apps/{服务名}/{实例ID}） → Server更新注册表 → 客户端每30秒拉取注册表（GET /eureka/apps） → 客户端本地缓存注册表

Mermaid 流程图

#mermaid-svg-D4Flf3TnTRGnH4ev{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-D4Flf3TnTRGnH4ev .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-D4Flf3TnTRGnH4ev .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-D4Flf3TnTRGnH4ev .error-icon{fill:#552222;}#mermaid-svg-D4Flf3TnTRGnH4ev .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-D4Flf3TnTRGnH4ev .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-D4Flf3TnTRGnH4ev .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-D4Flf3TnTRGnH4ev .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-D4Flf3TnTRGnH4ev .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-D4Flf3TnTRGnH4ev .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-D4Flf3TnTRGnH4ev .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-D4Flf3TnTRGnH4ev .marker{fill:#333333;stroke:#333333;}#mermaid-svg-D4Flf3TnTRGnH4ev .marker.cross{stroke:#333333;}#mermaid-svg-D4Flf3TnTRGnH4ev svg{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-D4Flf3TnTRGnH4ev p{margin:0;}#mermaid-svg-D4Flf3TnTRGnH4ev .label{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;color:#333;}#mermaid-svg-D4Flf3TnTRGnH4ev .cluster-label text{fill:#333;}#mermaid-svg-D4Flf3TnTRGnH4ev .cluster-label span{color:#333;}#mermaid-svg-D4Flf3TnTRGnH4ev .cluster-label span p{background-color:transparent;}#mermaid-svg-D4Flf3TnTRGnH4ev .label text,#mermaid-svg-D4Flf3TnTRGnH4ev span{fill:#333;color:#333;}#mermaid-svg-D4Flf3TnTRGnH4ev .node rect,#mermaid-svg-D4Flf3TnTRGnH4ev .node circle,#mermaid-svg-D4Flf3TnTRGnH4ev .node ellipse,#mermaid-svg-D4Flf3TnTRGnH4ev .node polygon,#mermaid-svg-D4Flf3TnTRGnH4ev .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-D4Flf3TnTRGnH4ev .rough-node .label text,#mermaid-svg-D4Flf3TnTRGnH4ev .node .label text,#mermaid-svg-D4Flf3TnTRGnH4ev .image-shape .label,#mermaid-svg-D4Flf3TnTRGnH4ev .icon-shape .label{text-anchor:middle;}#mermaid-svg-D4Flf3TnTRGnH4ev .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-D4Flf3TnTRGnH4ev .rough-node .label,#mermaid-svg-D4Flf3TnTRGnH4ev .node .label,#mermaid-svg-D4Flf3TnTRGnH4ev .image-shape .label,#mermaid-svg-D4Flf3TnTRGnH4ev .icon-shape .label{text-align:center;}#mermaid-svg-D4Flf3TnTRGnH4ev .node.clickable{cursor:pointer;}#mermaid-svg-D4Flf3TnTRGnH4ev .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-D4Flf3TnTRGnH4ev .arrowheadPath{fill:#333333;}#mermaid-svg-D4Flf3TnTRGnH4ev .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-D4Flf3TnTRGnH4ev .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-D4Flf3TnTRGnH4ev .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-D4Flf3TnTRGnH4ev .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-D4Flf3TnTRGnH4ev .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-D4Flf3TnTRGnH4ev .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-D4Flf3TnTRGnH4ev .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-D4Flf3TnTRGnH4ev .cluster text{fill:#333;}#mermaid-svg-D4Flf3TnTRGnH4ev .cluster span{color:#333;}#mermaid-svg-D4Flf3TnTRGnH4ev div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-D4Flf3TnTRGnH4ev .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-D4Flf3TnTRGnH4ev rect.text{fill:none;stroke-width:0;}#mermaid-svg-D4Flf3TnTRGnH4ev .icon-shape,#mermaid-svg-D4Flf3TnTRGnH4ev .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-D4Flf3TnTRGnH4ev .icon-shape p,#mermaid-svg-D4Flf3TnTRGnH4ev .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-D4Flf3TnTRGnH4ev .icon-shape rect,#mermaid-svg-D4Flf3TnTRGnH4ev .image-shape rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-D4Flf3TnTRGnH4ev .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-D4Flf3TnTRGnH4ev .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-D4Flf3TnTRGnH4ev :root{–mermaid-font-family:\”trebuchet ms\”,verdana,arial,sans-serif;}

客户端启动

注册到Eureka Server

每30秒发送心跳

Server更新注册表

客户端每30秒拉取注册表

客户端本地缓存注册表

服务调用时使用本地缓存

大数据场景下Eureka的5大性能痛点

在大数据场景（如实例数>5000），Eureka的以下机制会成为瓶颈：

痛点1：心跳风暴（QPS爆炸）

每个实例每30秒发送1次心跳，5000个实例的心跳QPS=5000/30≈167次/秒；10000个实例则≈333次/秒。如果集群有3个Eureka节点（主从同步），总QPS≈1000次/秒，超出普通服务器（CPU 4核8G）的处理能力（约800次/秒），导致请求延迟甚至超时。

痛点2：注册表膨胀（内存与查询压力）

每个实例的注册表条目约1KB，5000个实例占5MB，10000个实例占10MB。但Eureka的注册表是全量同步（客户端拉取整个注册表），客户端每次拉取需要传输10MB数据，在1000个客户端同时拉取时，Server网卡流量可能达到10GB/秒（10MB×1000），导致网络阻塞。

痛点3：集群同步延迟（主从数据不一致）

Eureka集群采用“去中心化”同步（每个节点互相复制注册表），当实例数激增时，同步一条数据需要3次HTTP请求（A→B→C→A）。10000次注册操作会导致同步队列堆积，主从节点数据差可能超过30秒，客户端拿到旧数据，调用失败。

痛点4：GC频繁（内存管理问题）

Eureka Server的注册表存储在JVM堆内存中，当实例数超过1万时，堆内存可能达到4GB（每个实例对象约400字节）。默认的JVM配置（如-Xmx2G）会导致频繁Full GC（每5分钟一次），每次GC暂停1秒，期间无法处理心跳和注册请求。

痛点5：自我保护机制误触发（服务发现不准）

默认自我保护阈值为“最近15分钟心跳数低于预期的85%”。在大数据集群中，网络波动（如某机房断网10秒）可能导致心跳丢失率超过15%，触发自我保护，Server不再清理失效实例。客户端拿到包含大量无效实例的注册表，调用时频繁超时（因为实例已宕机）。

核心优化策略：12个实战技巧（附代码与配置）

策略1：调整客户端心跳频率（降低QPS）

原理：减少心跳次数，降低Server的QPS压力。
操作：在客户端配置中修改eureka.instance.lease-renewal-interval-in-seconds（默认30秒）。
公式：心跳QPS=实例数/心跳间隔（秒）。建议心跳间隔调整为60秒（适用于非核心服务），核心服务保持30秒。

配置示例（Spring Boot）：

# application.properties
eureka.instance.lease-renewal-interval-in-seconds=60 # 心跳间隔60秒（原为30秒）
eureka.instance.lease-expiration-duration-in-seconds=180 # 失效时间（心跳丢失3次后删除，60×3=180秒）

策略2：启用客户端本地缓存（减少注册表拉取次数）

原理：客户端默认每30秒拉取一次全量注册表，改为拉取增量或延长拉取间隔，减少Server的查询压力。
操作：修改eureka.client.registry-fetch-interval-seconds（默认30秒），并启用增量拉取（需Server支持）。

配置示例：

eureka.client.registry-fetch-interval-seconds=60 # 拉取间隔60秒（原为30秒）
eureka.client.fetch-registry=true # 启用拉取（默认true）
eureka.client.prefer-same-zone-eureka=true # 优先从同机房节点拉取，减少跨机房流量

策略3：注册表分片（横向扩展存储能力）

原理：将服务按业务线分片（如order-service→节点A，user-service→节点B），每个Eureka节点只管理部分服务的注册表，降低单节点内存和CPU压力。
实现：通过自定义EurekaClientConfig，让客户端注册到指定分片的Server。

代码示例（自定义分片逻辑）：

// 自定义Eureka客户端配置，指定注册到分片A
@Configuration
public class EurekaShardConfig {
@Value("${eureka.shard}")
private String shard;

@Bean
public EurekaClientConfigBean eurekaClientConfigBean() {
EurekaClientConfigBean config = new EurekaClientConfigBean();
// 根据分片设置Server地址（如分片A的Server是http://eureka-shard-a:8761/eureka/）
config.setServiceUrl(Collections.singletonMap(
DefaultEurekaClientConfigBean.DEFAULT_ZONE,
"http://eureka-" + shard + ":8761/eureka/"
));
return config;
}
}

策略4：优化自我保护阈值（避免误触发）

原理：根据实例数动态计算自我保护阈值，避免网络波动导致误触发。
公式：预期心跳数=实例数×（60/心跳间隔）×15分钟（900秒）。
默认阈值=预期心跳数×0.85。建议调整为0.95（更严格）或根据历史心跳丢失率动态调整。

配置示例：

# Eureka Server配置
eureka.server.renewal-percent-threshold=0.95 # 阈值从0.85调至0.95
eureka.server.renewal-threshold-update-interval-ms=300000 # 每5分钟重新计算阈值（原为15分钟）

策略5：替换注册表存储（从内存到Redis）

原理：Eureka默认将注册表存在JVM堆内存中，内存不足时GC频繁。改为用Redis存储，利用其高性能和持久化能力。
实现：通过自定义PeerAwareInstanceRegistry，将注册表操作（增/删/查）路由到Redis。

代码示例（自定义Redis注册表）：

// 自定义注册表，使用Redis存储
public class RedisInstanceRegistry extends PeerAwareInstanceRegistryImpl {
private RedisTemplate<String, InstanceInfo> redisTemplate;

public RedisInstanceRegistry(
EurekaServerConfig serverConfig,
EurekaClientConfig clientConfig,
ServerCodecs serverCodecs,
RedisTemplate<String, InstanceInfo> redisTemplate
) {
super(serverConfig, clientConfig, serverCodecs);
this.redisTemplate = redisTemplate;
}

@Override
public void register(InstanceInfo info, boolean isReplication) {
redisTemplate.opsForHash().put("eureka:registry", info.getInstanceId(), info); // 存储到Redis
super.register(info, isReplication); // 可选：保留原内存存储（双写）
}
}

策略6：JVM调优（减少GC暂停）

原理：调整JVM堆内存大小和GC算法，减少Full GC频率。
建议配置（针对8核16G服务器，实例数1万）：

# JVM启动参数
-Xms8G -Xmx8G # 堆内存固定8G（避免动态扩展）
-XX:+UseG1GC # 使用G1GC（适合大内存）
-XX:MaxGCPauseMillis=200 # 目标GC暂停时间200ms
-XX:G1HeapRegionSize=32M # 分区大小32M（适应大对象）

策略7：读写分离架构（分担Server压力）

原理：部署主节点（处理注册/心跳）和从节点（处理服务发现查询），主节点将注册表同步到从节点，客户端从节点查询。
架构图：

客户端（注册/心跳）→ 主Eureka节点 → 同步到从Eureka节点 → 客户端（服务发现）→ 从Eureka节点

策略8：禁用不必要的日志（减少I/O消耗）

原理：Eureka默认记录所有注册/心跳日志，大数据场景下日志量极大（每天数百GB），消耗磁盘I/O。
配置示例（logback-spring.xml）：

<logger name="com.netflix.eureka" level="WARN"/> <!– 只记录警告及以上日志 –>
<logger name="com.netflix.discovery" level="WARN"/>

策略9：批量心跳（减少HTTP请求数）

原理：客户端将多个实例的心跳合并为一个HTTP请求（需Server支持），减少网络连接数。
实现：修改客户端EurekaClient的心跳发送逻辑，批量打包实例信息。

代码示例（批量心跳）：

// 自定义心跳发送器，批量发送
public class BatchEurekaClient extends DiscoveryClient {
private static final int BATCH_SIZE = 100; // 每批发送100个实例心跳

@Override
protected void sendHeartBeat() {
List<InstanceInfo> instances = getLocalInstanceInfoList(); // 获取本地实例列表
for (int i=0; i<instances.size(); i+=BATCH_SIZE) {
List<InstanceInfo> batch = instances.subList(i, Math.min(i+BATCH_SIZE, instances.size()));
eurekaTransport.registrationClient.sendBatchHeartBeat(batch); // 批量发送
}
}
}

策略10：监控关键指标（提前预警）

关键指标：

• eureka.server.num-of-renews-per-min：每分钟心跳数（正常应接近实例数×(60/心跳间隔)）
• eureka.server.registry-size：注册表实例数（超过1万需警惕内存压力）
• jvm.gc.pause：GC暂停时间（超过500ms需调优JVM）

监控工具：Prometheus+Grafana（配置示例）：

# prometheus.yml 抓取Eureka指标
scrape_configs:
– job_name: 'eureka'
static_configs:
– targets: ['eureka-server-1:8761', 'eureka-server-2:8761']
metrics_path: '/actuator/prometheus' # 需启用Spring Boot Actuator

策略11：预注册机制（减少启动时注册风暴）

原理：服务启动前，通过配置中心（如Nacos）预先向Eureka注册实例信息，避免启动时大量实例同时注册导致Server压力激增。
流程：

策略12：熔断与限流（保护Server不崩溃）

原理：在Eureka Server前端部署API网关（如Zuul），对注册/心跳请求做限流（如1000次/秒），避免突发流量打垮Server。

配置示例（Zuul限流）：

# application.properties（Zuul配置）
zuul.routes.eureka.path=/eureka/**
zuul.routes.eureka.url=http://eureka-server:8761
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=5000 # 熔断超时5秒
ribbon.MaxAutoRetries=1 # 重试1次

项目实战：电商大促场景下的Eureka优化案例

背景

某电商平台大促期间，微服务实例从5000增至15000个，Eureka集群（3节点）出现：

• 注册延迟从50ms增至800ms；
• 服务发现失败率从0.1%增至5%；
• Eureka Server CPU使用率长期90%以上。

优化步骤与效果

步骤1：调整客户端配置（降低QPS）

• 将非核心服务（如log-service）的心跳间隔从30秒调至60秒；
• 所有客户端的注册表拉取间隔从30秒调至60秒。

效果：心跳QPS从15000/30=500次/秒降至（10000×30秒心跳+5000×60秒心跳）/60= (10000/30 + 5000/60)×60/60≈ 333+83=416次/秒（下降17%）。

步骤2：注册表分片（3节点→6节点）

• 按业务线分片：order-service→节点1-2，user-service→节点3-4，item-service→节点5-6；
• 每个节点管理约2500个实例（15000/6）。

效果：单节点注册表大小从15000→2500，内存占用从6GB降至1GB，GC暂停时间从800ms降至100ms。

步骤3：启用Redis存储注册表（替代内存）

• 部署3主3从Redis集群，Eureka Server将注册表存储到Redis；
• 客户端拉取注册表时，先查本地缓存，再查Redis（减少Server压力）。

效果：Eureka Server内存使用率从80%降至30%，注册表查询延迟从500ms降至100ms。

步骤4：调整自我保护阈值（避免误触发）

• 将阈值从0.85调至0.95；
• 每5分钟重新计算阈值（原为15分钟）。

效果：大促期间因网络波动触发自我保护的次数从12次降至2次，服务发现失败率从5%降至0.5%。

优化前后对比表

实际应用场景

场景1：电商大促（实例数激增）

• 优化重点：降低心跳QPS、注册表分片、Redis存储。
• 收益：支撑2万+实例稳定运行，大促期间无服务发现故障。

场景2：物流实时调度（高频服务发现）

• 优化重点：客户端本地缓存、批量心跳、读写分离。
• 收益：服务发现延迟从200ms降至50ms，满足物流秒级调度需求。

场景3：大数据计算平台（长周期任务）

• 优化重点：预注册机制、调整失效时间（如2小时）。
• 收益：避免计算任务启动时的注册风暴，减少无效心跳。

工具和资源推荐

未来发展趋势与挑战

趋势1：云原生服务发现（Kubernetes+Istio）

Kubernetes的Service和Endpoint已提供基础服务发现，结合Istio的服务网格（Service Mesh），未来可能替代Eureka。但Eureka在遗留系统、跨云场景仍有优势。

趋势2：Eureka 2.0的“复活”（社区重启）

Eureka 2.0因维护问题停止开发，但社区近期有重启计划，可能引入分片、流传输（替代HTTP拉取）等特性，大幅提升性能。

挑战：混合云与多集群场景

跨云（如AWS+阿里云）、多数据中心的服务发现需要Eureka支持跨集群同步，现有版本的同步机制（HTTP复制）延迟高，需自定义协议优化。

总结：学到了什么？

核心概念回顾

• Eureka Server：管理服务实例的“智能白板”；
• Eureka Client：定期报平安（心跳）和查询地址的“快递员”；
• 自我保护机制：防止误删实例的“防误删保险”。

概念关系回顾

• Client通过心跳维持Server的注册表；
• Server的自我保护机制依赖注册表的心跳统计；
• 大数据场景下，注册表膨胀和心跳风暴是核心瓶颈。

优化核心思路

• 降负载（调整心跳/拉取间隔、批量操作）；
• 扩容量（分片、读写分离、Redis存储）；
• 稳运行（JVM调优、监控、熔断）。

思考题：动动小脑筋

附录：常见问题与解答

Q1：调整心跳间隔后，服务宕机的发现时间会变长吗？
A：是的。例如，心跳间隔从30秒调至60秒，失效时间（3次心跳）从90秒变为180秒。需根据业务容忍度权衡：核心服务（如支付）保持短间隔，非核心服务（如日志）可延长。

Q2：注册表分片后，如何保证跨分片服务发现？
A：需要额外的“元数据中心”或“全局路由”组件。例如，部署一个全局Eureka节点，记录各分片的服务分布，客户端先查全局节点，再查对应分片的Server。

Q3：Eureka和Nacos在性能上的主要区别？
A：Nacos支持AP/CP模式、增量注册表拉取、更高效的UDP心跳，在大数据场景下性能优于Eureka（如Nacos处理10万实例的QPS是Eureka的3倍）。但Eureka的优势是简单、与Spring Cloud集成更成熟。

扩展阅读 & 参考资料