一、方案概述
本方案针对双机房部署场景，结合“微服务不跨机房调用”的业务需求，采用“机房自治、物理隔离、故障隔离”的核心原则，部署两套完全独立的Nacos集群，每套集群对应本机房的微服务体系，彻底避免跨机房依赖，保障Nacos服务（注册中心+配置中心）的高可用，同时简化运维复杂度，降低故障扩散风险，适配业务不跨机房调用的核心诉求。
核心目标：实现单机房故障时，另一机房Nacos集群与微服务体系可独立正常运行，故障隔离无扩散，RTO（恢复时间目标）控制在5分钟内，保障服务注册与配置管理的连续性。
二、核心架构设计
2.1 整体架构
采用“双机房、双独立集群”架构，两套集群物理隔离、互不依赖，具体架构如下：
- 机房A：1套Nacos集群（3个节点，奇数节点保障Raft协议正常选举）+ 1套独立MySQL数据库 + 内网SLB（Nginx/HAProxy）+ 机房A微服务集群
- 机房B：1套Nacos集群（3个节点）+ 1套独立MySQL数据库 + 内网SLB（Nginx/HAProxy）+ 机房B微服务集群
- 核心约束：微服务仅访问本机房Nacos集群，不跨机房进行服务注册、发现及调用；两套Nacos集群之间不进行任何数据同步，彻底实现故障隔离。
2.2 关键组件配置
2.2.1 Nacos集群部署（单机房内）
- 节点要求：每个机房Nacos集群至少3个节点，采用对等节点架构，避免单点故障；节点部署在不同服务器，降低硬件故障影响。
- 一致性协议：服务注册元数据采用Raft协议（选举Leader处理写操作，Follower同步数据并处理读请求）；配置数据采用Distro协议（去中心化设计，提升读性能，支持水平扩展）。
- 内网SLB配置：采用Nginx Stream或HAProxy做四层TCP代理，同时代理Nacos的8848端口（HTTP接口、控制台、配置拉取）和9848端口（gRPC接口，服务注册、心跳、推送），配置健康检查，自动剔除宕机节点；负载均衡策略推荐“最小连接”，适配微服务长连接场景。
2.2.2 数据存储配置（核心区分）
Nacos的配置数据与服务注册数据存储位置不同，需针对性配置，确保数据安全与隔离：
- 配置数据：永久存储在各机房独立的MySQL数据库中（生产环境禁用内置Derby数据库），两套MySQL互不关联，物理隔离；配置namespace、group、dataId在两套集群中保持一致，通过CI/CD脚本或配置同步工具统一发布，避免手动修改导致的配置不一致。
- 服务注册数据：默认采用临时实例（99%微服务场景适用），仅存储在Nacos节点内存中，不写入MySQL；集群内节点通过Distro协议异步同步内存数据，保障集群内数据一致；微服务通过心跳（默认30秒）保活，无心跳则自动剔除实例；Nacos节点重启后，微服务会自动重注册，无需手动干预。
- 特殊说明：仅固定物理机、硬件设备等场景需使用持久化实例（写入MySQL），微服务场景不推荐，避免影响性能。
2.2.3 客户端配置
微服务客户端仅配置本机房Nacos集群的SLB地址，无需配置跨机房地址，确保不跨机房调用：
spring.cloud.nacos.discovery.server-addr=本机房SLBIP:8848
spring.cloud.nacos.config.server-addr=本机房SLBIP:8848
# 启用客户端本地容灾，提升故障时可用性
system.setProperty("nacos.client.failover.enabled", "true")
三、容灾核心机制
3.1 故障隔离机制
由于两套Nacos集群物理隔离、无数据同步，且微服务不跨机房调用，任一机房发生故障（如网络中断、集群崩溃、MySQL故障），均不会影响另一机房的正常运行，实现100%故障隔离。
3.2 故障应对策略
| 故障类型 | 影响范围 | 应对措施 | 恢复时间 |
|---|---|---|---|
| 单Nacos节点宕机（机房内） | 机房内部分请求失败 | SLB自动剔除宕机节点，Raft协议重新选举Leader，Follower接管服务；微服务心跳自动切换至健康节点 | <30秒，业务无感知 |
| 机房内MySQL故障 | 该机房Nacos配置写操作失败，读操作正常（依赖内存缓存） | 切换至MySQL从库（提前部署主从架构），更新Nacos数据库连接配置；配置回滚可通过Nacos历史版本实现 | 1-5分钟，读服务不受影响 |
| 整个机房故障（如网络中断、集群崩溃） | 该机房所有Nacos及微服务不可用 | 通过网关/DNS将流量切换至备用机房，备用机房Nacos集群与微服务独立运行，无需额外配置调整 | 3-5分钟，业务短暂波动 |
| Nacos集群整体崩溃（单机房） | 该机房微服务无法注册、发现服务 | 重新部署Nacos集群，连接本机房MySQL恢复配置数据；微服务自动重注册至新集群 | 10-30分钟，需提前演练部署流程 |
3.3 备份与恢复策略
3.3.1 配置数据备份
- MySQL备份：每个机房的MySQL采用“每日全量+增量备份”策略，备份文件上传至本地或对象存储，保留周期至少7天，重要环境保留30天。
- 配置版本管理：利用Nacos内置版本记录功能（支持100个版本），关键配置永久保留历史版本，便于快速回滚错误配置。
3.3.2 服务注册数据恢复
服务注册数据默认存储在内存，无需额外备份；Nacos集群重启或恢复后，微服务会通过自动重注册机制，快速恢复服务列表，无需手动干预。
3.3.3 集群恢复流程
- MySQL故障恢复：切换至从库，更新Nacos数据库连接，重启Nacos节点即可同步数据。
- Nacos集群崩溃恢复：重新部署3节点集群，配置MySQL连接，启动后微服务自动重注册，配置数据从MySQL同步。
- 机房故障恢复：故障机房修复后，重新启动Nacos集群与微服务，通过配置同步工具同步最新配置，恢复正常流量。
四、流量切换策略
结合“微服务不跨机房调用”的需求，采用两种流量切换模式，适配不同业务场景：
4.1 主备模式（推荐）
- 正常状态：所有业务流量均指向主机房（如机房A），备用机房（机房B）处于待命状态，微服务正常运行但无流量。
- 故障切换：主机房发生故障时，通过网关/DNS快速将流量切换至备用机房，备用机房直接接管业务，无需修改Nacos及微服务配置。
4.2 双活模式
- 正常状态：两个机房同时运行业务流量，按用户、区域或业务模块分流，各自使用本机房的Nacos集群。
- 故障切换：任一机房故障时，停止该机房流量，将对应业务流量切换至另一机房，实现业务无中断。
五、生产环境运维注意事项
- 集群配置规范：每个机房Nacos集群节点数≥3，禁用内置Derby数据库，配置MySQL主从架构；SLB需启用健康检查，及时剔除异常节点。
- 配置同步管理：两套Nacos集群的配置需保持一致，通过CI/CD脚本或配置同步工具统一发布，禁止手动分别修改，避免配置不一致导致业务异常。
- 监控告警配置：实时监控Nacos集群状态（节点健康、内存使用率）、MySQL运行状态（连接数、备份完整性）、SLB转发状态，设置告警阈值，提前预警潜在故障。
- 故障演练：定期（每月）演练故障切换流程（如单节点宕机、MySQL故障、机房切换），确保恢复机制有效，缩短故障恢复时间。
- 客户端优化：微服务启用本地容灾机制，配置连接超时和重试策略；定期检查客户端与Nacos的连接状态，避免连接泄露。
- 安全配置：开启Nacos鉴权功能，设置自定义密钥，防止未授权访问；限制SLB访问权限，仅允许本机房微服务访问。
六、方案优势与适配性
6.1 核心优势
- 故障隔离彻底：两套集群物理隔离，无跨机房依赖，任一机房故障不影响另一机房，风险可控。
- 运维简单：无需配置跨机房数据同步，无需处理跨机房一致性问题，降低运维复杂度和出错概率。
- 性能优异：服务注册数据存储在内存，结合Distro协议，支撑高并发注册与心跳；无跨机房网络延迟影响。
- 可落地性强：贴合“微服务不跨机房调用”的业务场景，无需修改业务代码，仅需调整部署与配置。
6.2 适配场景
本方案适用于“双机房部署、微服务不跨机房调用”的所有场景，尤其适合对故障隔离要求高、运维资源有限、追求高可用且简化架构的企业，可直接落地执行。
七、总结
本方案以“机房自治、物理隔离”为核心，通过双机房独立Nacos集群部署，结合Nacos存储机制特性，完美适配“微服务不跨机房调用”的需求，实现了Nacos服务的高可用容灾。方案既避免了跨机房部署的复杂性和风险，又保障了故障时的业务连续性，同时简化运维，是该场景下最优的Nacos容灾解决方案。建议根据业务规模，完善MySQL主从架构、监控告警和故障演练流程，进一步提升容灾能力。
