我们都同意，通过HTTP调用与微服务通信的常见请求-响应方式会导致它们之间的耦合。这就把我们带到了事件驱动的方法，在这种方法中，服务发布一些其他服务将做出反应的事件。为此，我们可以使用一些中间件，可以是AMQ、RabbitMQ、Kafka等
然而，反应式编程社区确实创建了一些优秀的项目，如Project Reactor或RxJava，它们将HTTP通信变成了伪消息驱动的解决方案。此外，随着RSocket等协议的到来，该模型也已到达TCP/IP应用层。
-
RSocket/Reflective微服务实际上可以被视为事件驱动的解决方案吗？它们不只是提高传统请求-响应系统性能的一种方式吗？
-
换一种说法：那些Rsocket+Rreactor微服务是否仍然像过去那样耦合？
-
在哪种情况下，更推荐它们？
这里有一个批次要拆包，很抱歉太长了。
你的题目描绘了一个错误的二分法。这两者并不是相互竞争的想法，实际上恰恰相反，以至于反应性卡夫卡是一种东西。
然而，反应式编程社区确实创建了一些优秀的项目，如Project Reactor或RxJava，它们将HTTP通信变成了伪消息驱动的解决方案。
Java中的反应式库当然非常适合台面驱动的解决方案，但它们几乎可以用于任何事情(可以说，它们经常用于不总是最适合的情况！)
RSocket/Reflective微服务实际上可以被视为事件驱动的解决方案吗？
Rsocket和反应式微服务是两种不同的东西；虽然它们在一起玩得很好，而且经常一起使用，但它们并不相同。RSocket对于初学者来说要新得多，所以大多数反应式微服务可能已经不使用它了
反应式微服务，或以反应式方式编写的微服务，主要与内部编写方式有关。由于是被动的，后端是非阻塞的，因此可以说它们更高效——尤其是在需要通过长期连接发送数据流的情况下。非响应式服务必须在整个时间内保持一个单独的线程打开，以管理该连接，而响应式服务可能只是处于空闲状态，除非正在主动发送消息。
反应式微服务肯定是内部事件驱动的。然而，这并没有说明反应式微服务可以用来通信的方式。它可以使用RSocket、纯HTTP、MQTT——仅基于此协议，您无法保证它正在使用什么。
RSocket然而，它是一个协议，设计用于非常好地处理响应式服务，在多个传输上工作，并且(作为二进制协议)更高效。这就引出了你的下一点：
它们不只是提高传统请求-响应系统性能的一种方式吗？
RSocket当然可以。您可以将其用作传统的请求/响应系统，只需获得改进的性能，其他一切都保持不变；经典"；。然而，它也支持数据流(单向和双向)，以及协议级别的fire-and-forget语义和可恢复流，因此具有功能优势和性能优势。
这可能是一些混乱的根源，因为(没有RSocket)人们可能会选择使用中间件，纯粹是因为它更容易管理这些流(而不是解耦任何特定的东西。)在这种情况下，是的，不需要中间件。
在传输层之上工作，RSocket也不在乎它在哪里使用，也不在乎通过它发送什么——所以它在TCP的服务器到服务器环境中操作就像在websocket的双向服务器到客户端环境中操作一样愉快。
那些Rsocket+Rreactor微服务是否仍然像以前那样耦合？
是的，它们仍然是耦合的——这不是Rsocket试图解决的问题。这是一个协议，不是中间件。例如，Kafka可以稍后原生地支持Rsocket。(我目前看不到任何迹象表明它会这样做，但从技术上讲，没有什么能阻止它。)
在哪些情况下更推荐它们？
如果您使用中间件的唯一原因是轻松生成和管理数据流(而不是受请求/repsonse的约束)，那么Rsocket与反应库相结合现在可以说在协议层上满足了这些标准。
然而，如果您使用中间件进行解耦，那么您几乎肯定会想继续使用它。然而，继续使用上述中间件当然不会妨碍您在实现中使用反应库和/或Rsocket。
RSocket的目的是提供一个应用程序到应用程序的通信协议，该协议更像是对等体之间的通信。HTTP是为人机(客户端-服务器)通信而设计的。即使是HTTP2或即将推出的3也不会改变这种观点。这两种协议之间的主要区别之一是双向流。所以不，RSocket不仅仅是想提高请求响应性能。
Kafka和反应流之间的一个关键区别是对基础设施成本的看法。Kafka将缓冲所有数据，而反应流将使用背压来协调发送器和接收器。RSocket只是将反应流扩展到网络协议级别。基本上，它是TCP在第6层端到端的滑动窗口。