Restful已经用得太多了，是不是有种被接口压垮的感觉？ 接口还没好，您就等着吧。摸鱼抓虾，问兄弟好了没，答还没好，今天啥事儿没干，1,2,3,4，周五好了，你这儿疯狂测试一堆问题，ok周末加加班，这就是常态。
RPC是远程过程调用（Remote Procedure Call）的缩写形式。SAP系统RPC调用的原理其实很简单，有一些类似于三层构架的C/S系统，第三方的客户程序通过接口调用SAP内部的标准或自定义函数，获得函数返回的数据进行处理后显示或打印。 RPC主要是解决软件多进程之间的调用问题，而要解决软硬件之间的通信需要CORBA（CORBA（Common ObjectRequest Broker Architecture公共对象请求代理体系结构）是由OMG组织制订的一种标准的面向对象应用程序体系规范。或者说CORBA体系结构是对象管理组织（OMG）为解决分布式处理环境(DCE)中，硬件和软件系统的互连而提出的一种解决方案；OMG组织是一个国际性的非盈利组织，其职责是为应用开发提供一个公共框架，制订工业指南和对象管理规范，加快对象技术的发展。）。
目录
原理
通过IPC和RPC，程序能利用其它程序或计算机处理的进程。客户机/服务器模式计算把远程过程调用与其它技术（如消息传递）一道，作为系统间通信的一种机制。客户机执行自己的任务，但靠服务器提供后端文件服务。RPC为客户机提供向后端服务器申请服务的通信机制，如图R-4所示。如果你把客户机/服务器应用程序想作是一个分离的程序，服务器能运行数据访问部分，因为它离数据最近，客户机能运行数据表示和与用户交互的前端部分。这样，远程过程调用可看作是把分割的程序通过网络重组的部件。LPC有时也称耦合（Coupling）机制。
用这种方式分割程序，当用户要访问数据时就无需每次拷贝整个数据库或它的大部分程序到用户系统。其实，服务器只处理请求，甚至只执行一些数据计算，把得出的结果再发送给用户。因为当数据存放在一个地方时，数据库同步很容易实现，所以多个用户可同时访问相同的数据。
分布式计算环境是由一个通信系统——网络连接的计算机集群。很容易把这个网络看成一个计算平台，若是对等方式，其中任何一台计算机都能成为客户机或服务器。一些处理任务可被分成独立运行程序在不同的网络计算机上并行处理，而独立的程序被交给最适合这个任务的计算机处理。这种策略可利用计算机空闲资源，提高网络的效益。一个典型的企业网包括许多运行着不同操作系统的异构计算机系统。
随着企业网的产生，开发商必须编制可在各种计算机和网络通信协议中都能运行的程序。现在人们正努力使得远程过程调用独立，这意味着开发商就不用考虑底层的网络和网络上数据传输所用的协议，下面介绍RPC在开放式软件基金（OSF）的分布式计算环境(DCC）中实现的相关方法。RPC工作于多种分布式计算环境。
应用
RPC在分布式系统中的系统环境建设和应用程序设计中有着广泛的应用，应用包括如下方面：
- 分布式操作系统的进程间通讯
进程间通讯是操作系统必须提供的基本设施之一,分布式操作系统必须提供分布于异构的结点机上进程间的通讯机制，RPC是实现消息传送模式的分布式进程间通讯的手段之一。
- 构造分布式计算的软件环境
由于分布式软件环境本身地理上的分布性, 它的各个组成成份之间存在大量的交互和通讯,R P C 是其基本的实现方法之一。ONC+和DCE两个流行的分式布计算软件环境都是使用RPC构造的，其它一些分布式软件环境也采用了RPC方式。
- 远程数据库服务
在分布式数据库系统中，数据库一般驻存在服务器上，客户机通过远程数据库服务功能访问数据库服务器，现有的远程数据库服务是使用RPC模式的。例如，Sybase和Oracle都提供了存储过程机制，系统与用户定义的存储过程存储在数据库服务器上，用户在客户端使用RPC模式调用存储过程。
- 分布式应用程序设计
RPC机制与RPC工具为分布式应用程序设计提供了手段和方便, 用户可以无需知道网络结构和协议细节而直接使用RPC工具设计分布式应用程序。
- 分布式程序的调试
RPC可用于分布式程序的调试。使用反向RPC使服务器成为客户并向它的客户进程发出RPC，可以调试分布式程序。例如，在服务器上运行一个远端调试程序，它不断接收客户端的RPC，当遇到一个调试程序断点时，它向客户机发回一个RPC，通知断点已经到达，这也是RPC用于进程通讯的例子。
框架
语言平台绑定的开源 RPC 框架主要有下面几种。
- RMI：利用java.rmi包实现，基于Java远程方法协议(Java Remote Method Protocol) 和java的原生序列化。
- Hessian ：轻量级的remoting onhttp工具，使用简单的方法提供了RMI的功能。基于HTTP协议，采用二进制编解码。
- Protobuf：Java类库，提供了基于 Google 的 Protocol Buffers 协议的远程方法调用的框架。基于 Netty 底层的 NIO 技术。支持 TCP 重用/ keep-alive、SSL加密、RPC 调用取消操作、嵌入式日志等功能。
- Dubbo：国内最早开源的 RPC 框架，由阿里巴巴公司开发并于 2011 年末对外开源，仅支持 Java 语言。
- Motan：微博内部使用的 RPC 框架，于 2016 年对外开源，仅支持 Java 语言。
- Tars：腾讯内部使用的 RPC 框架，于 2017 年对外开源，仅支持 C++ 语言。
- Spring Cloud：国外 Pivotal 公司 2014 年对外开源的 RPC 框架，仅支持 Java 语言
而跨语言平台的开源 RPC 框架主要有以下几种。
- gRPC：Google 于 2015 年对外开源的跨语言 RPC 框架，支持多种语言。
- Thrift：最初是由 Facebook 开发的内部系统跨语言的 RPC 框架，2007 年贡献给了 Apache 基金，成为 Apache 开源项目之一，支持多种语言。
如果你的业务场景仅仅局限于一种语言的话，可以选择跟语言绑定的 RPC 框架中的一种;
如果涉及多个语言平台之间的相互调用，就应该选择跨语言平台的 RPC 框架。
RPC 框架，它们具体有何区别?
Dubbo
先来聊聊 Dubbo，Dubbo 可以说是国内开源最早的 RPC 框架了，目前只支持 Java 语言，它的架构可以用下面这张图展示。
从图中你能看到，Dubbo 的架构主要包含四个角色，其中 Consumer 是服务消费者，Provider 是服务提供者，Registry 是注册中心，Monitor 是监控系统。
具体的交互流程是 Consumer 一端通过注册中心获取到 Provider 节点后，通过 Dubbo 的客户端 SDK 与 Provider 建立连接，并发起调用。Provider 一端通过 Dubbo 的服务端 SDK 接收到 Consumer 的请求，处理后再把结果返回给 Consumer。
Motan
Motan 是国内另外一个比较有名的开源的 RPC 框架，同样也只支持 Java 语言实现，它的架构可以用下面这张图描述。
Motan 与 Dubbo 的架构类似，都需要在 Client 端(服务消费者)和 Server 端(服务提供者)引入 SDK，其中 Motan 框架主要包含下面几个功能模块。
register：用来和注册中心交互，包括注册服务、订阅服务、服务变更通知、服务心跳发送等功能。
protocol：用来进行 RPC 服务的描述和 RPC 服务的配置管理，这一层还可以添加不同功能的 filter 用来完成统计、并发限制等功能。
serialize：将 RPC 请求中的参数、结果等对象进行序列化与反序列化
transport：用来进行远程通信，默认使用 Netty NIO 的 TCP 长链接方式。
cluster：请求时会根据不同的高可用与负载均衡策略选择一个可用的 Server 发起远程调用。
Tars
Tars 是腾讯根据内部多年使用微服务架构的实践，总结而成的开源项目，仅支持 C++ 语言，它的架构图如下。
Tars 的架构交互主要包括以下几个流程：
服务发布流程：在 web 系统上传 server 的发布包到 patch，上传成功后，在 web 上提交发布 server 请求，由 registry 服务传达到 node，然后 node 拉取 server 的发布包到本地，拉起 server 服务。
管理命令流程：web 系统上的可以提交管理 server 服务命令请求，由 registry 服务传达到 node 服务，然后由 node 向 server 发送管理命令。
心跳上报流程：server 服务运行后，会定期上报心跳到 node，node 然后把服务心跳信息上报到 registry 服务，由 registry 进行统一管理。
信息上报流程：server 服务运行后，会定期上报统计信息到 stat，打印远程日志到 log，定期上报属性信息到 prop、上报异常信息到 notify、从 config 拉取服务配置信息。
client 访问 server 流程：client 可以通过 server 的对象名 Obj 间接访问 server，client 会从 registry 上拉取 server 的路由信息(如 IP、Port 信息)，然后根据具体的业务特性(同步或者异步，TCP 或者 UDP 方式)访问 server(当然 client 也可以通过 IP/Port 直接访问 server)。
Spring Cloud
Spring Cloud 利用 Spring Boot 特性整合了开源行业中优秀的组件，整体对外提供了一套在微服务架构中服务治理的解决方案。
只支持 Java 语言平台，它的架构图可以用下面这张图来描述。
由此可见，Spring Cloud 微服务架构是由多个组件一起组成的，各个组件的交互流程如下。
请求统一通过 API 网关 Zuul 来访问内部服务，先经过 Token 进行安全认证。
通过安全认证后，网关 Zuul 从注册中心 Eureka 获取可用服务节点列表。
从可用服务节点中选取一个可用节点，然后把请求分发到这个节点。
整个请求过程中，Hystrix 组件负责处理服务超时熔断，Turbine 组件负责监控服务间的调用和熔断相关指标，Sleuth 组件负责调用链监控，ELK 负责日志分析。
gRPC
先来看下 gRPC，它的原理是通过 IDL(Interface Definition Language)文件定义服务接口的参数和返回值类型，然后通过代码生成程序生成服务端和客户端的具体实现代码，这样在 gRPC 里，客户端应用可以像调用本地对象一样调用另一台服务器上对应的方法。
它的主要特性包括三个方面。
通信协议采用了 HTTP/2，因为 HTTP/2 提供了连接复用、双向流、服务器推送、请求优先级、首部压缩等机制
IDL 使用了ProtoBuf，ProtoBuf 是由 Google 开发的一种数据序列化协议，它的压缩和传输效率极高，语法也简单
多语言支持，能够基于多种语言自动生成对应语言的客户端和服务端的代码。
Thrift
再来看下 Thrift，Thrift 是一种轻量级的跨语言 RPC 通信方案，支持多达 25 种编程语言。为了支持多种语言，跟 gRPC 一样，Thrift 也有一套自己的接口定义语言 IDL，可以通过代码生成器，生成各种编程语言的 Client 端和 Server 端的 SDK 代码，这样就保证了不同语言之间可以相互通信。它的架构图可以用下图来描述。
从这张图上可以看出 Thrift RPC 框架的特性。
支持多种序列化格式：如 Binary、Compact、JSON、Multiplexed 等。
支持多种通信方式：如 Socket、Framed、File、Memory、zlib 等。
服务端支持多种处理方式：如 Simple 、Thread Pool、Non-Blocking 等。
为什么RPC取代RESTFul接口服务调用
==========安全性考虑：=================
1、RPC地址的隐蔽性，无需暴露API地址，只需要提供公共代码级别的用户接口
2、HTTP不安全，必须要使用基于安全协议的HTTPS
3、内部通信约定俗成，管理API繁琐，文档更新不及时，发布应用安全性BUG（版本不匹配问题，底层难以发现）
==========维护成本考虑：==============
1、提供接口而不是实现，本质上约束好接口行为，无须关注内部实现
2、接口级别变更可以及时发现调整，在代码级别解决问题
3、RPC可以随时调整服务访问地址，具有天然的负载均衡能力，适合分布式系统
4、RPC具备双向调用能力，某些行为不需要再重新编写多余的代码即可实现调用
5、可以抛开某个系统，而只用其部分能力时不需要再进行二次开发，项目里面拿来即用(采用依赖配置和配置RPC服务地址解决)
==========跨服务调用：=================
1、目前大多数应用都在朝着微服务方向发展，服务之间的调用将更加频繁和广泛
2、服务之间请求难以保障，本质上HTTP底层也是TCP协议实现的也会建立连接等待服务响应，高性能调用
3、避免服务之间不可拆分，链式调用，导致服务不可用
4、只需要服务的能力，而不需要单独的部署，而RESTFUL需要某种能力需要单独部署
5、不需要解决跨域问题，不需要Nginx去做一堆的代理
痛点：一个核心服务被多个业务系统调用，每次都部署不同的服务以适应项目差异，而项目中每次都在用RestTemplate或者HttpClient的调用，接口调用都需要沟通才能实现，该核心项目由于设计上的不合理经常遭到多个项目组的吐槽，每次升级发布都需要全部将服务包下载下来逐个替换文件，很是繁琐。要么弃用，要么改变方式，在不能弃用的情况下：我建议去掉Restful接口，直接使用RPC定义好接口调用即可。一个服务有哪些行为设计上都是一清二楚的，这些接口定义好就可以各自开发调用了何乐而不为呢，沟通永远是最大的成本，但也是缩小成本的最佳方式。