企业官网建设流程全解析

把业务从一台云服务器搬到另一台，真正需要回答的不是“复制 200 GB 要多久”，而是什么时候停止旧实例写入、如何确认新实例已经追平、用户流量如何安全切换。全文以 Linux + Nginx + MySQL 应用为例；命令里的域名、路径、账户和 IP 均为占位符，执行前必须替换，并先在测试环境走一遍。

适用场景与停机边界

适用于购买新地域或更合适配置的云服务器、从旧实例迁出、跨可用区搬迁，或者先迁移再扩容的中小型业务。它不承诺“零停机”：如果应用没有双写、数据库复制或可控写入冻结机制，直接切换很容易丢数据。先定义允许的 RPO（可接受数据丢失）与 RTO（可接受恢复时间）。若 RPO 必须为零，切换前就要让旧实例停止写入，并确认数据库和文件增量全部到达新实例。

上图把“耗时但不必停机的预复制”和“必须控制写入的最终切换”分开。DNS 缓存尾部不等于实际停机时间；切换期间让旧入口继续服务、代理到新入口或保持只读，取决于应用架构。

先量资源，再估算窗口

至少记录：业务文件总量与每日/每小时变化量、源/目标磁盘读写与 IOPS、两个地域之间的实测有效传输速率、MySQL 写入速率与复制延迟、目标实例 CPU/内存峰值、公网带宽、备份空间，以及 DNS 当前 TTL。不要用云厂商标称带宽直接代替跨地域实测吞吐；也要把快照、出站流量和双实例并行时间列入成本核算。

初次文件同步可粗估为待复制字节 ÷ 实测有效吞吐。最后一次增量同步则近似为冻结前尚未同步的变化字节 ÷ 实测有效吞吐。真正的写入冻结窗口还包含连接排空、数据库追平、最终校验、应用冒烟测试和入口切换，并留出回滚余量。不能把 DNS TTL 当作一个“到点所有用户立刻更新”的倒计时：递归解析器和客户端缓存行为可能不同。

若目标磁盘写入持续接近上限，或复制延迟在业务高峰不断增长，应先升级目标云服务器的磁盘/实例资源，或调整迁移时段；否则冻结后也追不平。若峰值流量需要旧、新两台同时承接，还要检查目标实例与入口带宽是否足够。

可执行迁移步骤

1. 清点与演练

列出应用目录、上传文件、计划任务、环境变量、证书、Nginx 配置、数据库版本、账号权限与外部依赖。保留已验证可恢复的数据库备份和云盘快照。先在目标实例安装兼容版本，打通安全组与私网/SSH 连通性，再在非生产环境复演完整步骤。

2. 在线预复制静态和上传文件

以下示例从源实例执行。末尾斜杠表示同步目录内容；--dry-run只预演变更，不写入目标。确认目标路径和权限后再执行真实同步。这里刻意不使用--delete，避免误删目标已有文件。

rsync-a--dry-run --itemize-changes-essh/srv/app/uploads/ ops@NEW_HOST:/srv/app/uploads/rsync-a--info=stats2-essh/srv/app/uploads/ ops@NEW_HOST:/srv/app/uploads/

对需要保留 ACL、扩展属性或属主的目录，先确认源/目标文件系统支持、执行账户有权限，再评估-A -X --numeric-ids；不要机械复制运行中的数据库数据目录。参考 rsync 官方手册。

3. 单独处理数据库并追平

MySQL 数据应使用一致性备份/恢复、官方支持的复制链路或经验证的迁移工具，不能对正在写入的 InnoDB 数据目录直接rsync后就启动。先把目标设为只读并追源实例；观察复制错误、延迟与关键表校验结果。切换前记录复制位置/GTID，冻结旧实例写入后等待目标追平，再做最终一致性检查。使用的数据库版本、拓扑和操作方式不同，具体复制命令应以相应版本的 MySQL 官方复制文档 为准。

4. 降低 TTL、冻结写入、最终同步

提前至少一个原 TTL 周期调整 DNS TTL，避免到切换时旧值还在缓存中；但这不能保证所有客户端按时更新。正式切换时，先将旧应用置于维护/只读模式并排空写请求，然后确认数据库追平，再做一次文件增量同步和目录/抽样校验。记录每一步开始结束时间，超过预设窗口立即按预案停止切换。关于 TTL 的缓存边界，可参见 Cloudflare 官方说明。

5. 先验新实例，再切入口

在 DNS 变更前，利用curl --resolve指定目标 IP，测试域名对应的 HTTPS 证书、Nginx 路由和健康检查；再把负载均衡器后端或 DNS 记录切到新实例。下面的TARGET_IP为示例占位符。

sudonginx-tcurl--fail--show-error--resolveexample.com:443:TARGET_IP https://example.com/healthdig+short example.com @1.1.1.1

dig只反映指定解析器的查询结果，不代表所有用户都已切换。旧入口至少保留到缓存尾部和监控观察期结束；若需要代理转发，先设计好真实客户端 IP、会话、回源超时和防循环规则。

如何确认成功，以及何时回滚

从不同网络访问域名，验证登录、读写、文件上传、后台任务和回调；比较关键业务记录数或校验值、目标实例错误日志、5xx 比例、p95 延迟、CPU、内存、磁盘 IO 与数据库复制状态。只有新实例完成真实读写验证，才解除只读并放开业务写入。

回滚门槛要提前写清：例如关键写入失败、持续 5xx、数据库校验不一致，或预计超出冻结预算。一旦新实例已经接收写入，不能简单把 DNS 改回旧实例，否则会产生写入分叉；必须先有反向同步方案，或保持冻结并恢复到一致的备份点。

常见误区

• 只算首轮全量拷贝时间，不测最后增量和数据库追平速度。
• 认为 TTL 到期等于所有用户同时切换，提前关闭旧服务器。
• 对在线数据库直接同步数据目录，把文件复制成功误认为数据一致。
• 忽略上传文件、证书、定时任务和外部回调，导致首页正常而业务失败。
• 目标实例只按平均负载选型，未覆盖迁移并行期和峰值磁盘 IO。

云服务器该如何选

如果这次迁移是为了购买、升级或跨地域更换云服务器，先用峰值 CPU/内存、数据库磁盘延迟与 IOPS、实测带宽、备份保留量、地域时延和高可用要求做目标配置表；再用预复制与演练数据反推切换窗口。资源有余量、复制能稳定追平、回滚路径可验证，比只比较一张配置报价表更能降低迁移风险。