由于 cn & in 关系不稳定，近期一票涉及国际化业务的互联网公司将服务从阿里云迁移到 aws，刚好我们也是如此，这里详细记录了迁移过程和一些实施方案，希望对有类似需求的朋友提供参考。
I.迁移策略方案
首先盘点下我们用到的阿里云服务有哪些？云服务器 ECS，负载均衡 SLB，对象存储 OSS，大数据服务 MaxCompute，其中数据库、缓存、队列之类均使用 ECS + 开源产品搭建，而非阿里云服务。基本 aws 均有对标产品，EC2， ELB，S3 等可以满足需求，当然成本上 aws 产品还是略贵一些。
2.盘点服务机器
在线服务主要依赖 ECS ，系统搭建 CentOS，部署应用服务器，数据中心主要包括 Mysql 、MongoDB、Redis、ES、OSS等 ，中间件服务，消息队列，路由网关等。
离线服务数据仓库主要基于 MaxCompute，以及相关报表服务。
3.迁移策略
3.1.离线服务迁移策略
在新数据中心建立数仓，导入历史数据，新机房搭建 ETL 服务，迁移后增量数据从新机房在线服务中抽取。迁移可独立进行不受限于在线服务，注意在线服务迁移节点前后的数据补录和剔除。由于阿里云 MaxCompute 服务与 hive 语法有差异，此处还有些 sql 修改的工作。
3.2.在线服务迁移策略
原机房服务架构情况如下图
图中 router 作为网关和负载均衡，简化队列等其他服务。迁移方案总体分为不停服迁移和停服迁移两种，下面就具体分析下如何选型。
3.3.不停服迁移方案
首先在新机房按同等架构部署一套服务，数据库维持主从架构（原机房做主，新机房做从），redis （只用于缓存）两边各自部署维护。
从 网关层（router）切流量到新机房应用服务，但服务读写数据库仍从原机房（阿里云机房），如果不考虑延时或一致性要求不高的场景可以从新机房数据库读，写到原机房数据库。
应用流量迁移后，切换数据库读写到新机房，迁移前需要检查新机房是否有数据落后，通过变更连接配置进行切换，对使用数据库长连接的连接池模式，需要在程序做支持，捕获配置变更后启动新配置的连接池。
此方案采用从应用服务层到数据层自顶向下迁移，迁移过程中会出现双机房双活和跨机房调用的情况，确保尽可能少的出现跨机房调用。
方案优点：
服务基本可用，对用户无感知，或感知较小。
方案缺点：
实施过程复杂，跨机房数据延时会影响服务正常，切换瞬间可能会有数据不一致。
为了减少跨机房延时，一般采用拉专线方式，同机房数据传输一般延时在 10ms 以内， 同城专线一般延时在 10 ms 左右，跨城专线一般在 10 - 200 ms，公网传输一般在几百毫秒。
由于两个机房之间无法直接拉专线，跨机房调用可能会导致服务延时失败，出现更多不可控因素，且业务存在夜间低峰期且无新用户，停服影响可接受，因此最终实施将会按停服方案来操作。
3.4.停服迁移方案
和不停服一样，首先搭建一套镜像服务，在某个时间点会将所有写入暂停（无新数据写入），待数据全部同步新机房后，在新机房启动服务，并将流量完全导向新机房。
方案优点：
实施过程简单，实施过程中不会出现脏数据。
方案缺点：
会有一段时间对用户完全不可用，必须根据业务场景来评估是否可接受。
II.执行计划
1.完善实施细节
实施迁移前，必要的准备工作必不可少，购买新机房服务，配置网络及服务的搭建，应用服务的部署，数据库的准备及数据同步（及一致性检查），涉及到 ip 变更合作机构加白名单，以及必要的通知工作，最后需要对新机房服务做回归测试和校验。为了防止遗漏，最好使用 checklist 清单，完成一项对其打钩。
2.执行迁移过程
选择合适的迁移时间，服务低峰时间，避开必要的定时任务执行时间，梳理清可提前的或可推后的定时任务，迁移时间与必须按时执行的定时任务错峰。迁移过程对用户访问进行限制，除测试白名单可正常访问服务，其他用户会提示 “系统升级，请稍后回来” 。
迁移计划可以分几步，确定好时间，执行人，执行内容，必要的执行操作，做好 checklist 清单，格式如下：
-
停止原机房对外服务
1) 上线代码控制访问请求
2) 停止定时脚本和常驻 （注意顺序）
3) 观察数据无写入 xx 时间，保险起见对主库改为 readonly
4) 观察队列无新增，消费已完成 （可省略迁移队列数据）
-
外网域名 DNS 解析切换
1) 外网域名 DNS 解析切换
2) DNS解析生效需要周期，此时打入旧机房流量可以做转发到新机房
新机房服务恢复
回归测试
恢复对外服务
1) 在准备阶段已完成服务部署，数据库维持从库同步数据，此时断开与主库连接
2) 可以校验数据是否完全一致，准备阶段完成历史记录校验，迁移阶段只校验增量部分
3) 涉及 OSS 数据，需要同步到 S3，没有直接同步工具，可以先下载再上传，最后写了个比对工具校验两边一致性
4) 定时任务和常驻进程在新机房启动。
1) 观察日志监控
2) 服务和业务监控
3) 其他系统服务恢复
3.迁移过程的突发事件
虽然做了“万全”的计划，但迁移过程还是会发生一些计划外的事件，这时候就要随机应变了，但一个基本原则就是是否可以先忽略？如果不影响正常业务可以事后解决。
在停止对外访问后，按预期将没有新数据写入，但发现 MongoDB 数据库仍有数据写入，通过追查连接 ip 发现有其他部门服务连接，此时半夜无法联系到对方处理，最后确认该数据表我们并不使用，那么可以忽略不处理，但因为此项确认比预期要长，整体迁移时间也向后发生了偏移。
MongoDB 采用了停服后全量数据导出，在新服务器上导入的方案，并未使用从库。因为数据量较少，导出恢复速度快，不会有不一致问题。
在使用 aws 的 负载均衡服务（ELB）时，发现了与阿里云的 SLB 不一样的情况，在长连接服务过程中会断开连接，而当时在场的 aws 技术支持也未能有效解决，当时根据情况决策不使用负载均衡，直接连接 ip 的方式，先解决了服务断开的问题。
aws 负载均衡有健康检查机制，如果长时间无目标响应就会断开连接。
4.回滚计划
在做迁移计划时，也会出相应的回滚方案，如果不符合预期就会执行回退到阿里云，那么在停服阶段的回滚，相对比较简单且无损。而一旦对外开放流量后再回退，基本上需要执行迁移方案的逆向操作。
III.收尾
服务前移完成后，还有一些收尾的工作，以及服务的观察和监控。
系统指标对比：如 cpu、内存、io 等系统层面的使用情况和负载 应用指标对比：如接口响应时间，QPS 等情况
业务指标对比：如关键业务的转化率等情况
更多实施细节欢迎关注我的公众号留言与我讨论。
