用于服务间通信的消息代理模式
简化微服务之间的消息传递
微服务依赖于服务间通信来共享事件、状态和数据,以及保持隔离和解耦。许多开发人员为服务间通信实现了异步事件驱动的发布/订阅消息代理 ,但这很复杂。
这里有一个更好的方法:Redis Streams 既充当原生日志数据结构,又充当通信通道,可以在不需要立即响应的情况下发布事件。它易于部署,支持消息持久化,并通过消费者组提供可扩展性。
Redis Stream 作为消息代理的工作原理
微服务域将事件发布到其自己的流中,其名称反映了事件主题。
每个事件都是一个流条目。事件时间戳充当条目 ID。
其他微服务订阅特定的事件流。
订阅者确认事件已成功处理并记住它处理的最后一个条目 ID,以便轻松地从故障或断开连接中恢复。
Redis Streams 检查未处理消息的状态,并在指定的时间段后将事件重新分配给另一个订阅者。
了解 Redis Enterprise 如何解决微服务架构中的可扩展性、延迟和弹性挑战
观看演示
何时使用事件驱动的消息代理
异步通信 用例,其中应用程序中的所有服务都不需要存在才能处理消息;或者某些服务只需要来自另一个服务的子集信息。
您需要可靠地存储和传输瞬态数据,作为不可变的、追加式的、带时间戳的事件序列。
需要一对多通信,但使用消息队列效率低下,需要所有接收服务的地址和状态。
消息需要低延迟和持久性、确认,并且可以轻松处理故障情况。
Redis Enterprise 解决您的挑战
微服务问题 解决方案 很难保持微服务的隔离,同时又要通信状态、事件和数据 Redis Streams 是一个轻量级的异步消息代理,它既是不可变的时间排序日志数据结构,又是事件存储。 Redis 易于部署,具有开箱即用的分区、复制、持久性和可配置的消息传递保证。 扩展和维护微服务通信很困难,尤其是在流量高峰期间 Redis Streams 提供高效的写入/读取操作,以提高整体应用程序性能 。 它可以每秒捕获和处理数百万个数据点,延迟低于毫秒级 。 它包括高级消费者组 功能,使您能够将消息流拆分到多个客户端,以加快处理速度。 使用 Kafka 作为消息代理的复杂性和开发成本 Redis Streams 的轻量级实现只需要一对键值。这比设置 Kafka 主题的管理开销要简单得多。 Redis Enterprise Kubernetes 运算符 使得 Redis Enterprise 集群部署自动化。 Redis Streams 和缓存位于同一个统一的多租户数据平台上。无需额外许可证。了解更多
为什么要使用 Redis Enterprise
轻量级的设计和实现可以缩短上市时间。您可以在几分钟内开始原型设计。
即使在高强度消息负载下,也能提高微服务的可扩展性和响应能力。
99.999% 的正常运行时间 SLA 和弹性(主动-主动地理分布)有助于防止应用程序停机。
应用程序可以轻松处理重试、故障情况以及添加新的订阅服务。
更简单的集成,支持各种平台和编程语言,以及云中的本地和托管服务。
了解更多
常见问题解答
什么是消息代理?
消息代理是促进应用程序、系统和服务之间消息交换的软件。在微服务架构中,服务可以使用消息代理相互通信,即使它们使用不同的技术或部署在不同的平台上。
同步和异步通信模式之间的区别是什么?
同步通信意味着通道中的所有参与者,发送者和接收者,都需要同时处于活动状态才能进行通信。一个简单的例子是服务 A 和服务 B 进行直接远程过程调用 (RPC),通过从服务 A 调用服务 B 的 HTTP REST 端点来实现。但是,如果服务 B 离线,服务 A 将无法与 B 通信,因此 A 需要实现内部故障恢复过程。异步意味着即使并非所有参与者都同时在场,通信仍然可以发生。例如,服务 A 不等待来自发送者 B 的响应。
服务间通信的一些常用方法是什么?
API、任务队列、消息队列 (RabbitMQ)、事件流 (Kafka) 和消息代理。
什么是无代理和代理通信?
在无代理通信中,所有参与者都直接连接。代理通信意味着所有参与者通过消息代理连接到同一服务,消息代理充当,正如其名称所暗示的那样,一个集中式代理来实现消息路由机制。消息代理可以与同步和异步通信一起工作,但通常与异步通信相关联。
什么是事件驱动架构 (EDA)?
事件驱动架构使用事件来触发和在解耦的服务之间进行通信,在使用微服务构建的现代应用程序中很常见。事件是状态变化或更新,例如在电子商务网站上订购商品会导致库存管理系统将库存值减少一个。事件驱动架构非常适合需要以极低的延迟摄取和处理大量数据的实时应用程序,或者当不同的子系统或微服务需要对同一事件数据执行不同类型的处理时。EDA 可以使用发布/订阅 (pub/sub) 模型或事件流模型。