常用服务产品
| 功能 |
注意要点 |
要求&风险 |
| 云服务器esc |
ecs设备带宽与vpc网络带宽之间的关系，是否直接继承，还是要跟着设备规格单独计算 |
|
| 关系型数据库 |
备份费用计算 |
|
| DTS
扫描二维码关注公众号，回复：
15651931 查看本文章
|
是否支持全量+增量的同步模式，可以实时更新任务配置，正常情况下数据延迟在秒级 |
任务能否支持断点续传，能否支持重试 |
| 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