常用服务产品

功能	注意要点	要求&风险
云服务器esc	ecs设备带宽与vpc网络带宽之间的关系，是否直接继承，还是要跟着设备规格单独计算
关系型数据库	备份费用计算
DTS	是否支持全量+增量的同步模式，可以实时更新任务配置，正常情况下数据延迟在秒级	任务能否支持断点续传，能否支持重试
cdn	过渡阶段，是否能配合支持按照url规则回源到不同的源站	url里面要包含日期或其他可做切分的字符串特征
oss对象存储	是否支持2次回源，回源到初始源站，并拉取到当前存储桶中
应用防火墙WAF	如果源站不是同个厂商的云服务，延迟有多大，计费、带宽是否有区别 是否支持类sql日志查询功能
云防火墙	基础组件
块存储	磁盘快照费用
负载均衡	是否支持类sql日志查询功能
中间件-es	是否支持灵活降配，是否有迁移工具支持
中间件-redis	是否支持灵活降配，是否有迁移工具支持
中间件-kafka	是否支持灵活降配 默认topic分片数是多大，是否可以自行调整
vpc网络
vpn	是否支持灵活降配
日志服务
数据传输	数据传输的流量成本

ECS

基础中的基础，不过一般差不多的服务商，其产品能力差异不大，不会有太大问题

注意要点：

做一下单点+集群的性能测试就ok了，设备的网络性吞吐性能还要特别注意，有时候性能瓶颈在流量上

关系型数据库

同样是基础中的基础，差不多的服务商，其产品能力差异不大，不会有太大问题

注意要点：

计算成本的时候要包含备份的费用，一般来说1周至少本分2次，大多数服务商最少都会要求保留7天

DTS

重中之重！！直接决定迁移的效率与成败（除非体量太小）

注意要点：

任务的稳定性与数据完整性一定要去提前测试，创建任务后一定要支持后续修改，别只能重新建任务

最好有支持校验数据是否一致的功能，否则只能靠自己写python了

CDN与对象存储

注意要点:

尽量避免一刀切，分阶段迁移，每次迁移完校验文件是否完整（可以通过自动化脚本或工具支持）

cdn	过渡阶段，是否能配合支持按照url规则回源到不同的源站
oss对象存储	是否支持2次回源，回源到初始源站，并拉取到当前存储桶中

这2块是为了能实现逐步切换，避免一刀切带来的实施成本与风险

我们迁移的初期就是依靠服务商技术在后台配置日期特征，将某些特定年份及月份的urlCDN访问切换到新的源站上，这样可以先逐步把历史文件先迁移过去；

随后对象存储产品支持了当本地存储桶不存在要访问的文件时，可以配置2次回源的源站，去我们老的存储桶中拉取，自此实现了对象存储的无缝衔接。

PS：对于规模较较大的平台如果不能提供类似支持能力的服务商，不建议选用，因为CDN与对象关系紧密，通常会产生连带问题，如果不能支持灵活的回源配置，在迁移过程中的风险会大大增加

应用防火墙WAF

平台安全的重中之重！！一般来说都会选与自己云服务器相同厂商的产品，不过功能完善程度还是最终决定因素

注意要点:

首推阿里云的产品，成熟可靠，易用性，日志查询都非常方便，缺点就一个：贵！

实测阿里云waf回源其他云服务商的源站，延迟+30ms，还可以接受

同时阿里云企业版100M带宽，如果跨服务商回源就只有30M，需要额外购买带宽

类似sql日志查询能力真的对后续运维至关重要，能大大缩短定位解决问题的周期

云防火墙

基础安全组件，各家都差不多，没太多可说的

块存储

基本都是挂在ECS上的云盘

注意要点:

这里面要注意快照的费用，磁盘备份策略直接决定了快照的规模

负载均衡

基础中的基础，没啥太多要说

注意要点:

日志功能的完善度注意一下，但不是必须的，elk可以解决

日志服务

功能没啥多说的，看看价格合不合适就行了

中间件

ES

功能没啥多说的，看看价格合不合适，能否支持灵活升降配

此外注意一下单topic默认使用的分片数

Kafka

功能没啥多说的，看看价格合不合适，能否支持灵活升降配

redis

功能没啥多说的，看看价格合不合适，能否支持灵活升降配

压测

除了常规使用jmeter进行单点压测与集群压测外，可以用goreplay进行流量复制压测

网上有很多教程就不重复了，在实际使用中发现，按100%流量回访实际并发压力要远低于真实情况约为1/10（排除压力设备的性能问题），后加到1000%

迁移准备

梳理现有情况落实文档

资源对照表

为了便于查找替换涉及的资源地址，用户、密码（数据库，redis，ES，kafka，对象存储）

项目依赖资源明细

整理一份迁移涉及项目依赖中间件的明细，用于评估与检查对应系统的配置化改造是否完整，该系统依赖的资源是否已就绪，可以迁移

定时任务明细

定时任务是业务的重要组成部分，也是迁移很容易出问题的地方，很有必要进行一次梳理，明确：

任务依赖系统，执行时间，执行业务

配置化改造

一套代码可支持多机房部署

要把本地的配置文件放到配置中心中（apollo，nacos），确保同一套代码可以直接部署在不同的云服务，从各云服务中的配置中心拉取配置来是适配中间件与资源

尽可能减少跨机房调用

除非预算十分充裕，一般来说不会拉专线，因此在迁移方案要尽量避免跨机房的调用，确保交互在本地机房内

必要的双写改造

数据同步可以依靠DTS来实现

redis一般不需要实时同步，做全量即可

kafka正常不需要同步数据

ES正常需要做增量同步（因为搜索结果数据是持续发生变化，如果只能做全量同步，在切换时会为了保证2端数据一致会非常麻烦），目前没有发现太好用的工具，在实施过程中，我们是开发了双写方案，通过异步的方式进行索引更新同步

切换

切换时不推荐用改 DNS cname绑定来做，因为每次操作都有延时，会带来不确定的风险

如果用了WAF的话，首先考虑通过在WAF中变更回源地址来进行切换，可做到实时切换（阿里云WAF支持泛域名配置，切换操作比较方便）

如果没有WAF，还可以在云服务的clb上，配置服务器组+权重 来控制流量的分发（这种方案也会有额外流量成本，因为分发还是走的公网流量）

上线计划

编制一份上线计划，细化到每一个操作步骤、操作人、时间

这是我们脱敏后的计划

步骤	操作内容	负责人/团队	完成情况
配置化改造
部署新环境
ES集群双写上线
数据库全量复制
新环境功能测试
压力测试
流量复制测试
升级阿里云waf流量配置
停止新环境调度
启动数据库增量同步
redis复制	每天做1次
复制ES	双写 + 每天做1次滴兜底
检查配置中心内容
切换阶段
停止老环境调度
更改WAF回源
停止增量数据复制
启动新环境调度
检查调度任务状态	需要加日志辅助
检查nginx日志（并行）
检查前端系统日志（并行）
检查服务端系统日志（并行）
开始回归测试（并行）
切换完成

切换当天遇到的问题

按上面的步骤坐下来，基本没出大问题，当总会有漏网之鱼，遇到问题别慌，别急着撸代码，大概率是配置相关问题

我们在切换阶段发现的主要问题：

个别系统redis配置的访问密码不正确

因为还有一部分系统遗留在老环境上，再配置nginx跳转的时候有一些问题导致未能正常访问到老服务上

当天没有发现改代码需要解决的问题，整个切换从23:50 - 次日凌晨3:00