具有消息代理（例如 Kafka）的事件驱动微服务与反应式编程（RxJava、Project Reactor）以及改进的协议（RSocket）
Event driven microservices with message brokers (e.g. Kafka) vs reactive programming (RxJava, Project Reactor) plus improved protocols (RSocket)
我们都同意，通过 HTTP 调用通信微服务的通常请求-响应方式会导致它们之间的耦合。这将我们带到了事件驱动的方法，在这种方法中，服务发布一些其他服务将对其做出反应的事件。为此，我们可以使用一些中间件，可以是来自 AMQ、RabbitMQ、Kafka 等的任何东西。
然而，反应式编程社区也确实创建了一些优秀的项目，例如 Project Reactor 或 RxJava，它们将 HTTP 通信转变为伪消息驱动的解决方案。此外，随着RSocket等协议的到来，该模型也到达了TCP/IP应用层。
RSocket/Reactive 微服务实际上可以被视为事件驱动的解决方案吗？它们不就是提高传统请求-响应系统性能的一种方式吗？
换句话说：那些 Rsocket+Reactor 微服务不是仍然像过去基于 HTTP 的微服务那样耦合吗？
它们分别在哪些场景下比较推荐？
这里有很多可以解压，抱歉篇幅太长了。
你的问题标题描绘了一个错误的二分法。两者不是相互竞争的想法，实际上恰恰相反，以至于 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 中的响应式库当然非常适合消息驱动的解决方案，但它们几乎可以用于任何事情（并且可以说经常用于它们并不总是最好的情况适合！）
Can RSocket/Reactive microservices be actually considered event-driven solutions?
Rsocket 和响应式微服务是两个不同的东西；虽然它们一起玩得很好并且经常一起使用，但它们并不相同。 RSocket 对于初学者来说要新得多，所以大多数响应式微服务可能已经没有使用它了。
反应式微服务，或以反应方式编写的微服务，主要与它们在内部编写的方式有关。作为反应式，后端是 non-blocking，因此可以说它们更高效 - 特别是在需要在 long-term 连接上发送数据流的情况下。 Non-reactive 服务必须在整个时间内保持一个单独的线程打开以管理该连接，而反应式服务可以简单地处于空闲状态，除非正在主动发送消息。
反应式微服务肯定是 event-driven 内部的。然而，这并没有说明反应式微服务可能用于通信的方式。它可以使用 RSocket、纯 HTTP、MQTT - 您不能仅基于此协议就它使用的内容做出任何保证。
然而，RSocket 是一个 协议 ，它被设计为特别适合响应式服务，在多种传输上工作，并且（作为二进制文件）协议）效率更高。这就引出了你的下一点：
Aren't they just a way of improving the performance of the traditional request-response systems?
RSocket当然可以。您可以将它用作传统的 request/response 系统，并且只获得改进的性能，而其他一切都保持“经典”。然而，它还支持数据流（单向和双向）以及触发和忘记语义以及 协议 级别的可恢复流，因此具有功能优势和性能优势。
这可能是一些混淆的根源，因为（没有 RSocket）人们可能会选择使用中间件纯粹是因为它更容易管理这些流（而不是专门分离任何东西。）在这种情况下然后是的，不需要中间件。
在传输层之上工作，RSocket 也不关心它在哪里使用，或者通过它发送什么 - 所以它在通过 TCP 的服务器到服务器环境中运行就像在双向服务器中一样愉快通过 websocket 到客户端环境。
aren't those Rsocket+Reactor microservices still coupled exactly as HTTP based ones used to be?
是的，它们仍然是耦合的——这不是 Rsocket 试图解决的问题。它是一个协议，它不是中间件。例如，Kafka 稍后可以本地支持 Rsocket。 （我目前看不到任何迹象，但从技术上讲没有什么可以阻止它。）
In which scenarios is each of them more recommended?
如果您使用中间件的唯一原因是轻松生成和管理数据流（而不是受请求/响应的限制），那么 Rsocket 与反应式库相结合现在可以说在协议层上满足了这些标准.
但是，如果您将中间件用于解耦目的，那么您几乎肯定会希望继续使用它。然而，继续使用上述中间件当然不会阻止您在实现中使用反应式库 and/or Rsocket。
RSocket 的目的是提供一个应用程序到应用程序的通信协议，它更像是对等方相互交谈。 HTTP 是为人机（客户端-服务器）通信而设计的。即使是 HTTP2 或传入的 3 也不会改变这种观点。两种协议之间的主要区别之一是双向流。所以不，RSocket 不只是试图提高请求-响应性能。
Kafka 和反应流之间的一个关键区别是基础设施成本的观点。 Kafka 将缓冲所有数据，而反应流将使用背压来协调发送方和接收方。 RSocket 只是将反应流扩展到网络协议级别。基本上它是 TCP 在第 6 层端到端滑动 window。
我们都同意，通过 HTTP 调用通信微服务的通常请求-响应方式会导致它们之间的耦合。这将我们带到了事件驱动的方法，在这种方法中，服务发布一些其他服务将对其做出反应的事件。为此，我们可以使用一些中间件，可以是来自 AMQ、RabbitMQ、Kafka 等的任何东西。
然而，反应式编程社区也确实创建了一些优秀的项目，例如 Project Reactor 或 RxJava，它们将 HTTP 通信转变为伪消息驱动的解决方案。此外，随着RSocket等协议的到来，该模型也到达了TCP/IP应用层。
RSocket/Reactive 微服务实际上可以被视为事件驱动的解决方案吗？它们不就是提高传统请求-响应系统性能的一种方式吗？
换句话说：那些 Rsocket+Reactor 微服务不是仍然像过去基于 HTTP 的微服务那样耦合吗？
它们分别在哪些场景下比较推荐？
这里有很多可以解压，抱歉篇幅太长了。
你的问题标题描绘了一个错误的二分法。两者不是相互竞争的想法，实际上恰恰相反，以至于 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 中的响应式库当然非常适合消息驱动的解决方案，但它们几乎可以用于任何事情（并且可以说经常用于它们并不总是最好的情况适合！）
Can RSocket/Reactive microservices be actually considered event-driven solutions?
Rsocket 和响应式微服务是两个不同的东西；虽然它们一起玩得很好并且经常一起使用，但它们并不相同。 RSocket 对于初学者来说要新得多，所以大多数响应式微服务可能已经没有使用它了。
反应式微服务，或以反应方式编写的微服务，主要与它们在内部编写的方式有关。作为反应式，后端是 non-blocking，因此可以说它们更高效 - 特别是在需要在 long-term 连接上发送数据流的情况下。 Non-reactive 服务必须在整个时间内保持一个单独的线程打开以管理该连接，而反应式服务可以简单地处于空闲状态，除非正在主动发送消息。
反应式微服务肯定是 event-driven 内部的。然而，这并没有说明反应式微服务可能用于通信的方式。它可以使用 RSocket、纯 HTTP、MQTT - 您不能仅基于此协议就它使用的内容做出任何保证。
然而，RSocket 是一个 协议 ，它被设计为特别适合响应式服务，在多种传输上工作，并且（作为二进制文件）协议）效率更高。这就引出了你的下一点：
Aren't they just a way of improving the performance of the traditional request-response systems?
RSocket当然可以。您可以将它用作传统的 request/response 系统，并且只获得改进的性能，而其他一切都保持“经典”。然而，它还支持数据流（单向和双向）以及触发和忘记语义以及 协议 级别的可恢复流，因此具有功能优势和性能优势。
这可能是一些混淆的根源，因为（没有 RSocket）人们可能会选择使用中间件纯粹是因为它更容易管理这些流（而不是专门分离任何东西。）在这种情况下然后是的，不需要中间件。
在传输层之上工作，RSocket 也不关心它在哪里使用，或者通过它发送什么 - 所以它在通过 TCP 的服务器到服务器环境中运行就像在双向服务器中一样愉快通过 websocket 到客户端环境。
aren't those Rsocket+Reactor microservices still coupled exactly as HTTP based ones used to be?
是的，它们仍然是耦合的——这不是 Rsocket 试图解决的问题。它是一个协议，它不是中间件。例如，Kafka 稍后可以本地支持 Rsocket。 （我目前看不到任何迹象，但从技术上讲没有什么可以阻止它。）
In which scenarios is each of them more recommended?
如果您使用中间件的唯一原因是轻松生成和管理数据流（而不是受请求/响应的限制），那么 Rsocket 与反应式库相结合现在可以说在协议层上满足了这些标准.
但是，如果您将中间件用于解耦目的，那么您几乎肯定会希望继续使用它。然而，继续使用上述中间件当然不会阻止您在实现中使用反应式库 and/or Rsocket。
RSocket 的目的是提供一个应用程序到应用程序的通信协议，它更像是对等方相互交谈。 HTTP 是为人机（客户端-服务器）通信而设计的。即使是 HTTP2 或传入的 3 也不会改变这种观点。两种协议之间的主要区别之一是双向流。所以不，RSocket 不只是试图提高请求-响应性能。
Kafka 和反应流之间的一个关键区别是基础设施成本的观点。 Kafka 将缓冲所有数据，而反应流将使用背压来协调发送方和接收方。 RSocket 只是将反应流扩展到网络协议级别。基本上它是 TCP 在第 6 层端到端滑动 window。