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