背景
我们现在主体业务已经是部署在某云上了，但整个技术体系，还是基于传统的虚拟机去承载的，由于我们产品本身的媒体属性，导致了不可避免的会经常遇到突发流量，相比与一直比较平稳的流量，这种对服务端的考验更高，核心关注点还是在怎么保障在这种时刻用户都能得到良好的体验。
另一方面，由于云平台本身的一些不可抗力因素，不能保证百分百的高可用，怎么降低单点依赖的风险，也是我们需要重点考虑的。
经过综合性的权衡，我们决定把主体业务迁移到华为云，并且优化升级原来的架构，以便更好的支撑海量用户访问。前端机也从VM过渡到docker，迁移后的整体架构图如下
各个资源的迁移过程
1. mc迁移
现在业务上使用mc只是做临时缓存，cache miss会从存储（DB、ES等）拉一份写进去，并且业内也没有比较成熟的mc存量与增量迁移方案，所以这部分数据可以忽略，等上线前，预热一部分热点数据进去。不过使用上有一些区别，原平台使用的是服务端集群，现在是客户端集群，需要建立MC连接的时候，添加所有的服务器列表以及权重。
2. mq迁移
mq主要用来解耦业务模块，生产端生产一份数据，消费端可能有多个，迁移的话，需要先配置好资源的vhost，exechange还有queue，服务端先更新配置上线，数据写入到新资源，消费端在旧资源消费完成后，切换到新资源的消费上。
3. redis迁移
redis的迁移需要区分两个场景的数据，一个是缓存数据，可以按照mc的迁移策略忽略，另一部分是持久化数据，主要是业务上的各种计数，这部分数据要求尽量精确快速的迁移到新资源，当时考虑了两种方案
- 一种呢，是基于快照文件迁移 存量数据可以通过RDB快照，只需要原平台有备份RDB的权限，在新资源通过快照回放完成全量数据的迁移。 这种方案优点比较突出，操作简单快速，但缺点是不支持增量同步。
- 另一种呢，基于业务迁移 首先，读