技术选型指南：消息中间件

封面

前言

1986 年计算机科学家Red Brooks 发表了一篇论文《No Sliver Bullet--Essence and Accidens of Software Engineering》（《没有银弹--软件工程的本质性与偶然性》），后来收录在《人月神话》中。

没有银弹这个观点，沿用至今，依然十分奏效。无论现阶段流行的多么优秀的技术，一旦应用到生产商总是会有各种水土不服，花了大价钱改造不如原来的版本。

换句话说，即在软件工程中没有最好的，只有最适合的。对技术框架要一定的决策能力。

下面就以消息中间件（MQ）浅谈一下个人见解。

一款技术框架的选择基准

有一些比较通用的原则，比如开源协议、社区活跃度、技术团队的能力等。这些无关于技术细节，却是收割要考虑的元素。

开源协议

有关细节在笔者此篇文章有介绍《加入开源的正确姿势》这里便不再展开。

这里再补充一点，比如闭源项目，一般通过厂商提供线上或私有化服务，包含运维等服务。如果技术团队能力有限，选择云厂商提供的服务也不失为一种选择。

社区活跃

一个框架在使用过程中，难免会遇到不同的问题。很多可以在官方文档或者issue下可以得到解决，但部分需要去求助于社区。

活跃是一个比较抽象的词，量化为具体指标，即代码更新频率，issue 回答的数量、技术写作社区平台的讨论度等。

消息中间件的基准

具体到某一款产品来说，就会有更细节的对比。比如QPS级别，支持的协议，编写语言等。

比如对于业务系统来说，要求消息可靠，不丢消息。

常见名词解释

消息（Message）：通信交互的载体，是按照编码格式封装的传输数据。

主题（Topic）：表示一类消息的集合，是一个逻辑概念，可用于区分不同的业务场景。

队列（Queue）：主题由一个或多个队列组成，当消息发往某一个主题，需要选择一个队列。

消费组（Consume Group）：消费组用于订阅主题消息，可以订阅多个主题。一个消费组包含多个消费者。

消费者（Consume）：可以是同一个进程中的多个消费组线程、多个消费组进程、部署的多个节点等。

消息中间件横评

下面是通过了以上标准的一些开源产品对比。

RabbitMQ

比较老牌的消息中间件，由 Erlang 语言开发，目前依旧是很多公司的选择。

上手比较简单。当第一次学习中间件的各种概念，原理时，是一个很好的例子。文档也比较完善，一键式启动。

但由于万级的吞吐量，限制了他的场景。

RocketMQ

RocketMQ是国内阿里巴巴开源的，相传是 Java 版本的Kafka。具有国内开源框架的特点，例如中文文档，和国内其他产品生态集成度高等。

性能上，吞吐量达到了十万级别。各个方面比较水桶，但对于非Java 的生态支持较弱。

Kafka

当牺牲了一定的消息可达性，换取了极高的性能。吞吐量达到单机最强，百万级别，Kafka 应运而生。

根据该特性，框架的主要场景也发生了变化，不再是严格业务中，而是处理好凉数据流，比如日志、指标等。

简单对比

题外话：云原生时代的去留

在学习消息中间件时，听到一个概念，云原生 infra 设计。拋开繁杂的概念，简单来说，对于弹性扩缩容场景，传统的RabbitMQ、RocketMQ出现了弊端，或者说不适用。

RocketMQ 对此，出了 5.x 版本。

架构升级

而 Kafka 由于天然的设计，对于云原生场景依然适合。

还有一款逐渐讨论声比较小，但却成为了Apache顶级项目的Plusar。天然就是为云原生场景设计，分布式场景中，和 Kafka 的性能掰掰手腕。