题外话：
笔者就职于某上市游戏发行公司，主导整个发行业务线从双 IDC 到腾讯云的搬迁。在此过程中踩了不少坑，便以文章的形式记录下来。
如有错漏之处，敬请指正。
我先简单介绍下我自己：
我是业务开发出身，负责渠道登录/支付业务，熟悉前端，研究后台开发框架后，逐步往运维方向摸索。
业务除了登录/支付业务，也做过风控系统、聊天监控系统，主要是一些防刷保护、敏感词判别、垃圾信息过滤等等。
本系列篇幅较长，共有 7 篇文章，本文是第 6 篇。文章列表：
某上市游戏公司从 IDC 上腾讯云的落地经验（1）——上云必要性与方案设计
某上市游戏公司从 IDC 上腾讯云的落地经验（2）——方案实施之接入层上云
某上市游戏公司从 IDC 上腾讯云的落地经验（3）——方案实施之应用层上云
某上市游戏公司从 IDC 上腾讯云的落地经验（4）——方案实施之缓存层上云
某上市游戏公司从 IDC 上腾讯云的落地经验（5）——方案实施之数据层上云
某上市游戏公司从 IDC 上腾讯云的落地经验（6）——方案实施之中间件上云
某上市游戏公司从 IDC 上腾讯云的落地经验（7）——总结与回顾
中间件上云
中间件这块，我们的 Kafka 没有搬迁，属于大数据业务，目前依然在 IDC 机房。
Elasticsearch 是其他同事跟进，应该也是有同步工具并做 DNS 切换，业务无损。
而 RabbitMQ 这块是我负责上云的。我对它真的是又爱又恨——
- 爱：RabbitMQ 非常稳定，几乎不需要运维，跑了很久基本不出问题，PHP / Go 都非常友好，用起来比较方便；具备完善的 API 接口和管理界面，方便自己编写脚本实现某些操作的自动化
- 恨：性能堪忧，腾讯云的 CVM 自建 32 核 64 G内存 HDD * 2 台实例 + 4 层负载均衡，队列开启持久化吞吐量大概在 3 万消息每秒（主备模式）；镜像模式下，单队列没有水平扩展的能力，即使关闭持久化，依然存在硬件上的性能瓶颈。
众所周知，RabbitMQ 支持主备模式、镜像队列两种主流的用法。
这两种模式的优缺点如下：
主备模式：架构简单，但节点故障时非常难受，需要手工切换灾备节点（队列元数据需要声明才行，不然会丢数据），一般业务会开启持久化，不做切换时取决于节点何时恢复，不具备高可用的能力。
镜像模式：队列双副本 + 关闭持久化，同样配置吞吐量在 6 万消息每秒，但不具备水平扩展的能力，理论上换 SSD 磁盘会更快，但确实没办法再快了，和 Kafka 没法比。
