如何挑选适合微服务的最佳消息队列系统？

本文共计2275个文字，预计阅读时间需要10分钟。

微服务及消息队列简史：自Peter Rodgers教授2005年在Web Services Edge会议上首次提出Micro-Web-Services一词后，IT行业逐渐从单体架构转向微服务。2009年，Netflix决定将其单体架构为微服务。

微服务及消息队列简史

自从Peter Rodgers博士2005年在Web Services Edge会议上首次提出Micro-Web-Services一词后，IT行业慢慢地从单体架构转向了微服务。

2009年，Netflix决定把其单体架构拆分为微服务。

2010年，Best Buy开始把它们的单体架构转变为微服务架构。

2011年，eBay开始推行微服务。

2001年，当时Amazon的零售网站还是个巨大的单体架构。

Rob Brigham在Amazon的re:Invent 2015会议上提出了微服务改造建议：

• 将服务端拆分成松耦合的微服务

• 隔离微服务时应该关注业务而非团队技术栈

• 成立更小单位的研发团队，专注于定义良好的服务，使他们可以更高效、更大规模的完成交付

今天，服务端基本都遵循微服务架构设计模式。然而，基于消息队列的进程间或线程间通信可以追溯到20世纪80年代初，当时使用的是UNIX的V API或其它实时操作系统内核。直到2000年代，基于网络间通讯的消息队列才诞生。

• RabbitMQ在2007.07.01发布了它的v1.0.0版本

• Kafka最初由LinkedIn开发，随后于2011年初开源

• AmazonSQS于2004年底进入测试阶段，并于2006年年中正式上市

使用同步通讯还是异步通讯

选择了微服务架构，就面临着选择服务间的通讯协议：

• 同步：HTTP，如REST、SOAP、RPC、gRPC等

• 异步：消息队列，如AMQP、Kafka、MQTT等

同步通讯更容易出错，更难调试，也更难恢复。如果不是实时性要求特别强的功能，可以考虑异步通讯。

异步通讯提供了单一、可靠的消息总线，使得调试更容易，更不容易出错，服务间数据传递更可靠也更安全。

也就是说，除非存在使用较旧编程语言的遗留服务，或者无法改造的旧基础架构，云原生时代更建议选择异步通讯。

选择了使用异步方法，就需要决定使用什么消息队列中间件和消息队列协议。

消息队列中间件

以下是截至2021年比较著名的消息队列中间件以及云服务列表：

• RabbitMQ

• Apache Qpid

• Apache Kafka

• Apache ActiveMQ

• Redis

• Eclipse OpenMQ

• JoramMQ

• Eclipse Mosquitto

• HiveMQ

• Solace PubSub+

• Google Cloud Pub/Sub

• Amazon SQS

• Amazon MQ

• IBM MQ

• Azure Event Hubs

• Azure Service Bus

消息队列协议矩阵

以下是消息队列协议比较矩阵：

注意：Headers表示具有任意数量键的dictionary或map，而attrs表示一组有限的键值对。

相似点：

• 所有协议都有队列的FIFO概念

• 所有协议都基于TCP

• 所有协议都有生产者、消费者的概念

• 所有协议都有负载（payload）与正文（body）

不同点：

• AMQP有不同的消息传递模型

• Cloud-based的消息队列具有死信队列

• 消息检索（routingkey）方法不同

• Headers和attrs的支持有限

• Redis、STOMP、MQTT的功能最不丰富，而AMQP的功能最丰富

• Cloud-based的消息队列具有一些独特的配置以及相关API。

消息队列协议详解

消息队列协议的选择实际上比消息队列中间件的选择更重要。因为如果选择一个更通用的协议，就更容易找到其他中间件作为替代。

AMQP

AMQP -Advanced Message Queue Protocol是一种基于TCP的二进制协议，已成为ISO和OASIS的标准，AMQP协议主要由RabbitMQ使用。

优点：

• 针对不同的用户场景使用不同的消息传递模型，在协议级别降低了架构的复杂性

• AMQP是ISO和OASIS标准，被广泛采用

• AMQP快速、安全，可能是消息队列协议中最成熟的

• 可以在公有云上找到对应的云产品，并且可以在云产品和自有RabbitMQ间轻松切换

• 使用classical队列或quorum队列进行队列镜像，使其易于扩展

• RabbitMQ的消息大小限制在版本3.7.0之前为2GB，在版本3.8.0中减少到128MB

缺点：

• 不向下兼容，客户端只实现协议的一个版本，版本之间升级迁移可能很耗时

• 依赖RabbitMQ许多插件可能会面临运维挑战

• 调试和监控可能存在问题

• 虽然AMQP感觉像是标准化的消息队列协议，但大多数消息队列中间件都不支持它

Apache Kafka

Apche Kafka既是消息队列中间件的名称，也是协议本身。截至2021，该协议共有12个版本，客户端可同时兼容所有版本。

Apche Kafka是一个由Apache软件基金会开发和维护的项目，用Scala和Java编写。

Apache Kafka团队选择定义自己的协议，而不是采用AMQP或STOMP。是因为他们认为协议决定了实现，因此，采用已有的协议会降低了他们创建分布式消息中间件以及进行某些优化的自由度。

优点：

• Apache Kafka的partition和replication的功能使其易于扩展

• Apache Kafka提供了一种批量发送小消息的方法，使得该协议非常高效

• Apache Kafka提供的管理API使调试变得很容易

缺点：

• Apache Kafka需要部署ZooKeeper和Kafka两部分，对于初学者而言具有一定的挑战性

• Apache Kafka协议规范不断升级变化，客户端可能很难跟上其变化，升级也可能具有挑战性

• 消息大小限制为1MB

STOMP

STOMP -Streaming Text Oriented Messaging Protocol是一种基于文本的协议，与AMQP非常相似。但它缺乏其他协议所具有的许多功能和优化。另一方面，STOMP的简单性使其更易于采用。因此，有许多客户端支持该协议，RabbitMQ也可以通过插件支持STOMP。对于一些简单的用例或快速原型，可以考虑使用STOMP。

优点：

• 简单，易于集成

• 通过插件方式支持RabbitMQ

缺点：

• 与其他协议相比，功能和优化更少

MQTT

MQTT -Message Queuing Telemetry Transport是物联网（IoT）的消息队列协议，它是ISO和OASIS标准，当前支持MQTT的最著名的中间件是Eclipse Mosquitto和HiveMQ。

优点：

• 轻量

• 双向

缺点：

• 不适用于与物联网无关的微服务

• 功能不够丰富

Redis

RESP-Redis Serialization Protocol是Redis的协议。Redis是一个基于内存的Key-Value数据库。从技术上讲，Redis不是一个消息队列中间件，但通过一些客户端手段，Redis可以用于异步消息通讯。这主要是那些喜欢使用Redis的开发者或者一些简单场景采用的手段，因此，也把Redis纳入消息中间件。

优点：

• Redis基于内存，速度相当快

• 对于已经使用Redis的人来说，基本无学习曲线

缺点：

• 消息没有持久化，有丢消息的风险
• 功能不够丰富
• 不适用于其他协议能解决的所有应用场景

云服务，如 AWS SQS

如果不想自己维护基础设施，并需要自动扩容，或者本身就在公有云上，此时，可以考虑直接使用云服务。

优点：

• 方便快捷

• 稳定，自动扩容

• 无需个人维护

缺点：

• 对于简单或轻量的业务场景 ，费用可能过高

• 客户端兼容问题依赖云厂商解决，对某些开发语言可能兼容不好

• 非客户端交互模式，如API方式可能存在性能问题

如何选择消息队列

总之，一般情况下使用AMQP - RabbitMQ或Kafka，对消息可靠性要求较高时考虑RabbitMQ，否则选择Kafka。

请勿采用STOMP，因为它没有被很好的兼容，而且没有很好的优化。

如果您在从事物联网业务，那么请使用MQTT，它适合物联网。

如果您喜欢Redis，并且无法添加其它新技术，那么可以继续使用Redis，但需要接受Redis在消息队列中的缺点。

如果您本身就在使用公有云，具备一定的用户或业务体量，对消息队列有稳定性及自动扩容的要求，并且能接受其费用，那么，选择云服务提供的消息队列。

参考总结 以上就是本文希望分享的内容，如果大家有什么问题，欢迎在文章或者公众号 - 跬步之巅留言交流。