RSocket 系列的第三篇
如果你看过本系列的前两篇文章,应该已经已经发现 RSocket 提供了一些底层的 API。可以直接使用交互模型中的方法进行操作,而且可以没有任何限制来回发送帧。这些基础的 API 为我们提供了许多自由和控制权,但是它可能会引入额外的问题,尤其是与微服务之间的契约相关的问题。
为了解决这些问题,我们可以使用 RSocket 作为通用抽象层。有两种可用的解决方案: RSocket RPC 或者与 Spring Framework 集成 。在以下各节中,我们将简要讨论它们。
保持微服务之间的契约干净清晰是分布式系统的关键问题之一。为了确保应用程序可以交换数据,我们可以利用 RPC(远程过程调用)。幸运的是,RSocket 具有专用的 RPC 模块,它使用 Protobuf 作为序列化工具,因此,我们可以从 RSocket 的性能中受益并且同时具有保持契约的能力。通过将生成的服务和对象与 RSocket 接受器结合在一起,我们可以启动完全可操作的 RPC 服务端,并使用 RPC 客户端轻松使用它。
首先,我们需要定义服务和对象。在下面的示例中,我们创建了具有四个方法的简单的 CustomerService
服务,它们每个表示交互模型相互不同的方法。
其次,我们必须使用上面显示的 proto 文件来生成类。为此,我们可以创建一个 Gradle 任务,如下所示:
作为 generateProto
任务的结果,我们应该能够获得服务接口、服务客户端和服务服务端类
CustomerService
CustomerServiceClient
CustomerServiceServer
再次,我们必须实现服务接口(CustomerService)的相关业务逻辑:
最后,我们可以通过 RSocket 暴露服务。为此,我们必须创建服务端的实例(CustomerServiceServer)并注入服务的实现(DefaultCustomerService)。然后,我们准备创建一个 RSocket 接受器实例。该 API 提供了 RequestHandlingRSocket
,该服务包装服务端实例,并将契约中定义的端点转换为 RSocket 交互模型中可用的方法。
在客户端,实现非常简单。我们需要做的就是创建 RSocket 实例,并通过构造函数将其注入到客户端实例中,然后就可以开始了。
将 RSocket 与 RPC 方法结合使用有助于维护微服务之间的契约,并改善日常开发人员的体验。它适用于不需要完全控制帧的典型场景,但是另一方面,它不限制协议的灵活性。我们仍然可以在同一应用程序中暴露 RPC 端点以及普通的 RSocket 接受器,以便我们可以轻松地为给定用例选择最佳的通信模式。在 RSocket 上进行 RPC 的情况下,可能会出现一个基本的问题:它比 gRPC 好吗?这个问题没有简单的答案。RSocket 是一项新技术,它需要一些时间才能达到与 gRPC 相同的成熟度。另一方面,它在两个方面超过了 gRPC:性能(这里可以使用基准测试)和灵活性——可以作为传输层用于 RPC 或作为普通消息传递解决方案。在决定在生产环境中使用哪种软件之前,应该确定 RSocket 是否符合的“早期采用”策略,并且不会使软件面临风险。就个人而言,我建议在不太重要的区域引入 RSocket,然后再扩展到系统的其余部分。
第二个可用的解决方案是通过 与 Spring Boot 的集成 提供对 RSocket 的抽象,我们将 RSocket 用作反应式消息传递解决方案,并利用 Spring 注解轻松地将方法与路由连接起来。在下面的示例中,我们实现了两个 Spring Boot 应用程序(请求者和响应者)。响应者通过 CustomerController
暴露 RSocket 接口,并映射到三个路径: customer
、 customer-stream
和 customer-channel
。这些映射中的每一个都反映了来自 RSocket 交互模型的不同方法(分别是请求-响应,请求流和通道)。 CustomerController
还实现了简单的业务逻辑,并返回带有随机名称的 CustomerResponse
对象,如下例所示:
请注意,下面提供的示例基于 Spring Boot RSocket starter 2.2.0.M4 版本,这意味着它不是正式版本,API 可能会更改。
值得注意的是,Spring Boot 会自动检测类路径上的 RSocket 库并启动服务端。我们需要做的就是指定端口:
这几行代码和配置设置了完全可操作的响应者程序。让我们再看一下请求方。在这里,我们实现了 CustomerServiceAdapter
,它负责与响应者进行通信。它使用 RSocketRequester
bean 封装 RSocket 实例,该 bean 中还包含数据类型以及封装在 RSocketStrategies 对象中编码/解码的详细信息。再用反应式的方式给 RSocketRequester 配置路由消息以及处理数据的序列化/反序列化信息。总结下来,我们需要做的就是提供路由、数据以及消费响应者的消息的方式——作为单个对象(Mono)或作为流(Flux)。
除了与响应者进行通信之外,请求者还通过三种路径暴露 RESTful API: /customers/{id}
, /customers
, /customers-channel
。在这里,我们使用 Spring WebFlux,基于 HTTP2 协议。请注意,最后两个映射会生成文本事件流,这意味着数据可用时将被流式传输到 Web 浏览器。
要使用上述 REST 接口,可以使用以下 curl
命令:
Spring Boot 集成和 RPC 模块的是 RSocket 之上的补充解决方案。第一个是面向消息传递的,并提供了方便的消息路由 API,而 RPC 模块使开发人员可以轻松控制暴露的端口并维护微服务之间的契约。这两种解决方案都有应用场景,可以轻松地与 RSocket 底层 API 结合使用单一协议以一致的方式满足最复杂的要求。
本文是与 RSocket 有关的微型系列的最后一部分,RSocket 是一种新的二进制协议,可以彻底改变云中服务之间的通信。其丰富的交互模型,性能和其他功能,例如, 客户端负载平衡和可恢复性 使其成为几乎所有可能的业务案例的理想选择。RSocket 的使用还可以通过可用的抽象层进行简化:Spring Boot 集成和 RPC 模块——它们可以解决最典型的日常场景。请注意,RSocket 处于候选版本(1.0.0-RC2)中,因此不建议在生产环境中使用该协议。尽管如此,还是应当保持关注的,因为不断增长的社区和大型科技公司(例如 Netflix,Facebook,阿里巴巴,Netifi)的支持可能会使 RSocket 成为云中的主要通信协议。
原文:https://dzone.com/articles/reactive-service-to-service-communication-with-rso-3
近期热文
JVM 源码解读之 CMS GC 触发条件
如何减少长时间的 GC 停顿?
简单的 HTTP 调用,为什么时延这么大?
服务刚启动就 Old GC,要闹哪样?
喜欢本文的朋友们,欢迎长按下图关注订阅号 涤生的博客 ,收看更多精彩内容