在开始迁移前,必须做全面的准备以降低风险。首先,进行完整的资产清单与依赖关系梳理,列出所涉及的菲律宾原生IP、公网路由、域名、证书、数据库与缓存节点等。其次,制定详细的迁移计划与时间窗口,设置低流量时间段并提前通知相关团队和客户。再者,准备好回滚方案、快照与备份策略(如快照、Percona XtraBackup、mysqldump),以及测试环境来演练全流程。最后,配置监控与告警(如Prometheus、Zabbix、Grafana),并将DNS的TTL提前调低以便切换时能快速生效;这些步骤是保证业务不中断的基础。
清单应包含:源/目标服务器规格、IP与路由表、应用版本、数据库版本、依赖组件、SSL证书、会话存储位置、负载均衡配置与回滚触发条件等。对重要项使用故障演练来验证可行性。
选择流量低峰窗口并提前通知全体干系人,安排好联络人和快速响应小组以应对突发事件。
提前把DNS TTL调至60秒或更低,便于切换时快速回滚。
数据保护是核心。对于关系型数据库建议采用主从复制或双写策略:先建立目标服务器的异步或半同步复制(如MySQL主从、Galera、或Percona XtraDB Cluster),完成全量基线备份后开启增量同步。对于大文件或静态资源,可使用rsync或lftp做初次全量同步,之后用rsync的--delete和--partial参数实现差异同步;或使用实时同步工具如lsyncd、DRBD等。对于缓存与会话,采用共享存储(Redis哨兵或Cluster、Memcached集群)或将会话迁移到数据库/外部存储,避免切换时会话丢失。
数据库:Percona XtraBackup、mysqldump、binlog复制。文件:rsync、lsyncd、Rclone。会话:Redis Cluster/持久化。日志:集中化到ELK/EFK供回溯使用。
先离线做一次完整快照,再启用增量复制,验证数据一致性(校验checksum、行数对比),确保在切换瞬间主库与从库差距极小。
在某些场景可采用双写(应用端同时写入新旧库)并通过外部脚本比对,完成冷切换后再统一切除旧写入逻辑。
零中断切换通常采用“蓝绿部署/灰度发布+负载均衡切流”方案。步骤:1)在目标环境部署并完成健康检查;2)通过负载均衡器(如HAProxy、Nginx、F5)将一小部分流量导向目标实例做灰度验证;3)确认无异常后逐步增加目标流量直至全量;4)在过程中保证会话粘性或采用共享会话存储以避免用户断开。若使用云或路由策略,可先把目标机器加入后端池,移除旧机器流量。
准备好健康探针,先把目标加入LB并设置低权重,观察请求成功率、响应时延与错误率,若稳定则提升权重;最后在DNS层面或BGP/路由层面做最终切换时,配合短TTL与黑白名单测试,确保切换过渡平滑。
使用共享Redis/DB进行会话存储,或通过cookie与sticky session保持会话路由一致,避免用户因切换丢失登录态。
灰度期间开启详细访问日志与Tracing(如Jaeger),便于快速定位潜在问题。
DNS切换结合负载均衡可以实现平滑过渡:提前将DNS TTL降到低值(例如60秒),在目标机上配置好相同的域名证书(支持SNI),并确保反向代理(Nginx/HAProxy)配置一致。使用证书管理工具(如Let's Encrypt + certbot、ACME自动续期)在目标端提前完成证书颁发并测试。切换时优先在LB层或路由器层做流量切分,最后再在DNS将域名解析迁移到目标IP。如果使用菲律宾原生IP需要注意ISP路由和BGP公告,必要时与带宽提供商协调。
确保证书同时存在于新旧服务器,并且私钥安全传输。测试TLS握手、OCSP、HSTS策略,避免因证书或链问题造成访问中断。
因TTL较低,若新环境出现问题可以快速将DNS指回旧IP,同时在LB中重新加入旧节点以吸收流量。
如果担心DNS传播,可配合反向代理做基于Host头的流量路由,控制粒度更细。
迁移完成后必须进行一系列验证:功能测试、压力测试、端到端业务链路测试、日志比对和数据一致性校验。建立一份检查清单包括接口返回码、页面渲染时间、数据库主从延迟、错误率、业务关键指标(如下单成功率)。对于回滚,最好提前准备脚本化回滚流程(DNS回退脚本、负载均衡权重恢复、数据库主从倒换或从库提升为主库),并定义触发条件(错误率>阈值、服务不可用或数据不一致)。回滚必须先暂停新写入,确保数据不会再分叉,然后把流量切回旧环境并验证数据完整性。
关注指标:响应时间、5xx错误数、数据库延迟、队列积压、业务成功率。将这些指标纳入仪表盘并设置自动告警。
回滚步骤应可自动化,尽量减少人工干预。进行回滚前先通知用户并保存对等时间窗口的快照以便事后核查。
把回滚演练写入SOP并在演练环境跑一次,以便在真实回滚时从容应对。
