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

Question

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

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

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

换一种说法:那些 Rsocket+Reactor 微服务不仍然像以前基于 HTTP 的微服务那样耦合吗？

在哪些场景下更推荐它们？

Answer 1

这里有很多东西要解压，很抱歉篇幅太长。
您的问题标题正在描绘错误的二分法。两者不是相互竞争的想法，实际上恰恰相反，以至于 reactive Kafka是一件事。

However, it's also true that the reactive programming community has created some excellent projects, such as Project Reactor or RxJava that kind of turn HTTP communications into a pseudo-message-driven solution.

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

Can RSocket/Reactive microservices be actually considered event-driven solutions?

Rsocket 和响应式(Reactive)微服务是两个不同的东西；虽然它们一起玩得很好并且经常一起使用，但它们并不是一回事。 RSocket 对于初学者来说要更新很多，因此大多数响应式(Reactive)微服务可能已经没有使用它。
响应式(Reactive)微服务 ，或以 react 方式编写的微服务，主要与它们在内部编写的方式有关。作为响应式(Reactive)，后端是非阻塞的，因此可以说它们更有效——尤其是在需要通过长期连接发送数据流的情况下。非响应式(Reactive)服务必须在整个时间内保持一个单独的线程打开以管理该连接，而响应式(Reactive)服务可以简单地处于空闲状态，除非正在主动发送消息。
响应式(Reactive)微服务在内部肯定是事件驱动的。但是，这并没有说明响应式(Reactive)微服务可以用来进行通信的方式。它可以使用 RSocket、纯 HTTP、MQTT——你不能仅仅基于这个协议(protocol)就不能保证它正在使用什么。
RSocket 然而，它是一种协议(protocol)，旨在与响应式(Reactive)服务配合得特别好，在多种传输上工作，并且(作为二进制协议(protocol))更有效。这导致您的下一点:

Aren't they just a way of improving the performance of the traditional request-response systems?

RSocket当然可以。您可以将它用作传统的请求/响应系统并获得改进的性能，而其他一切都保持“经典”。但是，它还支持数据流(单向和双向)以及协议(protocol)级别的即发即弃语义和可恢复流，因此具有功能优势和性能优势。
这可能是一些困惑的根源，因为(没有 RSocket)人们可能会选择使用中间件纯粹是因为它更容易管理这些流(而不是专门解耦任何东西。)在这种情况下，是的，中间件不会不需要。
在传输层之上工作，RSocket 也不关心它在哪里使用，或者通过它发送什么 - 因此它在通过 TCP 的服务器到服务器环境中运行就像在通过 websocket 的双向服务器到客户端环境中一样快乐.

aren't those Rsocket+Reactor microservices still coupled exactly as HTTP based ones used to be?

是的，它们仍然是耦合的——这不是 Rsocket 试图解决的问题。这是一个协议(protocol)，它不是中间件。例如，Kafka 可以稍后原生支持 Rsocket。 (目前我看不出有迹象表明它会这样做，但从技术上讲，没有什么可以阻止它。)

In which scenarios is each of them more recommended?

如果您使用中间件的唯一原因是轻松生成和管理数据流(而不是受请求/响应的约束)，那么 Rsocket 与 react 库相结合现在可以说在协议(protocol)层满足这些标准。
但是，如果您将中间件用于解耦目的，那么您几乎肯定会继续使用它。但是，继续使用上述中间件当然不会阻止您在实现中使用响应式库和/或 Rsocket。