RPC简介及框架选择

简单介绍RPC协议及常见框架，对比传统restful api和RPC方式的优缺点。常见RPC框架，gRPC及序列化方式Protobuf等

HTTP协议

http协议是基于tcp协议的，tcp协议是流式协议，包头部分能够经过多出的\r\n来分界，包体部分如何分界呢？这是协议自己要解决的问题。目前通常有两种方式，第一种方式就是在包头中有个content-Length字段，这个字段的值的大小标识了POST数据的长度，服务器收到一个数据包后，先从包头解析出这个字段的值，再根据这个值去读取相应长度的做为http协议的包体数据。
浏览器connect 80端口

RESTful API (http+json)

理解RESTful架构 - 阮一峰
REST 架构该怎么生动地理解？ - 覃超的回答 - 知乎

网站即软件，并且是一种新型的软件，这种"互联网软件"采用客户端/服务器模式，创建在分布式体系上，经过互联网通讯，具备高延时（high latency）、高并发等特色。
　　它首次出如今 2000 年 Roy Fielding 的博士论文中，他是 HTTP 规范的主要编写者之一。Representational State Transfer，翻译是”表现层状态转化”，通俗来说就是：资源在网络中以某种表现形式进行状态转移。
总结一下什么是RESTful架构：
　　（1）每个URI表明一种资源；
　　（2）客户端和服务器之间，传递这种资源的某种表现层，好比用JSON，XML，JPEG等；
　　（3）客户端经过四个HTTP动词，对服务器端资源进行操做，实现"表现层状态转化"。

URL定位资源，用HTTP动词（GET,POST,DELETE,DETC）描述操做。
用HTTP协议里的动词来实现资源的添加，修改，删除等操做。即经过HTTP动词来实现资源的状态扭转：
　　GET 用来获取资源，
　　POST 用来新建资源（也能够用于更新资源），
　　PUT 用来更新资源，
　　DELETE 用来删除资源。

RPC

进程间通讯（IPC，Inter-Process Communication），指至少两个进程或线程间传送数据或信号的一些技术或方法。进程是计算机系统分配资源的最小单位。每一个进程都有本身的一部分独立的系统资源，彼此是隔离的。为了能使不一样的进程互相访问资源并进行协调工做，才有了进程间通讯。这些进程能够运行在同一计算机上或网络链接的不一样计算机上。 进程间通讯技术包括消息传递、同步、共享内存和远程过程调用。 IPC是一种标准的Unix通讯机制。

有两种类型的进程间通讯(IPC)。

• 本地过程调用(LPC)LPC用在多任务操做系统中，使得同时运行的任务能互相会话。这些任务共享内存空间使任务同步和互相发送信息。
• 远程过程调用(RPC)RPC相似于LPC，只是在网上工做。RPC开始是出如今Sun微系统公司和HP公司的运行UNIX操做系统的计算机中。

为何RPC呢？就是没法在一个进程内，甚至一个计算机内经过本地调用的方式完成的需求，好比好比不一样的系统间的通信，甚至不一样的组织间的通信。因为计算能力须要横向扩展，须要在多台机器组成的集群上部署应用

RPC的核心并不在于使用什么协议。RPC的目的是让你在本地调用远程的方法，而对你来讲这个调用是透明的，你并不知道这个调用的方法是部署哪里。经过RPC能解耦服务，这才是使用RPC的真正目的。RPC的原理主要用到了动态代理模式，至于http协议，只是传输协议而已。简单的实现能够参考spring remoting，复杂的实现能够参考dubbo。

简单的说，

• RPC就是从一台机器（客户端）上经过参数传递的方式调用另外一台机器（服务器）上的一个函数或方法（能够统称为服务）并获得返回的结果。
• RPC 会隐藏底层的通信细节（不须要直接处理Socket通信或Http通信） RPC 是一个请求响应模型。
• 客户端发起请求，服务器返回响应（相似于Http的工做方式） RPC 在使用形式上像调用本地函数（或方法）同样去调用远程的函数（或方法）。

RPC通讯过程

RPC架构简单理解
远程过程调用(RPC)详解

默认socket通讯。本地机器的RPC框架反序列化出执行结果，函数return这个结果

 

RPC通讯过程

RPC和restful api对比

* REST vs JSON-RPC? - stackoverflow
既然有http 请求，为何还要用rpc调用？ - 手不要乱摸的回答 - 知乎
为何须要RPC，而不是简单的HTTP接口

REST是一种设计风格，它的不少思惟方式与RPC是彻底冲突的。 RPC的思想是把本地函数映射到API，也就是说一个API对应的是一个function，我本地有一个getAllUsers，远程也能经过某种约定的协议来调用这个getAllUsers。至于这个协议是Socket、是HTTP仍是别的什么并不重要； RPC中的主体都是动做，是个动词，表示我要作什么。 而REST则否则，它的URL主体是资源，是个名词。并且也仅支持HTTP协议，规定了使用HTTP Method表达本次要作的动做，类型通常也不超过那四五种。这些动做表达了对资源仅有的几种转化方式。
RPC的根本问题是耦合。RPC客户端以多种方式与服务实现紧密耦合，而且很难在不中断客户端的状况下更改服务实现。RPC更偏向内部调用，REST更偏向外部调用。

Web 服务应该算是 RPC 的一个子集，理论上 RPC 能实现的功能， 用 Web 服务也能实现，甚至不少 RPC 框架选用 HTTP 协议做为传输层。
如今不少网站的 API 都是以 HTTP 服务的形式提供的，这也算是 RPC 的一种形式。

区别主要在这 2 个东西设计的出发点不太同样：

• HTTP 是面向浏览器设计的应用层协议，操做的核心在资源。咱们更多的用 Web 服务在作网站。
• RPC 是为了在像在本地调用一个函数那样调用远程的代码而设计的，因此更关注减小本地调用和远程调用的差别，像 SOAP(简单对象访问协议) 这种东西是能够把对象当参数传的。

咱们讨论 RPC 和 Web 的区别，实际上是在谈论 2 个东西：序列化协议和传输协议。序列化协议好比常见的 XML，JSON 和比较现代的 Protocol Buffers、Thrift。 传输协议好比 TCP、UDP 以及更高层的 HTTP 1.一、HTTP 2.0。

通常咱们考虑用 RPC 而不是 HTTP 构建本身的服务，一般是考虑到下面的因素：

• 接口是否须要 Schema 约束
• 是否须要更高效的传输协议（TCP，HTTP 2.0）
• 是否对数据包的大小很是敏感

好比 HTTP 是基于文本的协议，头部有很是多冗余（对于 RPC 服务而言）。HTTP 中咱们用的最多就是 RESTful ，而 RESTful 是个弱 Schema 约束，你们经过文档沟通，可是若是我就是不在实现的时候对接口文档约定的参数作检查，你也不能把我怎么样。这个时候 Thrift 这种序列化协议的优点就体现出来了，因为 Schema 的存在，能够保证服务端接受的参数和 Schema 保持一致。

RPC框架

谁能用通俗的语言解释一下什么是 RPC 框架？ - 洪春涛的回答 - 知乎
经常使用的跨语言通讯方案
深刻浅出 RPC - 深刻篇

• Call ID映射。咱们怎么告诉远程机器咱们要调用Multiply，而不是Add或者FooBar呢？在本地调用中，函数体是直接经过函数指针来指定的，咱们调用Multiply，编译器就自动帮咱们调用它相应的函数指针。可是在远程调用中，函数指针是不行的，由于两个进程的地址空间是彻底不同的。因此，在RPC中，全部的函数都必须有本身的一个ID。这个ID在全部进程中都是惟一肯定的。客户端在作远程过程调用时，必须附上这个ID。而后咱们还须要在客户端和服务端分别维护一个 {函数 <--> Call ID} 的对应表。二者的表不必定须要彻底相同，但相同的函数对应的Call ID必须相同。当客户端须要进行远程调用时，它就查一下这个表，找出相应的Call ID，而后把它传给服务端，服务端也经过查表，来肯定客户端须要调用的函数，而后执行相应函数的代码。
• 序列化和反序列化。客户端怎么把参数值传给远程的函数呢？在本地调用中，咱们只须要把参数压到栈里，而后让函数本身去栈里读就行。可是在远程过程调用时，客户端跟服务端是不一样的进程，不能经过内存来传递参数。甚至有时候客户端和服务端使用的都不是同一种语言（好比服务端用C++，客户端用Java或者Python）。这时候就须要客户端把参数先转成一个字节流，传给服务端后，再把字节流转成本身能读取的格式。这个过程叫序列化和反序列化。同理，从服务端返回的值也须要序列化反序列化的过程。
• 网络传输。远程调用每每用在网络上，客户端和服务端是经过网络链接的。全部的数据都须要经过网络传输，所以就须要有一个网络传输层。网络传输层须要把Call ID和序列化后的参数字节流传给服务端，而后再把序列化后的调用结果传回客户端。只要能完成这二者的，均可以做为传输层使用。所以，它所使用的协议实际上是不限的，能完成传输就行。尽管大部分RPC框架都使用TCP协议，但其实UDP也能够，而gRPC干脆就用了HTTP2。Java的Netty也属于这层的东西。

目前有不少Java的RPC框架，有基于Json的，有基于XML，也有基于二进制对象的。

论复杂度，RPC框架确定是高于简单的HTTP接口的。但毋庸置疑，HTTP接口因为受限于HTTP协议，须要带HTTP请求头，致使传输起来效率或者说安全性不如RPC

 

RPC框架封装

经常使用RPC框架

支持Java最多，golang

• Netty - Netty框架不局限于RPC，更多的是做为一种网络协议的实现框架，好比HTTP，因为RPC须要高效的网络通讯，就可能选择以Netty做为基础。
• brpc是一个基于protobuf接口的RPC框架，在百度内部称为“baidu-rpc”，它囊括了百度内部全部RPC协议，并支持多种第三方协议，从目前的性能测试数据来看，brpc的性能领跑于其余同类RPC产品。
• Dubbo是Alibaba开发的一个RPC框架，远程接口基于Java Interface, 依托于Spring框架。
• gRPC的Java实现的底层网络库是基于Netty开发而来，其Go实现是基于net库。
• Thrift是Apache的一个项目(http://thrift.apache.org)，前身是Facebook开发的一个RPC框架，采用thrift做为IDL (Interface description language)。
• jsonrpc

JSON-RPC

python web接口实现（restful方式、jsonrpc方式）
区块链项目中用的较多？资料不是不少
JSON-RPC是一种序列化协议。JSON 是 JS 对象的字符串表示法，它使用文本表示一个 JS 对象的信息，本质是一个字符串。
很是简单，方便，速度慢
相关Python 包(直接集成到flask和django)
Flask-JSONRPC,django-json-rpc；jsonrpcserver,jsonrpcclient

thrift

Python RPC 之 Thrift
Facebook开源的跨语言RPC框架。

gRPC

gRPC 官方文档中文版
深刻了解gRPC协议-知乎

1. tensorflow分布式与tensorflow serving底层通讯都是是用的grpc
   序列化用protobuf，通讯使用http2
2. latest Google APIs will have gRPC versions of their interfaces, letting you easily build Google functionality into your applications.
3. 支持 C, C++, Node.js, Python, Ruby, Objective-C,PHP and C#

HTTP2

一文读懂 HTTP2 特性 - 又拍云的文章 - 知乎
HTTP/2 和 HTTP/1 速度对比
http://www.http2demo.io/
HTTP/2
HTTP/2 是 HTTP 协议自 1999 年 HTTP 1.1 发布后的首个更新，主要基于 SPDY 协议。
HTTP/2的主要目标是经过启用完整请求和响应复用来减小延迟，经过有效压缩HTTP头字段来最大限度地下降协议开销，并添加对请求优先级和服务器推送的支持;多路复用(同一tcp,多个流)，头部压缩，服务推送。

Protobuf

经常使用的跨语言通讯方案
Google Protocol Buffer 的使用和原理
Protobuf 语法指南
Protocol Buffers 是一种轻便高效的结构化数据存储格式，能够用于结构化数据串行化，或者说序列化。它很适合作数据存储或 RPC 数据交换格式。可用于通信协议、数据存储等领域的语言无关、平台无关、可扩展的序列化结构数据格式。目前提供了 C++、Java、Python 三种语言的 API。
同 XML 相比， Protobuf 的主要优势在于性能高。它以高效的二进制方式存储，比 XML 小 3 到 10 倍，快 20 到 100 倍。

框架选择

gRPC vs Thrift
RPC框架性能基本比较测试
怎么看待谷歌的开源 RPC 框架 gRPC？ - 知乎
微服务的服务间通讯与服务治理
最佳实践 | 7大维度看国外企业为啥选择gRPC打造高性能微服务？

如何选择

何时应该选择gRPC而不是Thrift
　　须要良好的文档、示例
　　喜欢、习惯HTTP/二、ProtoBuf
　　对网络传输带宽敏感
何时应该选择Thrift而不是gRPC
　　须要在很是多的语言间进行数据交换
　　对CPU敏感
　　协议层、传输层有多种控制要求
　　须要稳定的版本
　　不须要良好的文档和示例

总的来讲，Python rpc框架选择较少，thrift性能最好，grpc性能比thrift稍差，缘由是多了http2，而thrift直接基于tcp，但grpc序列化方案更通用(protobuf)优秀，文档较好；
jsonrpc 自己基于http/1进行通讯，速度最慢，相对于以前速度无提高，只是接口和数据格式更为统一；

gRPC不足

1）GRPC还没有提供链接池 2）还没有提供“服务发现”、“负载均衡”机制 3）由于基于HTTP2，绝大部多数HTTP Server、Nginx都尚不支持，即Nginx不能将GRPC请求做为HTTP请求来负载均衡，而是做为普通的TCP请求。（nginx将会在1.9版本支持）

做者：63e7d8aa8856 连接：https://www.jianshu.com/p/b0343bfd216e 来源：简书 简书著做权归做者全部，任何形式的转载都请联系做者得到受权并注明出处。