由于 cn & in 关系不稳定，近期一票涉及国际化业务的互联网公司将服务从阿里云迁移到aws，刚好我们也是如此，这里详细记录了迁移过程和一些实施方案，希望对有类似需求的朋友提供参考。
I.迁移策略方案
1.盘点云服务
首先盘点下我们用到的阿里云服务有哪些？云服务器 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 清单，格式如下：
4) 观察队列无新增，消费已完成 （可省略迁移队列数据）
1)观察日志监控
2) 服务和业务监控
3) 其他系统服务恢复
3.迁移过程的突发事件
虽然做了“万全”的计划，但迁移过程还是会发生一些计划外的事件，这时候就要随机应变了，但一个基本原则就是是否可以先忽略？如果不影响正常业务可以事后解决。
在停止对外访问后，按预期将没有新数据写入，但发现 MongoDB 数据库仍有数据写入，通过追查连接 ip 发现有其他部门服务连接，此时半夜无法联系到对方处理，最后确认该数据表我们并不使用，那么可以忽略不处理，但因为此项确认比预期要长，整体迁移时间也向后发生了偏移。
MongoDB 采用了停服后全量数据导出，在新服务器上导入的方案，并未使用从库。因为数据量较少，导出恢复速度快，不会有不一致问题。
在使用 aws 的负载均衡服务（ELB）时，发现了与阿里云的 SLB 不一样的情况，在长连接服务过程中会断开连接，而当时在场的 aws 技术支持也未能有效解决，当时根据情况决策不使用负载均衡，直接连接 ip 的方式，先解决了服务断开的问题。
aws 负载均衡有健康检查机制，如果长时间无目标响应就会断开连接。
4.回滚计划
在做迁移计划时，也会出相应的回滚方案，如果不符合预期就会执行回退到阿里云，那么在停服阶段的回滚，相对比较简单且无损。而一旦对外开放流量后再回退，基本上需要执行迁移方案的逆向操作。
III.收尾
服务前移完成后，还有一些收尾的工作，以及服务的观察和监控。
迁移前可在原机房看一些关键数据，如最后一条用户数据、订单数据等，然后在新机房有针对性的查看放量后新增数据情况。
经过历时几个小时的通宵迁移，服务已平稳从阿里云机房迁移至了 aws 机房，观察几个小时后整体符合预期，算是基本圆满达成目标。
