汇智动力

售前免费咨询热线: 4 0 0 - 1 8 6 - 0 9 0 5
汇智资讯Huizhi information

当前位置:首页 »Web Service和REST(中)

Web Service和REST(中)

日期:2021-07-08 10:14:53 访问量: 来源:

6.2 RPC和REST

 

目录:

1. 6.2.1 RPC

2. 6.2.2 REST

REST近年来成为最主流的Web服务器设计模型,已经普遍取代了基于SOAP和WSDL的接口设计

 

6.2.1 RPC

6.2.1.1 RPC概念

RPC(Remote Procedure Call):远程过程调用,它是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的思想。

 

RPC 是一种技术思想而非一种规范或协议,常见 RPC 技术和框架有:

应用级的服务框架:阿里的 Dubbo/Dubbox、Google gRPC、Spring Boot/Spring Cloud。

远程通信协议:RMI、Socket、SOAP(HTTP XML)、REST(HTTP JSON)。

通信框架:MINA 和 Netty。目前流行的开源 RPC 框架还是比较多的,有阿里巴巴的 Dubbo、Facebook 的 Thrift、Google 的gRPC、Twitter 的 Finagle 等

 

简单解释:

RPC=SOAP+WSDL+UDDI

 

6.2.1.2 RPC框架

在一个典型 RPC 的使用场景中,包含了服务发现、负载、容错、网络传输、序列化等组件,其中“RPC协议”就指明了程序如何进行网络传输和序列化。

 

Web Service和REST(中)

 

例如阿里Dubbo的设计框架图,分层清晰,功能复杂:

 

Web Service和REST(中)

 

6.2.1.3 RPC 核心功能

RPC 的核心功能是指实现一个 RPC 最重要的功能模块,就是上图中的”RPC 协议”部分

 

Web Service和REST(中)

 

一个 RPC 的核心功能主要有 5 个部分组成,分别是:客户端、客户端 Stub、网络传输模块、服务端Stub、服务端等

 

Web Service和REST(中)

 

6.2.1.4 RPC 核心之功能实现

RPC 的核心功能主要由 5 个模块组成,如果想要自己实现一个 RPC,最简单的方式要实现三个技术点,分别是:

  • 服务寻址

  • 数据流的序列化和反序列化

  • 网络传输

 

6.2.1.5 RPC 核心之网络传输协议

在 RPC 中可选的网络传输方式有多种,可以选择 TCP 协议、UDP 协议、HTTP 协议。

 

基于TCP协议和基于HTTP协议RPC调用方式对比:

1. 基于 TCP 的协议实现的 RPC 调用,由于 TCP 协议处于协议栈的下层,能够更加灵活地对协议字段进行定制,减少网络开销,提高性能,实现更大的吞吐量和并发数。

 

但是需要更多关注底层复杂的细节,实现的代价更高。同时对不同平台,如安卓,iOS 等,需要重新开发出不同的工具包来进行请求发送和相应解析,工作量大,难以快速响应和满足用户需求。

 

2. 基于 HTTP 协议实现的 RPC 则可以使用 JSON 和 XML 格式的请求或响应数据。

 

而 JSON 和 XML 作为通用的格式标准(使用 HTTP 协议也需要序列化和反序列化,不过这不是该协议下关心的内容,成熟的 Web 程序已经做好了序列化内容),开源的解析工具已经相当成熟,在其上进行二次开发会非常便捷和简单。

 

但是由于 HTTP 协议是上层协议,发送包含同等内容的信息,使用 HTTP 协议传输所占用的字节数会比使用 TCP 协议传输所占用的字节数更高。

 

3. 因此在同等网络下,通过 HTTP 协议传输相同内容,效率会比基于 TCP 协议的数据效率要低,信息传输所占用的时间也会更长,当然压缩数据,能够缩小这一差距

 

6.2.2 REST

6.2.2.1 什么是REST

REST -- REpresentational State Transfer 直接翻译:表现层状态转移

RESTful -- 如果一个架构符合REST风格就称它为RESTful架构

RESTful service是一种架构模式,近几年比较流行,它的轻量级web服务,发挥HTTP协议的原生的GET,PUT,POST,DELETE。

REST模式的Web服务与复杂的SOAP和XML-RPC对比来讲明显的更加简洁,越来越多的web服务开始采用REST风格设计和实现。

 

例如,Amazon.com提供接近REST风格的Web服务进行图书查找;雅虎提供的Web服务也是REST风格的。REST 并非始终是正确的选择。它作为一种设计 Web 服务的方法而变得流行,这种方法对专有中间件(例如某个应用程序服务器)的依赖比基于 SOAP 和 WSDL 的方法更少。在某种意义上,通过强调URI和HTTP等早期 Internet 标准,REST 是对大型应用程序服务器时代之前的Web 方式的回归。

 

先解释和REST概念有关的三个概念:资源、表现层、状态转化

 

资源:

所谓"资源",就是网络上的一个实体,或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务,就是一个具体的实在。可以用一个URI指向它,要获取这个资源,访问这个URI就可以

 

表现层:

REST的表现层状态转化省略了主语,表现层的其实指的就是资源的表现层

资源是信息实体,可以有多种表现形式,资源的具体表现形式就是表现层

例如文本可以用txt格式,也可以用html、json、xml等格式

URI只代表资源的实体,不代表他的形式

例如网址的最后的.html不是必要的,属于表现层范畴,URI应该只代表资源位置,它的的具体表现形式应该在HTTP的请求HEAD中Accept和Content-Type指定,这两个字段才是对表现层的描述

 

状态转化:

访问网站,代表了客户端和服务器端的互动,势必涉及数据和状态的变化

HTTP是一个无状态协议,所有的状态都保存在服务器端。如果客户端要操作服务器就需要通过方法,让服务器发生状态转化

而这种状态转化是建立在表现层之上的,所以是表现层状态转化

 

6.2.2.2 RESTful架构

RESTful架构的几个特点为:

1. 资源

2. 统一接口

3. URI

4. 无状态

 

Web Service和REST(中)

 

统一接口:

RESTful 架构风格规定,数据的元操作,即 CRUD(Create,Read,Update 和 Delete,即数据的增删查改)操作,分别对应于 HTTP 方法:GET 用来获取资源,POST 用来新建资源(也可以用于更新资源),PUT用来更新资源,DELETE 用来删除资源,这样就统一了数据操作的接口,仅通过 HTTP 方法,就可以完成对数据的所有增删查改工作。

 

URI:

可以用一个 URI(统一资源定位符)指向资源,即每个 URI 都对应一个特定的资源。

要获取这个资源,访问它的 URI 就可以,因此 URI 就成了每一个资源的地址或识别符。

 

无状态:

所谓无状态的,即所有的资源,都可以通过 URI 定位,而且这个定位与其他资源无关,也不会因为其他资源的变化而改变。有状态和无状态的区别。

 

举个简单的例子说明一下。

如查询员工的工资,如果查询工资是需要登录系统,进入查询工资的页面,执行相关操作后,获取工资的多少,则这种情况是有状态的。因为查询工资的每一步操作都依赖于前一步操作,只要前置操作不成功,后续操作就无法执行。

如果输入一个 URI 即可得到指定员工的工资,则这种情况是无状态的,因为获取工资不依赖于其他资源或状态。

且这种情况下,员工工资是一个资源,由一个 URI 与之对应,可以通过 HTTP 中的 GET 方法得到资源,这是典型的 RESTful 风格

 

总结:

什么是RESTful架构:

1. 每个URI代表一种资源

2. 客户端和服务器之间,传递这种资源的某种表现层

3. 客户端通过HTTP的四个方法GET、POST、PUT、DELETE,对服务器资源进行操作,实现表现层状态转化

 

6.2.2.3 RPC和RESTful架构对比

面对对象不同:

RPC 更侧重于动作。

REST 的主体是资源。

RESTful 是面向资源的设计架构,但在系统中有很多对象不能抽象成资源,比如登录,修改密码等而

RPC 可以通过动作去操作资源。所以在操作的全面性上 RPC 大于 RESTful。

 

传输效率:

RPC 效率更高。RPC,使用自定义的 TCP 协议,可以让请求报文体积更小,或者使用 HTTP2 协议,也可以很好的减少报文的体积,提高传输效率。

 

复杂度:

RPC 实现复杂,流程繁琐。

REST 调用及测试都很方便。

RPC 实现需要实现编码,序列化,网络传输等。而 RESTful 不要关注这些,RESTful 实现更简单。

 

灵活性:

HTTP 相对更规范,更标准,更通用,无论哪种语言都支持 HTTP 协议。

RPC 可以实现跨语言调用,但整体灵活性不如 RESTful。

 

【未完待续...】

相关阅读Reading

全国热线:400-186-0905

总部热线:028-6547-1147

周一至周日9:30-24:00

我要咨询
汇智动力微信

汇智动力微信公众号