带有消息代理的事件驱动微服务(例如 Kafka)与反应式编程(RxJava、Project Reactor)以及改进的协议(RSocket)

cod*_*ent 5 event-driven apache-kafka project-reactor microservices rsocket

我们都同意,通过 HTTP 调用通信微服务的常用请求-响应方式会导致它们之间的耦合。这使我们采用了事件驱动的方法,其中服务发布一些其他服务将对其做出反应的事件。为此,我们可以使用一些中间件,可以是来自 AMQ、RabbitMQ、Kafka 等的任何东西。

然而,反应式编程社区也确实创建了一些优秀的项目,例如 Project Reactor 或 RxJava,它们将 HTTP 通信转换为伪消息驱动的解决方案。再者,随着RSocket等协议的到来,该模型也到达了TCP/IP应用层。

  • RSocket/Reactive 微服务真的可以被认为是事件驱动的解决方案吗?它们不只是提高传统请求-响应系统性能的一种方式吗?

  • 换一种方式说:那些 Rsocket+Reactor 微服务不是仍然像以前基于 HTTP 的微服务一样完全耦合吗?

  • 在哪些场景中更推荐它们中的每一个?

Mic*_*rry 10

这里有很多东西要拆包,很抱歉篇幅过长。

你的问题标题描绘了一个错误的二分法。这两者并不是相互竞争的想法,实际上恰恰相反,以至于反应式 Kafka是一个东西。

然而,反应式编程社区也确实创建了一些优秀的项目,例如 Project Reactor 或 RxJava,它们将 HTTP 通信转换为伪消息驱动的解决方案。

Java 中的响应式库当然非常适合消息驱动的解决方案,但它们几乎可以用于任何事情(并且可以说通常用于它们并不总是最适合的情况!)

RSocket/Reactive 微服务真的可以被认为是事件驱动的解决方案吗?

Rsocket 和响应式微服务是两个不同的东西;虽然它们可以很好地一起玩并且经常一起使用,但它们并不是完全相同的。RSocket 对于初学者来说更新很多,所以大多数反应式微服务可能已经没有使用它。

响应式微服务,或以响应式方式编写的微服务,主要与它们在内部编写的方式有关。作为反应式,后端是非阻塞的,因此它们可以说更有效 - 特别是在需要通过长期连接发送数据流的情况下。非反应式服务必须在整个时间内保持一个单独的线程打开以管理该连接,而反应式服务可以简单地处于空闲状态,除非正在主动发送消息。

响应式微服务当然是内部事件驱动的。然而,这并没有说明反应式微服务可能用于通信的方式。它可以使用 RSocket、普通 HTTP、MQTT - 你不能仅仅基于这个协议来保证它正在使用什么。

然而,RSocket是一种协议,旨在与反应式服务特别好地配合,在多种传输上工作,并且(作为二进制协议)效率更高。这导致您的下一点:

它们不只是提高传统请求-响应系统性能的一种方式吗?

RSocket当然可以。您可以将它用作传统的请求/响应系统,并获得更高的性能,而其他一切都保持“经典”。但是,它也支持数据流(单向和双向)以及协议级别的即发即弃语义和可恢复流,因此具有特性优势和性能优势。

这可能是一些混淆的根源,因为(没有 RSocket)人们可能会选择使用中间件纯粹是因为它可以更容易地管理这些流(而不是专门解耦任何东西。)在这种情况下,是的,中间件不会不需要。

在传输层之上工作,RSocket 也不关心它在哪里使用,或者通过它发送什么 - 所以它在通过 TCP 的服务器到服务器环境中运行就像在通过 websocket 的双向服务器到客户端环境中一样快乐.

那些 Rsocket+Reactor 微服务不是仍然像以前基于 HTTP 的微服务一样耦合吗?

是的,它们仍然是耦合的——这不是 Rsocket 试图解决的问题。这是一个协议,而不是中间件。例如,Kafka 可以稍后在本地支持 Rsocket。(我目前看不到任何迹象,但从技术上讲,没有什么可以阻止它。)

在哪些场景中更推荐它们中的每一个?

如果您使用中间件的唯一原因是轻松生成和管理数据流(而不是受到请求/响应的约束),那么 Rsocket 与反应库的结合现在可以说满足了协议层的这些标准。

但是,如果您将中间件用于解耦目的,那么您几乎肯定会希望继续使用它。但是,继续使用上述中间件当然不会阻止您在实现中使用反应式库和/或 Rsocket。

  • @codependent 反应式应用程序 *可能* 非常适合这种情况 - 但对于使用 RabbitMQ / Kafka / 其他任何中间件来说,它们不会是一个很好的 *替代品,恕我直言。我怀疑随着时间的推移,我们会看到更多的反应式应用程序,但我非常怀疑这些应用程序将“取代”中间件,更有可能补充它们。 (3认同)
  • 嗨迈克尔,首先感谢您花时间写下如此详细的答案。我完全同意你所说的一切。我的疑虑更多地与反应式框架(Spring Webflux+Project Reactor)如何用于解耦微服务与使用 Kafka 之类的框架有关。当前有一种“所有事件”趋势,我们希望通过消息传递来隔离有界上下文。在这种情况下,正如您所说,反应式应用程序不太适合。 (2认同)

小智 7

RSocket 的目的是提供一个应用程序到应用程序的通信协议,该协议更可能充当对等点之间的通信。HTTP 是为人机(客户端-服务器)通信而设计的。即使是 HTTP2 或传入的 3 也不会改变这个观点。两种协议之间的主要区别之一是双向流。所以不,RSocket 不仅仅是试图提高请求响应性能。

Kafka 和反应式流之间的一个关键区别是基础设施成本的观点。Kafka 将缓冲所有数据,而反应流将使用背压来协调发送者和接收者。RSocket 只是将反应流扩展到网络协议级别。基本上它是第 6 层端到端的 TCP 滑动窗口。