云原生实践之 RSocket 从入门到落地:Servlet vs RSocket

简介: 技术实践的作用在于:除了用于构建业务,也是为了验证某项技术或框架是否值得大规模推广。本期开始,我们推出《RSocket 从入门到落地》系列文章,通过实例和对比来介绍RSocket。主要围绕RSocket如何实现Polyglot RPC、Service Registry、 Service Discovery、 IoT联结等维度,为读者们揭开RSocket的面纱,希望对大家在Java API规范的技术选型过程中有所借鉴。

技术实践的作用在于:除了用于构建业务,也是为了验证某项技术或框架是否值得大规模推广。

本期开始,我们推出《RSocket 从入门到落地》系列文章,通过实例和对比来介绍RSocket。主要围绕RSocket如何实现Polyglot RPC、Service Registry、 Service Discovery、 IoT联结等维度,为读者们揭开RSocket的面纱,希望对大家在Java API规范的技术选型过程中有所借鉴。

第一篇文章我们将通过Servlet和RSocket的对比,快速了解RSocket的一些基本知识。要说明的是其实RSocket与Servlet并不是同类的产品,但是大家对Servlet都很熟悉,功能对比相对方便一些。

阅读本系列文章,需要大家对Java有了解,其中可能会涉及到Kotlin,有少部分C++和Python(不做要求),如果了解Spring Boot则最好。

什么是 Servlet ?

维基百科上的解释是"Servlet,全称Java Servlet,是用Java编写的服务器端程序。 其主要功能在于交互式地浏览和修改数据,生成动态Web内容”。

对于Java程序员来说,解释这个概念直接上代码,这样才能方便理解,如下:

public abstract class HttpServlet extends Servlet {
    protected abstract void doGet(HttpServletRequest req,HttpServletResponse resp)
        throws ServletException, IOException;

    protected abstract void doPost(HttpServletRequest req,HttpServletResponse resp)
       throws ServletException, IOException;
}

所以,Servlet就是提供HTTP Request,处理后,最终调用HTTP Response完成输出。没错,就是这个,大家可别小瞧这个class,几乎所有符合Servlet规范的web框架的第一个Java类都是从这里开始的,包括Struts、Spring MVC和阿里巴巴内部用到的WebX。很多开发者根据这个class写了Web Framework,来解决不同的问题。

什么是 RSocket

rsocket.io给出的解释是"RSocket是一个二进制的协议,以异步消息的方式提供4种对等的交互模型,以字节流的方式运行在TCP, WebSockets, Aeron等传输层之上”。

通过这个定义,大家可以有一个基本理解:二进制协议、异步消息、七层协议和运行在TCP、WebSocket以及Aeron之上。同样的,我们通过代码来解释这个概念,如下:

public interface RSocket extends Availability, Closeable {

  Mono<Payload> requestResponse(Payload payload);

  Mono<Void> fireAndForget(Payload payload);

  Flux<Payload> requestStream(Payload payload);

  Flux<Payload> requestChannel(Publisher<Payload> payloads);

  Mono<Void> metadataPush(Payload payload);

  default double availability() {
  return isDisposed() ? 0.0 : 1.0;
}

展开阐述一下:

四个模型:

requestResponse、fireAndForget、requestStream和requestChannel,它们和doGet、doPost没有区别。

参数:

Payload,前面说到基于消息通讯,那就是拿到消息返回消息,Got!等一下,为何不叫Message?请原谅我们的英文水平,暂时可以理解为同义词吧。对于一个消息来说,由两部分组成,原信息(metadata)和数据(data)。原信息是指路由信息等,例如要调用那个服务,你的数据的mime type是什么,数据则是指调用的参数值和返回的结果。

metadataPush:

这个是什么?推送元信息的,可以告诉对方的一些元信息,至于是什么,可以自己定义。我理解为:如果是一个集群,我可以将集群的信息给你,然后让你和各个work node连接;我要下线啦,大家做好准备等等。

availability:

为何要这个? 这个可以理解问健康度检查,如果为0,则表示不可用,这在load balance的情况下非常实用。Servlet缺少这个,所以我们要自行加入Health URL等,如/ok.jsp :) 那为何不是布尔值,true或者false?仅是个人理解:double值可以作为权重,如1.0表示处理能力非常好,0.8一般,这个就看你如何处理了。

Mono和Flux:

这是Reactive编程要求,通过异步的方式来提升系统的处理能力。RSocket定义中有一个异步关键字,Mono和Flux就是来处理异步的。

Servlet 和 RSocket的区别

其实两者的共同点非常明显:Servlet是一套Java的API规范,基于HTTP协议之上;RSocket也是一套API规范(支持多种语言),基于自定义的二进制协议之上。 可以不用关心协议的细节,直接实现接口写代码就可以,然后功能就会Ready。 这里我们还是想列举一下它们两者之间的重大区别:

协议层:

Servlet是基于HTTP协议的,RSocket则是自定义协议。 标准化方面,HTTP尚不用说。 但是RSocket的自定义二进制协议性能非常好,解析方便。如果觉得HTTP非常简单,那是1.1,2.0版本开始是有点复杂的。这里我们可以理解为:RSocket定位高性能通讯,比HTTP高非常多(号称10倍)。这里要注意的是:RSocket并不是天然的极致高性能,要实现极致高性能需要根据自己业务场景优化才行。

指令和通讯模式:

HTTP的指令不只是get和post,其他还有head、put、delete和options等。Servlet2.0添加了流式的支持,但是这些指令都是为浏览器设计的,并非为服务通讯设计的,而且它们都是request/response模式,所以也叫做 request command。其他例如流式推送、fireAndForget和双向通讯,Servlet2.0都不支持。基本上,我们可以将HTTP定位为request/response这一种通讯模式。这个说法也许有争议,因为HTTP也有polling和websocket等,但是这些设计都是为了hack和高效通讯的改造,而不是内置的通讯模式。

message:

HTTP1.1是基于文本的通讯,2.0是基于message的。 message的好处是什么呢?基于message的好处是异步化。message都必须有一个ID,这个消息发送出去后,就不用等立即返回,可以继续发其他message,收到message后,再根据返回的message ID和之前的发出去的message ID进行匹配。如果不是message,内容发出去后,就要等着返回的结果进行匹配,然后才能发下一个message,这也是为何很多人抱怨www是World Wide Wait。

Reactive编程模型:

RSocket要求基于Reactive编程模型,对Java来说,主要是Reactor和RxJava,由于Spring在RSocket上贡献颇多,外加RSocket Java SDK还要基于Netty-Reactor,所以默认的接口就是Reactor API。异步化对编程确实比较有挑战,如callback、Future和Promise等,对比传统不是那么友好,所以Reactive在传统和异步化上推出了Reactive编程模型,算是兼顾,这个看大家如何理解,如果对Functional Programming也能接受的话,那Reactive就没有问题。

对等通讯:

我们传统的理解是Client -> Server模式,例如写一个Servlet运行在服务端的,然后再用JS写一个Servlet运行在浏览器端,这样服务端可以反向调用浏览器,例如订单状态变更时,需要将详情区域刷新一下。但是RSocket没有这个概念,大家的地位是对等的,都可以在server端,我调用你的服务,你也可以调用我的服务。后续我们会有详细的Demo来介绍这个使用场景,如无监听端口对外提供服务,从互联网反向访问内部服务。RSocket Broker就是基于这种对等通讯来实现的。

Singleton & Prototype scope:

这里我们套用Spring的Singleton scope和Prototype scope来看Servlet和RSocket的不同。 Singleton scope表示JVM唯一,而Prototype scope是每次调用都需要创建。类比而言,Servlet的class基本都是singleton的,但是RSocket确未必,主要原因是前面说到的对等通讯,如果要给连接的另一方发送请求,就需要hold住连接的另一方(peer RSocket),所以这个handler就不能singleton的,如果只是单方通讯,不用在乎setup payload,那么RSocket的handler为Singleton也没有关系。

当然还有一项细小差别,这些就不做介绍了。鉴于个人能力,可能我理解的不够彻底,漏掉了重大的区别,大家理解和使用后,欢迎反馈一下。我们再通过图例来对比下两者的不同:
ce359da7368a27faa67bd531492c6bc4

RSocket Demo

这里我们将RSocket的Demo介绍一下。由于没有client -> server这种通讯模型,所以我们用requester和responder来说明,但是角色也是互换的,requester可以为responder,在实际的编码过程中,其实就将requester默认调整为responder。

Responder代码:

RSocketFactory.receive()
            .acceptor(new SocketAcceptor() {
                @Override
                public Mono<RSocket> accept(ConnectionSetupPayload setup, RSocket sendingSocket) {
                    return Mono.just(new RSocketHandlerImpl());
                }
            })
            .transport(TcpServerTransport.create("0.0.0.0", 42252))
            .start()
            .subscribe();

Responder主要是RSocketFactory.receive(),接收外部来的连接。接下来你只需要一个RSocket的接口实现给acceptor就可以了。 这里说明一下SocketAcceptor接口。对于Responder来说,它需要验证requester能否可以连接到自己,这个非常有用,如初始鉴权等,一旦鉴权通过,连接建立好后,后续就不需要验证了。这里的ConnectionSetupPayload是requester发给responder的创建连接的数据。这个是Servlet中没有的,后续我们还会提供更多的实践,第一篇文章里仅验证是否可以连接。

Requester代码:

RSocketFactory.connect()
                    .acceptor(new Function<RSocket, RSocket>() {
                        @Override
                        public RSocket apply(RSocket peerRsocket) {
                            return Mono.just(new RSocketHandlerImpl()) ;
                        }
                    })
                    .transport(TcpClientTransport.create("localhost", 42252))
                    .start()
                    .block();

RSocketFactory.connect() 是表示要连接到目标的responder上,然后也有RSocket实现给acceptor表示接收从对方过来的调用请求。 最好的block()表示采用同步方式等待responder返回,这个是需要的,如目标服务宕机或者不存在等,应用可以快速自我发现。 但是在load balance的情况下,我们未采用block这种方式,而是使用Mono方式,这样可以实现自动重连,新地址推送等。

实际上,如果使用Spring Boot,可能就需要1-2个Bean,SocketAcceptor和RSocket Bean,其他都是通过注入方式完成,不需要写很多重复代码。 目前rsocket-spring-boot-starter已经开发快完成了,所以不用担心代码的复杂性。

本文作者:雷卷,社区ID linux-china,Java程序员,阿里巴巴资深技术专家。

相关文章
|
1月前
|
缓存 Java API
【云原生】Spring Cloud Gateway的底层原理与实践方法探究
【云原生】Spring Cloud Gateway的底层原理与实践方法探究
|
3月前
|
存储 SQL Cloud Native
深入了解云原生数据库CockroachDB的概念与实践
作为一种全球领先的分布式SQL数据库,CockroachDB以其高可用性、强一致性和灵活性等特点备受关注。本文将深入探讨CockroachDB的概念、设计思想以及实践应用,并结合实例演示其在云原生环境下的优越表现。
|
3月前
|
Cloud Native 关系型数据库 大数据
CockroachDB:云原生数据库的新概念与实践
本文将介绍CockroachDB,一种先进的云原生数据库,它具备分布式、强一致性和高可用性等特点。我们将探讨CockroachDB的基本原理、架构设计以及在实际应用中的种种优势和挑战。
|
28天前
|
Cloud Native 安全 持续交付
构建未来:云原生架构的演进与实践
【2月更文挑战第30天】 随着数字化转型的深入,企业对于信息技术的需求日益复杂化和动态化。传统的IT架构已难以满足快速迭代、灵活扩展及成本效率的双重要求。云原生技术作为解决这一矛盾的关键途径,通过容器化、微服务、持续集成/持续部署(CI/CD)等手段,实现了应用的快速开发、部署及运维。本文将探讨云原生架构的最新发展,分析其如何助力企业构建更加灵活、高效的业务系统,并结合实际案例,展示云原生转型过程中的最佳实践和面临的挑战。
|
6天前
|
Kubernetes 监控 Cloud Native
构建高效云原生应用:基于Kubernetes的微服务治理实践
【4月更文挑战第13天】 在当今数字化转型的浪潮中,企业纷纷将目光投向了云原生技术以支持其业务敏捷性和可扩展性。本文深入探讨了利用Kubernetes作为容器编排平台,实现微服务架构的有效治理,旨在为开发者和运维团队提供一套优化策略,以确保云原生应用的高性能和稳定性。通过分析微服务设计原则、Kubernetes的核心组件以及实际案例,本文揭示了在多变的业务需求下,如何确保系统的高可用性、弹性和安全性。
11 4
|
4月前
|
资源调度 调度 混合部署
Koordinator 助力云原生应用性能提升,小红书混部技术实践
本文基于 2023 云栖大会上关于 Koordinator 分享的实录,介绍小红书通过规模化落地混部技术来大幅提升集群资源效能,降低业务资源成本。
|
2月前
|
Prometheus 监控 Kubernetes
青团社:亿级灵活用工平台的云原生架构实践
青团社:亿级灵活用工平台的云原生架构实践
262339 5
|
3月前
|
人工智能 Cloud Native PyTorch
阿里云 ACK 云原生 AI 套件中的分布式弹性训练实践
阿里云 ACK 云原生 AI 套件中的分布式弹性训练实践
148647 4
|
3月前
|
人工智能 Cloud Native 调度
为大模型工程提效,基于阿里云 ACK 的云原生 AI 工程化实践
本文主要介绍了解析云原生 AI 所遇到的技术挑战和应对方案,随后介绍云原生 AI 领域的关键技术与架构细节,最后分享我们在 ACK 的相关经验及工程实践。
|
4月前
|
运维 Cloud Native Linux
【云原生|Docker系列第4篇】Docker的容器的入门实践
【云原生|Docker系列第4篇】Docker的容器的入门实践