问题标签 [rsocket]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
spring-boot - Spring 5 WebFlux 服务器通过 RSocket 协议推送通知
案例如下:
在作为客户端A
并B
通过协议与服务器建立连接后RSocket
,每个客户端都可以通过自己的事件(event A
或event B
)通知,以触发客户端上的某些操作(event X -> action on client X
)。
谢谢
spring-boot - Spring StandardWebsocketClient 可以连接到 Spring boot RSocket Server 吗?
我是 RSocket 的新手,所以请多多包涵。
我能够通过 TCP 和 Websocket 遵循服务器和客户端的 Spring boot RSocket 的工作示例。但是,如果我有一个实现标准 WebSocket 的现有客户端应用程序,那么我可以创建一个实现 RSocket 的新服务器应用程序 - Spring boot 并让现有客户端应用程序连接到这个新服务器而不更改任何客户端的源代码。
实际上我已经通过以下链接尝试了一些
结果,看起来服务器没有收到来自客户端的任何消息。我在这里误解了概念吗?
ssl - 安全 RSocket 抛出 java.lang.IllegalArgumentException:既未指定 SslContextBuilder 也未指定 SslContext
我正在尝试使用证书及其私钥启动一个安全的 RSocket,但我不知道为什么它会在secure{...}
语句中引发异常:java.lang.IllegalArgumentException: Neither SslContextBuilder nor SslContext is specified
完整日志:
reactor-netty - 使用 TLS 保护时 RSocket 不工作 - 服务器 java.lang.UnsupportedOperationException - 客户端 java.nio.channels.ClosedChannelException
更新我已经将一个示例项目上传到 Github,您可以在其中重现该问题。检查自述文件中的说明。
我有一个可用于请求流的 RSocket 服务器,生成一个带有 n 个随机数的 Flux:
我还创建了一个连接到 RSocket 并请求 10 个随机数的客户端:
这完美运行。
服务器日志:
客户端日志:
但是我想在 RSocket 通信中使用 TLS,所以我为服务器创建了一个 certificate.pem/key.pem 并配置它:
在客户端,我创建了一个 truststore.jks,导入了 certificate.pem 并将客户端配置为使用安全通信:
启动服务器后,我启动客户端。服务器的接受器请求流被调用(打印Generating 10 random numbers
)但立即失败:
在客户端有一个关闭的通道异常:
如何修复它以使用 TLS?
java - springboot-rsocket如何接收多个参数?
如果我给Rsocket设置更多参数,Rsocket在请求Controller时报错
如何解决?这是我的 rsocket-controller 配置,可能是配置问题吗?
spring-boot - 用于传输 FHIR 资源的 RSocket 与 HTTP 性能
我最近开始了一系列关于使用FHIR资源的服务到服务通信的性能调查,以确定在以下方面花费的处理时间:
- 有效载荷通信/交换
- 序列化和反序列化有效负载
在调查过程中,我遇到了两个我不明白的结果,因此我希望RSocket开发团队的帮助。我将详细说明结果和问题。
为了确定最快的通信方式,我分析了使用两种传输协议的三种传输方式——HTTP 和 RSocket。更准确地说 - 我已经分析和基准测试:
- 使用HAPI REST 服务器和 HAPI FHIR 客户端交换 FHIR 资源
- 通过使用Web 客户端访问 Spring
@RestController
端点,使用 REST 通信交换字符串(序列化 FHIR 资源)RestTemplate
- 使用RSocket消息交换 FHIR 资源
对前两种通信方法的分析在使用 HAPI REST 服务器交换 FHIR 资源和交换(原始)字符串有效负载(包括将这些有效负载反序列化为 FHIR 资源)之间产生了巨大差异。更准确地说 - 对于大型 FHIR 资源,HAPI REST 服务器增加的开销大约是(原始)字符串通信和反序列化所需开销的 3-4 倍。
关于两个服务之间的 RSocket 通信 - 我尝试使用两种模式来交换 FHIR 资源:
- 作为原始字符串,从 FHIR 资源序列化
- 作为原始 FHIR 资源,让 RSocket 处理序列化和反序列化
第一种方法(使用原始字符串)产生的负载交换开销几乎与 HTTP(使用 REST)通信所需的开销相似。更准确地说 - 通信开销比 HTTP 通信高几个百分比 (5-10%)。这让我感到惊讶,因为我认为 RSocket 通信开销会比HTTP 通信低得多——我至少看过一个 Spring & Netifi 演示,其中 RSocket 被宣传为“比 HTTP 快 10 倍”。
我的第一个想法是我在 RSocket 配置中做错了,因此我尝试了RSocketRequester
Spring bean 的各种配置更改,从零复制帧解码器的设置开始。但是,它们都没有在整体性能上有任何明显的改进。
我的下一个尝试是在服务之间交换原始 FHIR 资源,方法是实现 RSocket 编码器和解码器类来交换 FHIR 资源。在与 RSocket 编码器和解码器接口的实现进行了一些斗争之后,我设法在两个服务之间交换了 FHIR 资源。问题 - FHIR 资源通信的性能非常低,远低于String
s 交换的性能。
对于很长的介绍/上下文设置,我的问题/帮助请求是:我在分析中做错了什么和/或遗漏了什么,所以我没有获得 RSocket 承诺的性能优势?
我在这个Github 存储库中包含了两个示例项目(一个 RSocket 请求者和一个响应者)。最相关的类是RSocket 配置和 FHIR Bundle 编码器和解码器。
免责声明:我知道这个问题在Netifi 社区页面上会得到更好的解决。在过去的几天里,该页面无法再访问,因此这里有这么长的帖子。
先感谢您。
spring-boot - 与在 Kubernetes 集群上使用直接 RSocket 应用程序通信相比,Netifi 代理有哪些改进?
假设我有一个 Kubernetes 集群,我在其中部署了使用 RSocket 进行通信的 Spring Boot 应用程序。为了相互调用,他们将使用 Kubernetes 服务名称,因此我们将依赖该“注册表”进行发现和路由。
另一方面,Netify 提供了一个Netifi 经纪人可以部署在 Kubernetes 上如果我理解得很好,这个代理是为了调解应用程序之间的通信,所以那些 Spring Boot RSocket 应用程序不会通过它们的 Kubernetes 服务名称进行通信,而是通过 Netifi 代理。
每种方法的优点和缺点是什么?
authentication - 跨微服务传递用户信息
基本上,我有一个微服务 A,它通过检查凭据来验证用户,它需要将用户请求转发到另一个微服务,该微服务对请求进行进一步处理。我们使用基于会话的身份验证。在微服务 B 中收到请求后,它需要保留发起请求的用户的记录。这些微服务使用 RSocket 相互通信。现在,如果我需要将登录的用户信息传递给微服务 B,我可以将其作为请求的一部分发送,或者我可以创建 JWT 令牌并将令牌与请求一起传递。可以在服务 B 处验证令牌以获取授权和用户详细信息。最好的方法是什么?请建议是否有任何其他方式可以以更好的方式完成?
apache-kafka - 带有消息代理(例如 Kafka)的事件驱动微服务与反应式编程(RxJava、Project Reactor)以及改进的协议(RSocket)
我们都同意,通过 HTTP 调用通信微服务的通常请求-响应方式会导致它们之间的耦合。这使我们采用了事件驱动的方法,在这种方法中,服务发布一些其他服务将响应的事件。为此,我们可以使用一些中间件,可以是 AMQ、RabbitMQ、Kafka 等。
然而,反应式编程社区也确实创建了一些优秀的项目,例如 Project Reactor 或 RxJava,它们将 HTTP 通信转变为伪消息驱动的解决方案。此外,随着 RSocket 等协议的到来,这种模式也到达了 TCP/IP 应用层。
RSocket/Reactive 微服务真的可以被认为是事件驱动的解决方案吗?它们不只是提高传统请求-响应系统性能的一种方式吗?
换一种说法:那些 Rsocket+Reactor 微服务不仍然像以前基于 HTTP 的微服务那样耦合吗?
在哪些场景下更推荐它们?