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

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

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

标签： apache-kafkamicroservicesproject-reactorevent-drivenrsocket

这里有很多东西要解压，很抱歉篇幅太长。

您的问题标题正在描绘错误的二分法。这两者并不是相互竞争的想法，实际上恰恰相反，以至于反应式卡夫卡是一件事。

然而，反应式编程社区也确实创建了一些优秀的项目，例如 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。