手游项目运维迁移规划实践
一.项目介绍
公司有一个项目，’赛马’项目，在手机上会有个 ’赛马APP’。因为业务原因，并发从最初几千，将扩展到上万，需要将项目扩展，均为阿里云的ESC和其他产品。
APP下载后有3个页面 1.查询’赛马比分’信息页面 2.投注’赛马’页面 3.注册/登录页面
玩家可以在投注页面投注’赛马’，成绩在查询信息页面查询。
服务器情况：玩家app点击咨询页面，将发送请求到 zixun.saima.cn，上面解析到 1.1.1.1 这台公网机器的nginx负载均衡上。
nginx将请求给后端的java服务（zixun-saima:9091）端口。zixun-saima这个java程序则从 1.1.1.1 这台机器安装的mysql中查询数据。
投注和注册/登录页面均为如此，分别是 touzhu-saima:9092、zhuce-saima:9093
所以 1.1.1.1 上面部署了 jenkins/gogs/nginx/mysql/jdk/maven。gogs存放代码，jenkins用于构建后在本地服务器发布。
二.迁移任务
扩展需求
将这一台机器的服务，需要扩展迁移成4台机器+阿里云RDS。
其中1.1.1.1中jenkins和gogs不动 新购买一台ESC 1.1.1.2用于搭建zabbix 新购买2台ESC 1.1.1.3/1.1.1.4 每台机器部署那3个java项目，2台机器就做冗余和负载均衡。新购买一个RDS，将1.1.1.1中的mysql数据迁移上去。
业务迁移
根据业务情况来和开发分析重要性和低峰期，一般是夜里 在决定迁移的白天中先购买好机器，做好环境初始化 暂停项目更新，更改jenkins发布地址，将项目发布到1.1.1.3/1.1.1.4上面并进行测试，因为是新机器，并不影响当前项目 夜里将nignx负载均衡地址更改。进行业务测试，在app进行操作查看是否正常。进行高可用测试（nignx健康检查）。 均确定没问题后迁移成功
业务迁移注意点
记录好项目启动的端口号，确定新机器上端口起来了，很多时候jenkins上面显示发布，但端口未启动。 项目启动一般是有顺序的，要按顺序进行依次发布启动 项目发布后一般是通过域名调用，比如’赛马APP’点击咨询页面将访问zixun.saima.cn，但有些可能是写的ip，这就需要在代码里更改。 在迁移中原有服务都不要关闭，一直开启即可。
数据库迁移
评估业务低峰期，一般是晚上迁移 需要开发陪同，迁移到新数据库后，需要开发人员进行项目里数据库地址更改 当前’赛马’业务数据库只有一个’saimadata’库，大小为2G，这样采用mysqldump导出，在导入到新库即可。 白天时间确定数据库字符集，在新RDS上建立同字符集数据库，防止错误。同时确定好导出的语句。 迁移时，停掉业务，让数据库没有更新。确定当前数据库中数据总条目数进行记录。2分钟后再抽查，确定数据库确实已经没有新数据写入。 导出数据，mysql xxx < xx.sql 方式导入到新库。导入后进行新库数据条目对比，一样即可。不放心可进行数据库随机抽取比对。 没问题后通知开发人员进行数据库地址更换。
数据库迁移注意点
导入时注意数据库确实已经停止写了。如果数据量大，可以进行主从方式同步，阿里也有工具DTS。
三.迁移策略
成功迁移策略
迁移成功后，原有数据库和服务进行关闭，保留3周或1月后删除。
失败迁移策略
如果出现问题并3小时内未解决。将负载均衡地址改回原有服务地址，数据库地址不变，开放数据写入。
对出现的问题进行记录，白天时间进行讨论分析，在模拟解决后，晚上继续迁移。
四.具体迁移方案
资源统计
应用服务迁移（3台） 分布式服务迁移（3台，集群） web服务迁移（1台） 跳板机迁移（1台） nginx迁移（1台） 数据库迁移（2台）
迁移技术选型确定
2月10号开会，确定每人每块业务不会有遗漏，并且确定迁移注意事项，确定配合迁移人员，调试人员等
操作前打通隧道，实现内网互通，采用业务先迁移的方法，数据库同步，迁移时更改数据库连接地址即可
内网打通，通过内网拷贝，速度为120M/秒
方案1-整体迁移
时间：2月15 - 2月20日
步骤：
提前使用DTS同步数据库 某一时刻，停止全部业务，避免有数据写入到数据库中，停掉同步 打包9台服务器镜像，并分享到新账号下（由于使用是普通硬盘原因，生成镜像会比较慢预计2小时完成） 打包的同时需要迁移oss,表格存储到新账号中 服务器镜像打包完成，在新账号上建立服务器，使用这些打包的镜像 启动所有服务器，建立网络 配置host访问，使用跳板机管理 免密码登录需要重新设置 更改服务器IP，基础环境已经硬盘挂载，服务器基础环境建立 更改服务启动的IP，服务的IP 启动服务测试有无异常 通知业务相关人员，更改发布系统，更改连接数据库，oss,表格存储地址 重新发布所有服务 开始测试所有服务是否正常 正常，迁移完成
方案2-批次迁移
时间：2月15号正式迁移 验证测试所有重要服务器迁移步骤，如redis集群，redis单点，oss,对象存储，表格存储等迁移方式。
应用服务器迁移（3台）
备份服务器所有开放服务端口 新老账号内网打通 不影响业务时间段，一次性停止所有服务器，发公告服务器维护，进行镜像打包 晚上迁移应用服务器，在新账号建立这些服务器 所有服务，如RDS,OSS,对象存储，都通过之前内网打通方式连接 启动新服务器，对IP，服务地址进行更改 jenkins更改发布服务器的地址 nginx更改负载均衡地址 针对新服务进行发布 测试所有服务是否正常 正常迁移完成 以上操作必须在几小时内完成，不能影响第二天业务
分布式服务迁移（3台，集群）
备份服务器所有开放服务端口 不影响业务时间段，关闭所有入口，发公告服务器维护 按照集群手动停止服务，redis使用工具备份业务出来，同时java同事通过业务备份出来一份redis数据，避免迁移出现数据丢失的问题 关闭zookeeper，redis，kafaka，关闭服务之前，关闭服务器，打包镜像 在新账号下通过这些镜像恢复服务器 更改服务器初始化环境，对IP 服务器地址 恢复集群，主要是更改了IP之后的恢复 集群恢复完成 启动业务trade项目，连接基础服务 zk redis，kafka测试服务是否正常，数据是否丢失 测试通过，本次service切割完成 以上操作必须在几小时内完成，不能影响第二天业务
web服务迁移（1台）
备份服务器所有开放服务端口 不影响业务时间段，关闭所有入口，确保没有数据写入数据库 备份数据，如REDIS上所有数据，以及重要文件 关闭服务器，并进行镜像打包 在新账号下恢复此服务器 更改服务器初始化环境，对IP 服务器地址 启动服务，没有问题，web1迁移完成 以上操作必须在几小时内完成，不能影响第二天业务
跳板机迁移（1台）
备份服务器所有开放服务端口 不影响业务时间段，关闭服务器，进行打包 在新账号下恢复此服务器更改服务器初始化环境，对IP和服务器地址 更改服务IP地址，如jenkins 启动服务，没有问题，ops迁移完成 以上操作必须在几小时内完成，不能影响发布业务
nginx迁移（1台）
备份服务器所有开放服务端口 不影响业务时间段，关闭服务器，进行打包 在新账号下恢复此服务器 更改服务器初始化环境，对IP 服务器地址 由于之前已经更改了负载均衡的IP，此时不用更改，更改外网地址，以及域名解析即可 启动服务，没有问题，nginx迁移完成 以上操作必须在几小时内完成，不能影响发布业务
数据库迁移（2台）
数据库一直在同步，此时使用的是老库 不影响业务时间，停服务，确保没有数据写入数据库 数据库DTS同步停止 通知相关业务人员更改数据库连接 启动服务 测试数据是否完整可用 迁移完成
迁移技术选型确定
ECS迁移：阿里云-服务器迁移流程（镜像备份）.pdf
OSS迁移：使用 osslmport 工具迁移
RDS迁移：使用DTS进行数据同步，同步结束后停止同步，并程序切换连接地址完成迁移
REDIS迁移：单点迁移直接拷贝RDB文件即可
表格存储：Tablestore CL 工具进行迁移
点击屏末 | 阅读原文 | 即刻学习