RPC简介

为什么RPC呢？就是无法在一个进程内，甚至一个计算机内通过本地调用的方式完成的需求，比如比如不同的系统间的通讯，甚至不同的组织间的通讯。由于计算能力需要横向扩展，需要在多台机器组成的集群上部署应用，

RPC的协议有很多，比如最早的CORBA，Java RMI，Web Service的RPC风格，Hessian，Thrift，甚至Rest API。

=============================================================================================

RPC(远程过程调用)是什么

简单的说，RPC就是从一台机器（客户端）上通过参数传递的方式调用另一台机器（服务器）上的一个函数或方法（可以统称为服务）并得到返回的结果。
RPC 会隐藏底层的通讯细节（不需要直接处理Socket通讯或Http通讯）
RPC 是一个请求响应模型。客户端发起请求，服务器返回响应（类似于Http的工作方式）
RPC 在使用形式上像调用本地函数（或方法）一样去调用远程的函数（或方法）。

远程过程调用发展历程

ONC RPC （开放网络计算的远程过程调用），OSF RPC（开放软件基金会的远程过程调用）
CORBA（Common Object Request Broker Architecture公共对象请求代理体系结构）
DCOM（分布式组件对象模型），COM+
Java RMI
.NET Remoting
XML-RPC，SOAP，Web Service
PHPRPC，Hessian，JSON-RPC
Microsoft WCF，WebAPI
ZeroC Ice，Thrift，GRPC
Hprose

早期的 RPC

第一代 RPC（ONC RPC，OSF RPC）不支持对象的传递。
CORBA 太复杂，各种不同实现不兼容，一般程序员也玩不转。
DCOM，COM+ 逃不出 Windows 的手掌心。
RMI 只能在 Java 里面玩。
.NET Remoting 只能在 .NET 平台上玩。

XML-RPC，SOAP，WebService

冗余数据太多，处理速度太慢。
RPC 风格的 Web Service 跨语言性不佳，而 Document 风格的 Web Service 又太过难用。
Web Service 没有解决用户的真正问题，只是把一个问题变成了另一个问题。
Web Service 的规范太过复杂，以至于在 .NET 和 Java 平台以外没有真正好用的实现，甚至没有可用的实现。
跨语言跨平台只是 Web Service 的一个口号，虽然很多人迷信这一点，但事实上它并没有真正实现。

PHPRPC

基于 PHP 内置的序列化格式，在跨语言的类型映射上存在硬伤。
通讯上依赖于 HTTP 协议，没有其它底层通讯方式的选择。
内置的加密传输既是特点，也是缺点。
虽然比基于 XML 的 RPC 速度快，但还不是足够快。

Hessian

二进制的数据格式完全不具有可读性。
官方只提供了两个半语言的实现（Java，ActionScript 和不怎么完美的 Python 实现），其它语言的第三方实现良莠不齐。
支持的语言不够多，对 Web 前端的 JavaScript 完全无视。
虽然是动态 RPC，但动态性仍然欠佳。
虽然比基于 XML 的 RPC 速度快，但还不是足够快。

JSON-RPC

JSON 具有文本可读性，且比 XML 更简洁。
JSON 受 JavaScript 语言子集的限制，可表示的数据类型不够多。
JSON 格式无法表示数据内的自引用，互引用和循环引用。
某些语言具有多种版本的实现，但在类型影射上没有统一标准，存在兼容性问题。
JSON-RPC 虽然有规范，但是却没有统一的实现。在不同语言中的各自实现存在兼容性问题，无法真正互通。

Microsoft WCF，WebAPI

它们是微软对已有技术的一个 .NET 平台上的统一封装，是对 .NET Remoting、WebService 和基于 JSON 、XML 等数据格式的 REST 风格的服务等技术的一个整合。
虽然号称可以在 .NET 平台以外来调用它的这些服务，但实际上跟在 .NET 平台内调用完全是两码事。它没有提供任何在其他平台的语言中可以使用的任何工具。

ZeroC Ice，Thrift，GRPC

初代 RPC 技术的跨语言面向对象的回归。
仍然需要通过中间语言来编写类型和接口定义。
仍然需要用代码生成器来将中间语言编写的类型和接口定义翻译成你所使用的编程语言的客户端和服务器端的占位程序（stub）。
你必须要基于生成的服务器代码来单独编写服务，而不能将已有代码直接作为服务发布。
你必须要用生成的客户端代码来调用服务，而没有其它更灵活的方式。
如果你的中间代码做了修改，以上所有步骤你都要至少重复一遍。

Hprose

国产。无侵入式设计，不需要单独定义类型，不需要单独编写服务，已有代码可以直接发布为服务。
具有丰富的数据类型和完美的跨语言类型映射，支持自引用，互引用和循环引用数据。
支持众多传输方式，如 HTTP、TCP、Websocket 等。
客户端具有更灵活的调用方式，支持同步调用，异步调用，动态参数，可变参数，引用参数传递，多结果返回（Golang）等语言特征，Hprose 2.0 甚至支持推送。
具有良好的可扩展性，可以通过过滤器和中间件实现加密、压缩、缓存、代理等各种功能性扩展。
兼容的无差别跨语言调用
支持更多的常用语言和平台
支持浏览器端的跨域调用
没有中间语言，无需学习成本

RPC是系统间的一种通信方式，系统间常用的通信方式还有http,webservice，rpc等，一般来讲rpc比http和webservice性能高一些，常见的RPC框架有：thrift，Finagle，dubbo，grpc，json-rpc等。

一个通用的网络RPC框架，它应该包括如下功能：

1.具有服务的分层设计，借鉴Future/Service/Filter概念
2.具有网络的分层设计，区分协议层、数据层、传输层、连接层
3.独立的可适配的codec层，可以灵活增加HTTP，Memcache，Redis，MySQL/JDBC，Thrift等协议的支持。
4.将多年各种远程调用High availability的经验融入在实现中，如负载均衡，failover，多副本策略，开关降级等。
5.通用的远程调用实现，采用async方式来减少业务服务的开销，并通过future分离远程调用与数据流程的关注。
6.具有状态查看及统计功能
7.当然，最终要的是，具备以下通用的远程容错处理能力，超时、重试、负载均衡、failover……

RPC 框架有哪些？

rpcx: 基于Go的服务治理的rpc框架、客户端支持跨语言
grpc: Google 出品的跨语言rpc框架，很弱的(实验性的)负载均衡, 测试使用的是grpc-go
go std rpc: Go标准库的rpc, 不支持跨语言(jsonrpc支持json rpc 1.0)
thrift: 跨语言的rpc框架，facebook贡献
dubbo: 国内较早开源的服务治理的Java rpc框架，虽然在阿里巴巴内部竞争中落败于HSF，沉寂了几年，但是在国内得到了广泛的应用，目前dubbo项目又获得了支持，并且dubbo 3.0也开始开发
motan: 微博内部使用的rpc框架，底层支持java,生态圈往service mesh发展以支持多语言
hprose: 国内开发人员开发的一个跨语言的rpc框架，非服务治理但是性能高效
twirp: twitch.tv刚刚开源的一个restful风格的rpc框架
go-micro: Go语言的一个服务治理rpc框架， 在测试中发现性能不太好，所以没有继续测试，相关的测试代码已在github库中
go kit:
腾讯 Tars:腾讯公司的rpc框架
百度 brpc: 百度公司的rpc框架
spring cloud: