现有业务是否应迁移至香港CN2服务器：按停机窗口与回退条件决策

现有业务是否应迁移，不能只看“香港CN2服务器”这一名称，而要先确认当前问题是否确实来自访问链路，并判断停机窗口、数据同步、环境兼容和回退能力能否同时满足要求。若现有业务面向内地用户，已有记录显示主要瓶颈集中在网络路径，且目标服务器经过同口径验证后更符合验收标准，同时能够在允许的窗口内完成最终同步与切换，则可以迁移。

反过来，如果慢请求主要由数据库、应用代码、磁盘或第三方接口造成，迁移服务器通常不能解决根因；如果业务不能暂停写入、数据又没有增量复制能力，或者切换后无法恢复到旧环境，也不应直接迁移。此时更稳妥的做法是先完成兼容测试、预同步和回退演练，再决定正式切换。

先用五个条件判断是否具备迁移资格

迁移前应设置“硬门槛”，而不是依靠总体评分掩盖单项风险。以下任意关键项为红色，都建议推迟迁移。

这里的核心原则是：迁移收益可以通过后续优化提升，但数据一致性和回退能力不能依靠上线后补救。

停机窗口不能只按文件大小估算

迁移窗口通常由多段时间组成。若采用预同步方式，真正的业务停机时间可按下面的口径估算：

停机时间 ≈ 停止写入
         + 最终增量同步
         + 数据一致性检查
         + 应用启动与预热
         + 健康检查
         + 流量切换
         + 故障缓冲

DNS记录的完全更新不一定等于业务持续停机。如果旧环境和新环境可以在过渡期同时提供兼容服务，影响可能较小；但对于会话、本地文件、数据库写入高度耦合的业务，DNS切换期间的新旧访问必须纳入一致性设计。

用有效吞吐量计算同步时间

不要直接用端口标称带宽计算。应根据迁移时段、单连接限制、加密开销、磁盘读写和小文件数量，测得实际可用吞吐量，再加入修正系数：

预计全量同步小时数
≈ 数据量GB × 8 × 1000 ÷ 有效吞吐量Mbps ÷ 3600 × 修正系数

例如，假设待传输数据为500 GB，迁移时实际有效吞吐量为200 Mbps，综合小文件、校验和波动后使用1.3的修正系数：

500 × 8 × 1000 ÷ 200 ÷ 3600 × 1.3 ≈ 7.2小时

这只是计算示例，不代表任何香港CN2服务器的实际传输性能。正式计划必须使用自己的数据规模和迁移时段测量值。

根据窗口选择迁移模式

大多数传统业务更适合“预同步加最终增量”。它不要求重构应用，但必须明确哪些数据会持续变化，以及这些数据由文件同步、数据库机制还是应用接口负责迁移。

迁移前先验证收益是否来自线路

香港CN2服务器主要影响网络路径和连接质量，不会自动提升代码执行效率、数据库查询速度或磁盘处理能力。迁移收益验证应从外到内进行。

1. 记录现有环境的DNS解析、连接、TLS握手、首字节和总请求时间。
2. 使用目标服务器临时地址部署相同版本的测试实例。
3. 从具有代表性的用户网络或监测节点访问目标实例。
4. 使用相同域名、接口、请求内容和时间段对比。
5. 区分网络时间、应用处理时间与第三方接口等待时间。

对于HTTPS业务，可以在不修改公共DNS的情况下，通过 curl --resolve 指定目标地址。执行前应确认测试域名证书已经部署到目标服务器，并将示例中的域名和IP替换为实际值：

curl --resolve service.example.com:443:TARGET_IP \
  -sS -o /dev/null \
  -w 'http=%{http_code} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' \
  https://service.example.com/health

如果连接时间改善但首字节仍然很慢，应继续检查应用和数据库，而不是仅凭线路判断迁移成功。如果连接阶段没有改善，则要确认测试节点是否具有代表性、目标地址是否为正式交付线路，以及访问是否经过了代理、CDN或其他中间层。

在已安装 mtr 的Linux环境中，可以保留路径和丢包观测记录：

mtr -rwzc 50 TARGET_IP

路由可能随访问网络、方向和时间变化，部分节点也可能不响应探测包。因此，单次路由追踪不能独立证明线路质量或线路归属，应结合交付信息、多个来源节点和业务请求记录综合判断。

对目标环境做兼容性验收

兼容性问题经常不会在安装时出现，而会在切换流量后表现为权限错误、任务未执行、上传失败或外部接口拒绝。正式迁移前至少核对以下项目：

• 操作系统版本、CPU架构和时区是否符合应用要求。
• 运行时、Web服务、数据库客户端及扩展版本是否一致。
• 文件系统是否支持应用依赖的权限、符号链接、扩展属性和大小写规则。
• 上传目录、日志目录、缓存目录和临时目录是否可写。
• 定时任务、后台队列、守护进程是否部署，且不会在预演阶段提前消费正式任务。
• 应用是否写死旧IP、主机名、目录路径或回调地址。
• 第三方平台是否限制来源IP，新服务器出口地址是否需要加入允许列表。
• TLS证书、完整证书链、私钥权限和自动续期机制是否正常。
• 会话是否保存在本机；如果是，切换后现有用户可能需要重新登录。
• 授权软件是否与设备标识、网卡地址或IP绑定。

对于Linux服务器，可先核对发行版和基础环境。以下命令适用于常见Linux环境，其中 timedatectl 需要系统使用systemd；不确定时应先检查系统版本，不要直接照搬服务管理方式：

cat /etc/os-release
uname -m
df -Th
ip route
ps -p 1 -o comm=
timedatectl

应用验收不能只检查首页。至少要覆盖登录、查询、写入、上传、下载、消息发送、回调接收、后台任务和管理端操作，并记录每个用例的预期结果。

数据迁移必须区分文件与数据库

普通静态文件可以使用文件同步工具处理，但正在运行的数据库不能通过复制其底层数据目录来代替一致性备份。数据库应使用对应版本支持的备份恢复或复制机制，并在预演中验证恢复结果。

文件同步前应先确认目标目录为空或内容可控，并保留独立备份。下面的 rsync 示例默认不删除目标端文件，先执行预览：

rsync -aHAX --numeric-ids --dry-run \
  /srv/app/ user@TARGET_IP:/srv/app/

确认目录映射、权限和容量无误后，再去掉 --dry-run 执行正式预同步：

rsync -aHAX --numeric-ids --info=progress2 \
  /srv/app/ user@TARGET_IP:/srv/app/

-A 和 -X 涉及ACL及扩展属性，需要源端、目标端文件系统和执行权限支持。如果业务不依赖这些属性，应根据实际环境调整，而不是机械复制参数。不要在未备份和未完成预演时加入 --delete，否则路径配置错误可能造成目标文件被删除。

需要单独列出的动态数据通常包括：

• 用户上传文件；
• 数据库中的新增和更新记录；
• 本地会话文件；
• 消息队列中尚未处理的任务；
• 定时任务生成的数据；
• 应用缓存中不能自动重建的内容；
• 搜索索引或派生数据。

每一类数据都应明确负责人、同步方式、最后更新时间和验证方法。没有迁移价值且可安全重建的缓存，不必与核心业务数据采用同等策略。

按固定顺序执行正式切换

1. 切换前冻结环境变更

迁移前停止非必要发布、数据库结构调整和基础配置修改，确保预演环境与正式切换环境一致。提前调整DNS TTL时，应根据DNS平台允许范围和业务策略设置，并等待旧TTL自然过期，不能在切换当天临时修改后期待立即生效。

此时应完成：

• 源端完整备份并验证能够读取；
• 目标端应用、配置和依赖安装；
• 监控、日志采集和告警接入；
• 全量数据预同步；
• 回退脚本或操作步骤复核；
• 业务方、运维方和数据负责人确认窗口。

2. 进入窗口后停止新增写入

可以通过维护模式、只读模式或停止写入入口实现。不要只停止前台页面，还要暂停后台任务、定时任务、消息消费者和会产生数据的回调接口。

停止写入后记录准确时间，并确认数据库写入量、上传目录修改时间和任务队列均不再变化。若仍有写入，不能开始最终同步。

3. 执行最终增量同步

再次同步动态文件，并等待数据库复制追平或完成最终一致性备份恢复。同步结束后检查：

• 源端与目标端关键表记录是否符合预期；
• 核心文件数量、大小或校验值是否一致；
• 数据库字符集、时区和自增状态是否正常；
• 后台任务是否保持暂停；
• 目标端是否误发通知或调用生产回调。

不必为所有缓存文件计算校验值，但订单、用户上传、配置附件等不可重建数据应进行重点核验。

4. 在不切换公共流量的情况下验收

先通过临时域名、内部负载入口或 curl --resolve 验证目标服务。验收内容至少包括：

健康检查返回正常
登录及鉴权正常
一项核心读取交易正常
一项受控写入交易正常
上传与下载正常
数据库连接正常
后台服务启动状态正常
日志中没有持续性错误
外部接口访问正常

受控写入会影响回退复杂度。若测试数据会进入正式数据集，应提前约定测试标识和清理方式；不要在生产数据库中执行未经审核的删除语句。

5. 切换流量并持续观察

流量切换后，先观察小范围请求或低风险入口，再逐步放开完整业务。若只能通过DNS切换，应同时监测新旧服务器的访问日志，因为在解析过渡期内两端都可能收到请求。

验收指标应在迁移前写明，避免故障发生后临时争论“是否需要回退”。

阈值应由业务方根据现有基线和可接受影响确定，不应使用未经验证的通用数字。

回退条件必须在目标端接收写入前确定

最容易回退的时间点，是目标服务器尚未接收正式写入之前。一旦目标端产生了订单、用户资料或上传文件，简单把DNS切回旧服务器可能造成数据丢失或业务状态倒退。

建议至少定义以下回退触发条件：

• 核心业务流程连续失败，无法在预定修复时间内恢复；
• 数据一致性检查不通过；
• 数据库复制无法追平或出现不可解释的差异；
• 目标端持续出现高比例服务错误；
• 必要的第三方接口无法从新地址访问；
• 实际停机时间即将超过批准窗口；
• 出现无法确认影响范围的权限、安全或配置异常。

同时明确RTO和RPO：

• RTO：触发回退后，旧环境需要在多长时间内恢复服务。
• RPO：允许丢失多少时间范围内的数据。

如果RPO要求为零，目标端接收正式写入后就不能直接切回旧端，除非具备反向同步、双写或再次停写并合并数据的能力。

目标端尚未产生正式写入

这种情况回退相对简单：

1. 停止继续切换流量。
2. 将入口恢复到旧环境。
3. 确认旧环境的数据库、后台任务和写入功能恢复。
4. 验证DNS或流量入口指向。
5. 保留目标端日志和现场，不要立即重装。
6. 重新开放业务并监测关键交易。

目标端已经产生正式写入

此时不要直接将目标数据目录覆盖回旧服务器，也不要未经核对就反向执行文件同步。正确顺序是：

1. 暂停目标端新增写入，记录停写时间。
2. 导出目标端迁移后新增或变化的数据范围。
3. 由数据负责人判断能否安全回补到旧环境。
4. 对不可自动合并的数据制定人工处理清单。
5. 完成回补和一致性检查后再切回流量。
6. 对外恢复服务后继续核对订单、账户、上传文件等关键数据。

如果无法在窗口内完成安全回补，应优先保护数据完整性，而不是为了快速恢复而制造第二次数据分叉。

异常发生时保留可复核证据

出现问题后，不应只保留聊天记录中的“访问慢”或“打不开”。至少记录异常时间、来源网络、目标地址、接口、状态码和日志时间范围。

在Linux环境中，可使用以下低风险命令采集基础信息。journalctl 适用于systemd系统，服务名应替换为实际名称：

date -Is
uptime
df -h
free -h
ss -s
ip -s link
ip route
systemctl status SERVICE_NAME --no-pager
journalctl -u SERVICE_NAME --since "30 minutes ago" --no-pager

DNS与接口记录可以分别保留：

dig +nocmd service.example.com A +noall +answer

curl -sS -o /dev/null \
  -w 'time=%{time_total} code=%{http_code} remote=%{remote_ip}\n' \
  https://service.example.com/health

如果系统未安装 dig、mtr 或其他工具，应根据实际发行版和包管理器确认安装方式；迁移窗口内不建议为了排障临时进行大范围系统升级。

需要归档的证据包括：

• 迁移前后的监控截图或导出数据；
• DNS解析结果与流量切换时间；
• 目标服务器访问日志、应用日志和系统日志；
• 数据同步开始、结束及校验记录；
• 数据库备份、恢复和复制状态；
• 每次配置修改的内容、执行人和时间；
• 回退触发原因及实际恢复时长。

保留旧环境直到复核完成

完成流量切换并不代表迁移已经交付。旧环境应保持可回退状态，不要立即删除数据、取消服务或修改成其他用途。具体保留时间应由业务周期、数据变化速度和回退方案决定。

复核期间持续检查以下事项：

• 新旧服务器是否仍同时收到请求；
• 是否有定时任务漏配或重复执行；
• 上传、报表、回调等低频功能是否正常；
• 目标端错误日志是否出现周期性异常；
• 备份任务是否已改为覆盖新环境；
• 监控和告警是否真正触发过；
• 旧环境是否保持隔离但可恢复；
• 迁移后新增数据是否有独立备份。

只有当香港CN2服务器的网络收益经过实际业务验证、目标环境连续满足验收条件、数据备份可用，并且回退观察期内没有未解释异常时，才适合解除旧环境。若收益仅存在于少量测试请求，或当前瓶颈仍位于应用和数据库，继续优化与观察通常比仓促完成迁移更安全。