aws迁移到腾讯云过程
目录：
由aws迁移到腾讯云
公司机器计划从aws迁移到腾讯云，其主要原因是价格，腾讯云这边报价就是aws的70%，而且作为大客户的我们还有优惠，并且10月12日下午也来和我们介绍了一下情况和迁移方案，本博文用于记录。
说实话我是希望下半年按照正常的节奏上docker的。
而且业务迁移好迁，但是问题就在基础服务和数据库上。
仅仅做一个记录，以后有进展会进行更新。
迁移初步规划（10月12日周四）
迁移之前
迁移的时候需要考虑的问题是两点
- 业务允许的停机时间
- 业务之间的耦合关系
停机时间直接影响迁移方案的实施
耦合又分三种
- 松耦合 不重要
- 松耦合 重要
- 紧耦合
云的使用情况
为了防止云厂商的绑定，所以一般不会深度使用，仅仅是把云服务当做IDC来使用
迁移前期
腾讯云测试费用
提供测试费用，测试各个服务性能以及其差异
专线
期初要进行拉专线，专线进行评估
专线的两种选择
- 电信专线1g
- 裸光纤10g
以上两个价格相同，大概为300多一公里
酒仙桥到希格玛大厦皮长在行驶路程的1.5倍到2倍之间，具体大概也就20公里撑死了，可以保障延迟大概在max为5ms，一般到天津200多公里的avg延迟都可以保证到5ms，min为4ms，max为9ms，到广州为50ms
我们选择两条10g裸光纤容灾，但是每个光纤跑5g，这样其中一个光纤有问题，另一根光纤也能撑起10g的流量
容量评估
容量做1:1进行匹配
对于迁移到新环境，云厂商的新区相同的配置，但是因为硬件等因素，性能会提高，理论上，但是也可能有些不可控未知因素存在
相比机器不够，肯定要保障机器数量，因为缩容还是很容易的
迁移流程
环境预部署，两边发布
在腾讯云部署相同配置的机器，发布代码的时候两边的机器都进行发布
测试
数据库导入腾讯云进行功能和性能测试
逻辑层直接到cache测试
dns灰度进行测试
数据库同步
进行迁移
逻辑层重定向，切换数据库
其他
redis主从
pfile两种，主从时延要低
oracle双主原理
只有oracle才能做到两主同时写，原理是在双主前有cache，两主同时写入成功才算成功
注意点
迁移和代码重构不在一起做
灰度的两种模式
灰度dns层，逻辑层
cdn迁移
cdn迁移，我们是七牛的cdn，回源七牛的存储空间，然后再回源s3，因为我们没有完全的index索引，而七牛也不会提供，如果迁移到腾讯云，就直接腾讯的cdn接入到腾讯的cos，回源到七牛，不过域名冲突是个问题。然后在七牛cdn基本没有流量，说明热数据已经全部迁移到cos，余下的挖坟的数据可以舍弃。
对于存储的集中形式
对象存储就是传统意义上的存储
文件存储可以类似nfs，gfs
归档存储可以认为是冷数据存储
日志存储可以对日志实时同步，切分等处理
运维组规划（10月13日周五）
第二日，运维组先分了四个规划
腾讯云调研规划
调研腾讯云产品，并且进行试用，把各个组件划分给每个人进行为期一个星期的调研。
针对我们使用的ec2虚拟机，ebs云盘，s3对象存储，vpc，安全组，账号IAM，auto scaling，安全组件，rds进行调研
- 做一下两家aws和qcould平台功能差异的对比（aws特性，qcloud特性以及两者之间差异三个问题）
- 在迁移的过程中可能会遇到的问题
- api相关功能了解
光纤问题
推进光纤问题，咨询aws提供的pos点和迁移方面的支持程度
商务对接光纤成本，推进工作进度
光纤是我们迁移的前提
基础设施的推进
从基础的ntp和dns，到我们的cmdb和zabbix的部署。
甚至还包括cmdb的改造工作，我们都是基于aws的api进行的，以后的cmdb程序需要能应对混合云模式
与业务分析迁移步骤
我们关心的问题更多是迁移的时候s3是否跟着业务一起迁移。
运维组调研结果汇总（10月23日周一）
vpc
vpc我们还是规划了pro，dev，test，op，db五个网段，腾讯云也支持对端连接，vpn连接，net连接(用于多个后端机器使用相同IP出口)，创建连接，添加路由，安全组开通才能正式的进行数据通信，不好的一点是
clb
对于aws的elb，我们感觉更像是两台haproxy构成，而腾讯云的clb，原理是8台lvs改造的节点构成，支持内网ip，公网ip和公网应用型，截至到10月23日，监控指标只有出入网流量和出入网数据包四项指标，但是不包含平响时间，后端不正常主机，HTTP4xx和HTTP5xx的数量监控项。
后端主机支持在一个可用区，例如北京二区和北京三区，但是不支持跨大区，例如北京区和广州区
cvm
cvm为aws的ec2
rds
腾讯云的rds和aws的rds差不多，但是腾讯云的rds只支持选择内存，cpu是根据选择的内存而定的，并且rds支持，参数需要提交工单修改。
腾讯云有点坑的是，rds一年为8.3折，两年4折，三年3折，确实数据库是业务的核心，绑住数据库，其他的业务自然就在上边了
cos和cdn
cos和cdn是结合的，cdn的burket是支持目录的，而七牛的cdn是一个key和value的映射。
安全产品
很贵，规则不能自定制。
总结
腾讯云是今年上半年开始完善功能，很多文档都是下半年完善，很多功能还在灰度测试，例如clb的七层指标监控，权限相关功能，总觉的自己是小白鼠了呢。
再次沟通(11月3日)
业务迁移大致方案：
- 第一步，迁移与其他系统耦合性弱的小系统，连带数据库一起迁移。
- 第二步，分批迁移与商城主业务耦合性弱的系统，数据库保留在aws云。
- 第三步，迁移商城主业务至腾讯云，数据库保留在aws云。
- 第四步，分批迁移aws的数据库至腾讯云。
- 第五步，迁移EMR系统至腾讯云。
- 第六步，迁移S3数据至COS。
基础环境(11月4日)
- 划分子网
- 使用ipsec打通aws和腾讯云网络
- 基础镜像设置
- 基础软件编译
- 运维基础服务两个云平台支持
基础测试(11月4日)
腾讯云环境部署代码数据库进行简单性能测试
得出结论，腾讯云cpu新区的性能对比同等配置的aws性能强很多。
初步统计(11月4日)
内网带宽峰值消耗，涉及到光纤带宽大小。
初步迁移(11月14日)
小业务测试，考虑到腾讯云北京区在希哥玛大厦，aws在酒仙桥。同城外网延迟应该很好。
- 服务代码到腾讯云，后端接口在aws，数据库在aws，灰度放量测试，测试功能，公网和vpn混合稳定性
- 如果vpn不稳定，时延不接受，则等专线或依赖接口迁移，若vpn稳定，时延可接受，业务独立迁移
- 运维考虑数据库迁移和回迁方案
- 依赖接口迁移到腾讯云，测试
迁移草案(12月4日)
基础服务迁移
支付，物流，推送，消息流，图片视频上传，zk，监控，基础java服务
需要解决的点
- 复用的库有哪些业务被调用
- memcache中有些数据需要保留，解决方式aws和Qcloud双写，Qcloud的请求现在Qcloud读mc，读不到就去aws读，然后写入到Qcloud的mc
- rabbitmq问题，pub和sub需要考虑
- zk部署两套，每个zk配置一个域名
独立线迁移
初步迁移
整体服务测试，测试业务——拼团
楚楚街
1比1部署，从库mysql，redis部署，测试方式，因为商场整体没有解耦，采取相关域名单独灰度，集体放量灰度测试，然后在这基础上，单独提高一个域名进行测试，尽可能涵盖更多的点，并且节省带宽。
大微信客
1比1部署，从库mysql，redis部署
核心业务迁移
- 独立数据库优先搬迁
- 共用数据库资源待评估
业务梳理(12月中旬)
业务梳理出业务代码中包含内网域名，内网ELB，外网ELB，内网IP地址，外网IP地址统一改成域名。
运维根据梳理出的需要添加域名的，统一通过新建ELB并新增ELB的域名解析的方式，对内网调用的通过内网DNS实现，然后在腾讯云同样搭建内网DNS。外网IP的统一使用外网域名
迁移过程中发现的问题
- 数据库跨部门复用
cdn迁移（2018年1月2日）
- CDN迁移流程梳理，运维和业务
- 运维和业务自测
- 灰度，全量进行
- 回滚方案（业务修改代码，对于商城涉及太多，只能等待运维修改CNAME，等待运营商更新缓存）
初步部署(2018年1月初)
- jenkins环境，建立迁移项目对应关系的项目，用来共享迁移进度和顺序
- 代码部署
- 开发测试
- 测试功能测试
灰度测试
- 通过CDN线路灰度的方式进行
业务迁移
- 建立checklist，并在凌晨迁移
- 数据库只读
- 业务返回页面维护
- 业务切全量
- 主从切换
- 检查数据一致性
以上步骤分批次进行
后续
- 梳理未整理到的业务和陈年老项目进行下掉
- 基础服务zabbix，elk等进行迁移
- 测试，灰度环境迁移
