Fork me on GitHub

RPC与RESTful

  接口调用通常包含两个部分,序列化和通信协议。
  常见的序列化协议包括json、xml、hession、protobuf、thrift、text、bytes等;
  通信比较流行的是http、soap、websockect,RPC通常基于TCP实现,常用框架例如dubbo,netty、mina、thrift

首先解释下两种接口调用:
  Rest:严格意义上说接口很规范,操作对象即为资源,对资源的四种操作(post、get、put、delete),并且参数都放在URL上,但是不严格的说Http+json、Http+xml,常见的http api都可以称为Rest接口。
  Rpc:我们常说的远程方法调用,就是像调用本地方法一样调用远程方法,通信协议大多采用二进制方式

RPC vs RESTful

  在微服务中,使用什么协议来构建服务体系,一直是个热门话题。 争论的焦点集中在两个候选技术: (binary) RPC or Restful。
  业内对微服务的实现,基本是确定一个组织边界,在该边界内,使用RPC; 边界外,使用Restful。这个边界,可以是业务、部门,甚至是全公司。

RPC

  以Apache Thrift为代表的二进制RPC,支持多种语言(但不是所有语言),四层通讯协议,性能高,节省带宽。相对Restful协议,使用Thrifpt RPC,在同等硬件条件下,带宽使用率仅为前者的20%,性能却提升一个数量级。但是这种协议最大的问题: 无法穿透防火墙

RESTful

  以Spring Cloud为代表所支持的Restful 协议,优势在于能够穿透防火墙,使用方便,语言无关,基本上可以使用各种开发语言实现的系统,都可以接受Restful 的请求。 但性能和带宽占用上有劣势。
  什么是RESTful?URL定位资源,用HTTP动词(GET,POST,PUT,DELETE)描述操作

  RESTFul API有哪些特点:
  1.基于“资源”,数据也好、服务也好,在RESTFul设计里一切都是资源。
  2.无状态。一次调用一般就会返回结果,不存在类似于“打开连接-访问数据-关闭连接”这种依赖于上一次调用的情况。
  3.URL中通常不出现动词,只有名词
  4.URL语义清晰、明确
  5.使用HTTP的GET、POST、DELETE、PUT来表示对于资源的增删改查。RESTful风格的数据元操CRUD(create,read,update,delete)分别对应HTTP方法:GET用来获取资源,POST用来新建资源(也可以用于更新资源),PUT用来更新资源,DELETE用来删除资源,这样就统一了数据操作的接口。
  6.使用JSON不使用XML

  所以RESTful API就是REST风格的API。 那么在什么场景下使用RESTful API呢?在当今的互联网应用的前端展示媒介很丰富。有手机、有平板电脑还有PC以及其他的展示媒介。那么这些前端接收到的用户请求统一由一个后台来处理并返回给不同的前端肯定是最科学和最经济的方式,RESTful API就是一套协议来规范多种形式的前端和同一个后台的交互方式。
  RESTful API由后台也就是SERVER来提供前端来调用。前端调用API向后台发起HTTP请求,后台响应请求将处理结果反馈给前端。也就是说RESTful 是典型的基于HTTP的协议。那么RESTful API有哪些设计原则和规范呢?
  1,资源。首先是弄清楚资源的概念。资源就是网络上的一个实体,一段文本,一张图片或者一首歌曲。资源总是要通过一种载体来反应它的内容。文本可以用TXT,也可以用HTML或者XML、图片可以用JPG格式或者PNG格式,JSON是现在最常用的资源表现形式。
  2,统一接口。RESTful风格的数据元操CRUD(create,read,update,delete)分别对应HTTP方法:GET用来获取资源,POST用来新建资源(也可以用于更新资源),PUT用来更新资源,DELETE用来删除资源,这样就统一了数据操作的接口。
  3,URI。可以用一个URI(统一资源定位符)指向资源,即每个URI都对应一个特定的资源。要获取这个资源访问它的URI就可以,因此URI就成了每一个资源的地址或识别符。一般的,每个资源至少有一个URI与之对应,最典型的URI就是URL。
  4,无状态。所谓无状态即所有的资源都可以URI定位,而且这个定位与其他资源无关,也不会因为其他资源的变化而变化。有状态和无状态的区别,举个例子说明一下,例如要查询员工工资的步骤为第一步:登录系统。第二步:进入查询工资的页面。第三步:搜索该员工。第四步:点击姓名查看工资。这样的操作流程就是有状态的,查询工资的每一个步骤都依赖于前一个步骤,只要前置操作不成功,后续操作就无法执行。如果输入一个URL就可以得到指定员工的工资,则这种情况就是无状态的,因为获取工资不依赖于其他资源或状态,且这种情况下,员工工资是一个资源,由一个URL与之对应可以通过HTTP中的GET方法得到资源,这就是典型的RESTful风格。
  说了这么多,到底RESTful长什么样子的呢?
  下面是一些例子。
  GET /zoos:列出所有动物园
  POST /zoos:新建一个动物园
  GET /zoos/ID:获取某个指定动物园的信息
  PUT /zoos/ID:更新某个指定动物园的信息(提供该动物园的全部信息)
  PATCH /zoos/ID:更新某个指定动物园的信息(提供该动物园的部分信息)
  DELETE /zoos/ID:删除某个动物园
  GET /zoos/ID/animals:列出某个指定动物园的所有动物
  DELETE /zoos/ID/animals/ID:删除某个指定动物园的指定动物

  RESTful API还有其他一些规范。
  1: 应该将API的版本号放入URL。GET:http://www.xxx.com/v1/friend/123。或者将版本号放在HTTP头信息中。要不要版本号取决于自己开发团队的习惯和业务的需要,不是强制的。
  2: URL中只能有名词而不能有动词,操作的表达是使用HTTP的动词GET,POST,PUT,DELETEL。URL只标识资源的地址,既然是资源那就是名词了。
  3: 如果记录数量很多,服务器不可能都将它们返回给用户。API应该提供参数,过滤返回结果。?limit=10:指定返回记录的数量、?page=2&perpage=100:指定第几页,以及每页的记录数。
  4: 使用Token令牌来做用户身份的校验与权限分级,而不是Cookie。
  5: url中大小写不敏感,不要出现大写字母
  6: 使用 - 而不是使用
做URL路径中字符串连接。


区别

  使用RPC远程服务调用方式与传统http接口直接调用方式的差别在于:
  1).从使用方面看
  Http接口只关注服务提供方,对于客户端怎么调用,调用方式怎样并不关心,通常情况下,我们使用Http方式进行调用时,只要将内容进行传输即可,这样客户端在使用时,需要更关注网络方面的传输,比较不适用与业务方面的开发;
  而RPC服务则需要客户端接口与服务端保持一致,服务端提供一个方法,客户端通过接口直接发起调用,业务开发人员仅需要关注业务方法的调用即可,不再关注网络传输的细节,在开发上更为高效。

  2).从性能角度看
  使用Http时,Http本身提供了丰富的状态功能与扩展功能,但也正由于Http提供的功能过多,导致在网络传输时,需要携带的信息更多,从性能角度上讲,较为低效。
  RPC服务网络传输上仅传输与业务内容相关的数据,传输数据更小,性能更高。

  3).从运维角度看,
  使用Http接口时,常常使用一个前端代理,来进行Http转发代理请求的操作,需要进行扩容时,则需要去修改代理服务器的配置,较为繁琐,也容易出错。
  而使用RPC方式的微服务,则只要增加一个服务节点即可,注册中心可自动感知到节点的变化,通知调用客户端进行负载的动态控制,更为智能,省去运维的操作。

  Rest 调用及测试都很方便,Rpc就显得有点麻烦,但是Rpc的效率是毋庸置疑的
  所以建议在多系统之间采用Rpc,对外提供服务,Rest是很适合的.
  duboo在生产者和消费者两个微服务之间的通信采用的就是Rpc,无疑在服务之间的调用Rpc更变现的优秀


几种协议

  Socket 使用时可以指定协议Tcp,Udp等;
  RIM 使用Jrmp协议,Jrmp又是基于TCP/IP;
  RPC 底层使用Socket接口,定义了一套远程调用方法;
  HTTP 是建立在TCP上,不是使用Socket接口,需要连接方主动发数据给服务器,服务器无法主动发数据个客户端;
  在微服务架构中,各个服务之间可能千差万别,rest接口更加灵活,如果使用RPC则会有很多约束


参考文章:
  RPC vs RESTful
  微服务 Rpc和Rest协议
  什么是RESTful API?

-----------------本文结束,感谢您的阅读-----------------