消息队列备选架构选择，你选择哪个？
备选架构1 - 开源方案评估
kafka：
人力成本：
测试代表倾向于引入 Kafka，因为 Kafka 比较成熟，无须太多测试投入。
中间件团队部分研发人员也支持使用 Kafka，因为使用 Kafka 能节省大量的开发投入。
可维护性：
Kafka 是 Scala 语言编写的，运维团队没有维护 Scala 语言开发的系统的经验，出问题后很难快速处理。
运维团队已经有一套成熟的运维体系，包括部署、监控、应急等，使用 Kafka 无法融入这套体系，需要单独投入运维人力。
业务场景：
部分人员认为 Kafka 可能并不适合我们的业务场景，Kafka 是大容量的日志消息传输，而我们的消息队列是为了业务数据的可靠传输。
学习成本：
业务主管倾向于采用 Kafka 方案，因为 Kafka 已经比较成熟，各个业务团队或多或少都了解过 Kafka
备选架构2 - 自研集群 + MySQL 存储
图片
【简单描述】
1. JAVA 语言编写消息队列服务器；
2. 消息存储采用 MySQL；
3. SDK 轮询服务器进行消息写入；
4. SDK 轮询服务器进行消息读取；
5. MySQL 双机保证消息尽量不丢；
6. 使用.NETty 自定义消息格式，并且支持HTTP 接口。
成本：
中间件团队的研发人员认为这个方案比较简单，实现成本低，但测试代表认为这个方案测试人力投入较大。运维团队认为这个方案的硬件成本比较高，一个数据分组就需要4台机器（2台服务器 + 2台数据库）。
可维护性：
方案可以融入到现有的运维体系中，而且使用 MySQL 存储数据，可靠性有保证，运维团队也有丰富的 MySQL 运维经验。
业务主管对这个方案既不肯定也不否定，因为开发和运维都不是业务团队，对业务团队来说，只要保证消息队列系统稳定和可靠即可。
业务场景：
可以为业务场景定制开发各种特性，例如权限控制、消费速度预警等。
性能：
部分研发人员对于这个方案的性能持怀疑态度，毕竟使用 MySQL 来
存储消息数据，性能肯定不如使用文件系统。
其它：
是否会影响中间件团队的技术声誉，毕竟用 MySQL 来做消息队列，看起来比较“土”、比较另类。
备选架构3 - 自研集群 + 自研存储
图片
1. 模拟 Kafka 的原理，用 Java 语言实现，也可以用 LSM 数据结构来存储消息。
2. 可以保证高可用高性能。
3. 加上可维护性的各种能力，嵌入到已有的运维体系。
备选架构3评估
成本：
要做到稳定可靠的存储系统，需要较长时间迭代，投入成本大。
自研存储系统的测试难度高，投入也很大。
可维护性：
可以融入到现有的运维体系中，但自研存储系统需要较长时间才能成熟，增大了运维风险和投入。
业务场景：
可以为业务场景定制开发各种特性，例如权限控制、消费速度预警等。
性能：
性能上相比 MySQL 要高，但初步评估并不能高太多。
可用性：
从历史经验来看，新系统上线肯定有bug，而存储系统出 bug 是最严重的，一旦出 bug 导致大量消息丢失，影响会很严重。运维代表不太赞成这个方案，因为运维之前遇到过几次类似的存储系统故障导致数据丢失的问题，损失惨重。
团队技术实力：
方案复杂度太高，按照目前的团队人力和技术实力，要做到稳定可靠的存储系统，有较大风险。
运维团队并不相信目前的中间件团队的技术实力足以支撑自己研发一个存储系统。
备选架构4 - 直接用阿里的 MetaQ
RocketMQ
成本：
低，接入即可。
可维护性：
UC 机房和阿里机房隔离，打通困难，如果在 UC 机房部署阿里的系统，部署、维护、升级的人力成本太高。
UC 机房3年内估计不会切换阿里机房。
业务场景：
可以为业务场景定制开发各种特性，例如权限控制、消费速度预警等。
性能：
性能上和 Kafka 基本持平。
可用性已经上线运行，支撑阿里业务，久经考验。
