1.

前置准备与评估

- 资产清单：列出待迁移的应用、数据库、状态存储、证书、外部依赖。
- 性能指标：当前QPS、并发、带宽、RTO/RPO目标（例如RTO=0，RPO=0/几秒到几分钟）。
- 网络条件：确认现有出口是否支持 CN2 或是否需办理 CN2 专线 / 与运营商协商 Direct Connect/SD-WAN。

2.

选择接入方案

- 方案 A：使用运营商 CN2 + 直连（Direct Connect）到 AWS 日本区域（推荐对延迟敏感的业务）。
- 方案 B：使用 IPSec VPN + CN2 加速（成本与部署速度折衷）。
- 决策要点：延迟需求、带宽峰值、合规性、预算与合作伙伴可用性。

3.

搭建网络拓扑（VPC & 子网）

- 在 AWS 日本区域创建 VPC：合理规划 AZ、子网（公有/私有）、路由表、NACL。
- 配置 NAT Gateway / Internet Gateway，预留弹性 IP。
- 规划安全组：最小化打开端口，明确互联两端允许的 CIDR/端口。

4.

建立 CN2 专线或加速通道（运营商对接）

- 提交工单给运营商：填写带宽、接入点（POP）、目标机房（AWS Direct Connect 对应位置）。
- 如果使用 Direct Connect：选择 LAG/虚拟接口，配置 BGP Peer（AS号、邻居 IP、预期路由）。
- 验收回环与链路质量：做丢包、抖动、带宽测试。

5.

安全与认证（证书、访问控制）

- 在 AWS 上创建 IAM 角色、策略，最小权限原则。
- 证书：为域名在日本环境申请或复制 SSL/TLS 证书（ACM 或自签导入）。
- Vault/Secrets：同步或安全迁移密钥、凭证，避免明文传输。

6.

数据同步策略（数据库与文件）

- 数据库：使用主从复制（MySQL binlog、Postgres logical replication）或 AWS DMS 做持续迁移；启用 GTID 可简化位置管理。
- 文件与对象存储：对静态文件用 rsync + rsyncd/lsyncd 或使用 S3 同步工具（s3sync/s3cmd）与并行校验。
- 校验：逐表/逐文件校验行数、校验和（md5/sha256）。

7.

应用同步与无状态化改造

- 将服务拆分为无状态前端与有状态后端；把会话状态迁移到 Redis/Memcached 或粘性 Cookie 的共享存储。
- 构建镜像与部署流水线（CI/CD），在日本区域预先部署同版本的应用实例并进行 smoke test。
- 配置健康检查接口，确保 ALB/ELB 能自动移除不健康实例。

8.

双活与灰度流量切换方案

- 初期并行跑：在国内与日本同时运行，采用双写或异步写（注意数据一致性方案）。
- 流量分流：使用 Route53 加权路由 或 全球负载均衡器（如 ALB + DNS）将一定比例流量导向日本节点进行灰度。
- 监控：针对错误率、延迟、业务关键指标设阈值，自动回滚权重到国内。

9.

DNS 切换与 TTL 策略

- 预设低 TTL（例如30s或60s）在切换前 24-48 小时内生效。
- 切换步骤：先把一小部分权重指向日本，验证健康后逐步放大到 100%。
- 考虑客户端缓存：对无法及时更新的客户端准备后备策略（例如保活更长的代理或滑动窗口回退）。

10.

零宕机切换细节（步骤化）

- 步骤 1：完成网络和安全配置；验证连通性与带宽。
- 步骤 2：建立数据库持续复制并验证落盘一致性（采样比对）。
- 步骤 3：部署应用并在日本做全面健康检查与压测（流量模拟）。
- 步骤 4：开启灰度流量（5%-20%），监控一到两个业务完整流程。
- 步骤 5：若指标稳定，按 2x、5x 放大直到切换完成；若异常，立即回退权重并定位问题。

11.

回滚与应急预案

- 回滚策略：保留 DNS、流量权重与数据库主链路指向原本线上环境；双写窗口内如需回滚，关闭日本写入并完成数据比对。
- 应急：编写 playbook（网络断开、证书错误、主从延迟过大）并练习演练（游戏日）。

12.

验证与收尾（上线后）

- 验证引导：对用户请求路径做链路追踪（X-Request-Id），确认日志、监控告警无异常。
- 性能回归：做 24-72 小时的流量观测期，记录关键 SLA 指标并和历史比较。
- 文档与知识转移：迁移过程与故障处理记录成文，交付运维与支持团队。

13.

问：如何保证在全量切换时数据库不会出现写丢或冲突？

- 答：采用主从复制或双写并结合冲突检测。优先推荐在日本建立从库并做主库到从库的异步或半同步复制；若需双写，必须实现幂等写入和冲突解决策略（例如使用全局唯一 ID、时间戳优先、合并策略），并在切换窗口内暂停批量写操作，先进行小流量验证后再扩大。

14.

问：DNS 切换过程中用户会有短暂访问失败怎么办？

- 答：通过降低 DNS TTL、使用加权路由灰度切换，以及在切换前保持国内节点的健康并继续服务，能最大限度避免失败。对于仍可能受缓存影响的客户端，可提供备用域名或通过应用层重试机制（指数退避）来遮蔽短暂解析差异。

15.

问：如果 CN2 专线建立失败或延迟无法满足，如何回退计划？

- 答：准备好备选通道（例如 IPSec VPN + CN2 加速、或第三方 SD-WAN），并在迁移前做探测比对。回退时立即把流量权重回调到原国内出口，暂停对日本写入，继续用异步复制/队列保证数据最终一致。务必在迁移前准备好可切换的运营商联系人与替代链路配置。

来源：迁移案例如何将现有服务接入日本 aws cn2并保证零宕机