企业官网建设流程全解析

第 14 章：不同规模场景怎么设计（2 个 / 3 个 / N 个节点）🧭

本章目标：给出可直接照抄的选型建议——你有几个服务、要不要单独建注册中心、要不要做集群，一看就知道怎么落地。
一句话原则：注册中心是"要不要用"的问题，不是"每个服务配一个"的问题。全局最多一套（生产是一套集群）。

14.0 先记住三条铁律

1. 注册中心全局只有「一套」：不管你有 2 个还是 200 个业务服务，它们共用同一套注册中心。
2. 注册中心 ≠ 业务服务：它是独立进程/独立部署单元，不要塞进某个业务服务里（学习除外）。
3. 多个注册中心 = 高可用副本，不是"给不同业务各配一个"。

14.1 场景速查表（最重要，先看这个）

判断口诀：服务少且地址固定 → 写死；一旦要动/要扩容 → 上注册中心；一旦是生产核心 → 注册中心做集群。

14.2 场景 A：只有 2 个服务，地址固定

结论：不必上 Eureka，直接写死地址最省事。

配置直接写对方 URL：

# service-a 的配置downstream:service-b-url:http://b-host:8081

什么时候别用这招：只要出现「B 要部署多个实例做负载均衡」或「地址经常变」，就升级到场景 B。

• ✅ 优点：零额外组件、零学习成本
• ❌ 缺点：地址变要改配置重启；无自动负载均衡

14.3 场景 B：2~3 个服务，地址会变/想解耦

结论：单独建 1 个 Eureka Server，A、B（、C）都注册进去。

• 注册中心：单独 1 个进程（不要塞进 A 或 B）。
• 业务服务：都配defaultZone: http://注册中心:8761/eureka/，用服务名互调。
• 开发/内网可接受单点，注册中心挂了期间已缓存地址仍能调用（客户端有本地缓存）。

「能不能让 A 兼任注册中心？」——技术可行，但 A 一挂注册中心也没了，不推荐，仅限本机学习。

14.4 场景 C：3~10 个服务

结论：开发环境单个 Server 够用；生产环境上集群。

• 每个业务服务如果需要抗压，可以起多实例（同一个spring.application.name，不同端口）。
• Eureka 会把同名的多个实例都记下来，调用方自动负载均衡。

多实例只需改端口即可（同名注册）：

spring:application:name:order-service# 两个实例名字相同server:port:8080# 另一个实例改成 8082

14.5 场景 D：10+ 服务 / 生产核心链路

结论：注册中心必须做集群（2~3 个副本，互相注册）。

客户端指向所有副本：

eureka:client:service-url:defaultZone:http://s1:8761/eureka/,http://s2:8762/eureka/,http://s3:8763/eureka/

• 副本数建议2~3 个，跨机器/跨可用区部署。
• 任意一个 Server 宕机，其余副本继续服务，不影响注册与发现。
• 详见第08章-高可用集群.md。

14.6 场景 E：全新项目 / 需要配置中心

结论：可以直接考虑 Nacos / Consul，一套组件同时搞定「注册 + 配置」。

• Eureka 只做「服务注册发现」，配置中心要另配（如 Spring Cloud Config）。
• Nacos 把「注册中心 + 配置中心」合二为一，社区更活跃，适合 2026 新项目。
• 已经在用 Spring Cloud Netflix 的老项目，Eureka 继续用没问题。
• 详见第11章-2026选型提醒.md。

14.7 「是否需要单独建服务」决策图

14.8 常见误区纠正

14.9 本章小结

• 要不要注册中心：地址会变/要扩容才需要，否则写死即可。
• 建几个：业务角度永远一套；生产为高可用做成 2~3 副本集群。
• 别搞错：注册中心是独立部署单元，不是每个服务各配一个。
• 选型：老项目用 Eureka，新项目可考虑 Nacos/Consul。