微服务使用异步通信时，通常会使用消息代理。代理保证了不同微服务之间可靠稳定的通信，消息在系统内部进行管理和监控，消息不丢失。您可以从大小和数据功能各不相同的多个消息代理中进行选择。这篇博文将比较三个最流行的代理：RabbitMQ、Kafka和Redis。但首先，让我们了解微服务通信。微服务通信：同步和异步微服务之间的通信有两种常见的方式：同步和异步。在同步通信中，调用方在发送下一条消息之前等待响应，该消息作为HTTP之上的REST协议运行。相反，在异步通信中，消息无需等待响应即可发送。这适用于分布式系统，其中通常需要消息代理来管理消息。您选择的通信类型应考虑不同的参数，例如如何构建微服务、要设置的基础设施、延迟、规模、依赖关系和通信目的。异步通信的设置可能更复杂，并且需要向堆栈中添加更多组件，但对微服务使用异步通信的优势胜过劣势。异步通信的优势首先，异步通信根据定义是非阻塞的。它还支持比同步操作更好的缩放。第三，在微服务崩溃的情况下，异步通信机制提供了各种恢复技术，通常可以更好地处理与崩溃相关的错误。此外，当使用代理而不是REST协议时，接收通信的服务实际上不需要相互了解。甚至可以在旧服务运行很久之后引入新服务，即更好的解耦服务。最后，当你选择异步操作时，你可以提高你在未来创建中心发现、监控、负载平衡甚至策略执行者的能力。这将为您的代码和系统构建提供灵活性、可扩展性和更多功能。选择正确的消息代理异步通信通常通过消息代理进行管理。还有其他的方法，比如aysncio，但是比较稀缺和有限。在选择执行异步操作的broker时，应考虑以下几点：1.BrokerScale——系统中每秒发送的消息数。2.数据持久性——恢复消息的能力。3.消费者能力——经纪人是否能够管理一对一和/或一对多消费者。一对一：一对多：我们查看了最新和最好的服务，以找出在这三个类别中哪一个提供商是最强大的。比较不同的消息代理RabbitMQ(AMQP)规模：根据配置和资源，这里的速度大约是每秒50K消息。持久性：支持持久性和瞬态消息。一对一消费者与一对多消费者：两者都有。RabbitMQ于2007年发布，是最早创建的通用消息代理之一。它是一个开源软件，实现了高级消息队列协议(AMQP)，通过点对点和发布子方法传递消息。它旨在支持复杂的路由逻辑。有一些托管服务允许您将其用作SaaS，但它本身并不是主要云提供商堆栈的一部分。RabbitMQ支持所有主要语言，包括Python、Java、.NET、PHP、Ruby、JavaScript、Go、Swift等。持久模式下可能存在一些性能问题。Kafka规模：每秒高达数百万条消息。坚持：是的。一对一消费者与一对多消费者：只有一对多（乍一看似乎很奇怪，对吧？！）。Kafka于2011年由Linkedin创建，用于处理高吞吐量、低延迟的处理。作为一个分布式流媒体平台，Kafka复制了一个发布-订阅服务。它提供数据持久性并存储记录流，使其能够交换高质量的消息。Kafka在Azure、AWS和Confluent上管理SaaS。他们既是Kafka项目的创造者，也是主要贡献者。Kafka支持所有主要语言，包括Python、Java、C/C++、Clojure、.NET、PHP、Ruby、JavaScript、Go、Swift等。Redis规模：每秒最多100万条消息。持久性：基本上不是——它是一个内存数据存储。一对一消费者与一对多消费者：两者都有。Redis与其他消息代理略有不同。Redis的核心是内存中数据存储，可用作高性能键值存储或消息代理。另一个区别是Redis没有持久性，而是将其内存转储到磁盘/数据库。它也非常适合实时数据处理。Redis本来就不是一对一和一对多的。但是，自从Redis5.0引入了pub-sub之后，功能得到了提升，一对多成为了现实的选择。每个用例的消息代理我们介绍了RabbitMQ、Kafka和Redis的一些特性。这三种动物都属于这一类，但如上所述，它们的运作方式截然不同。以下是我们根据不同用例对正确的MessageBroker的建议。短消息：RedisRedis的内存数据库几乎完全适合不需要持久化的短消息用例。因为它提供了极快的服务和内存中功能，Redis非常适合保留时间短的消息，在这种情况下，持久性并不重要，您可以容忍一些丢失。随着Redis流在5.0中的发布，它也是一对多用例的候选者，由于限制和旧的发布-订阅功能，这是绝对需要的。海量数据：KafkaKafka是一个高吞吐量的分布式队列，用于长时间存储大量数据。Kafka非常适合需要持久性的一对多用例。复杂路由：RabbitMQRabbitMQ是一个较老但成熟的代理，具有许多支持复杂路由的特性和功能。当要求的速率不高时（超过数万个msg/s），它甚至支持复杂的路由通信。考虑您的软件堆栈当然，最后要考虑的是您当前的软件堆栈。如果您正在寻找一个相对简单的集成过程，并且不想在您的堆栈中维护不同的代理，您可能更倾向于使用您的堆栈已经支持的代理。例如，如果您在RabbitMQ之上的系统中使用Celery作为任务队列，您将有动力使用RabbitMQ或Redis，而不是Kafka，后者不受支持并且需要一些重写。
