为什么要有RPC
因为，两个不同的服务器上的服务提供的方法不在一个内存空间，所以，需要通过网络编程才能传递方法调用所需要的参数。并且，方法调用的结果也需要通过网络编程来接收。但是，如果我们自己手动网络编程来实现这个调用过程的话工作量是非常大的，因为，我们需要考虑底层传输方式（TCP 还是 UDP）、序列化方式等等方面。
http接口是在接口不多、系统与系统交互较少的情况下，解决信息孤岛初期常使用的一种通信手段；优点就是简单、直接、开发方便。利用现成的http协议进行传输。但是如果是一个大型的网站，内部子系统较多、接口非常多的情况下，
RPC框架的好处就显示出来了，首先就是长链接，不必每次通信都要像http一样去3次握手什么的，减少了网络开销；其次就是RPC框架一般都有注册中心，有丰富的监控管理；发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作。第三个来说就是安全性。 后就是 近流行的服务化架构、服务化治理，RPC框架是一个强力的支撑。
socket只是一个简单的网络通信方式，只是创建通信双方的通信通道，而要实现rpc的功能，还需要对其进行封装，以实现更多的功能。
RPC一般配合netty框架、spring自定义注解来编写轻量级框架，其实netty内部是封装了socket的，较新的jdk的IO一般是NIO，即非阻塞IO，在高并发网站中，RPC的优势会很明显
什么是RPC
RPC（Remote Procedure Call Protocol）远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。简言之，RPC使得程序能够像访问本地系统资源一样，去访问远端系统资源。比较关键的一些方面包括：通讯协议、序列化、资源（接口）描述、服务框架、性能、语言支持等。
简单的说，RPC就是从一台机器(客户端)上通过参数传递的方式调用另一台机器
(服务器)上的一个函数或方法(可以统称为服务)并得到返回的结果。
RPC 能帮助我们做什么呢
一言蔽之：RPC 的出现就是为了让你调用远程方法像调用本地方法一样简单。
通过 RPC 可以帮助我们调用远程计算机上某个服务的方法，这个过程就像调用本地方法一样简单。我们不需要了解底层网络编程的具体细节。
举个例子：两个不同的服务 A、B 部署在两台不同的机器上，服务 A 如果想要调用服务 B 中的某个方法的话就可以通过 RPC 来做。
远程调用
远程调用就是本地机器调用远程机器的一个方法，远程机器返回结果的过程。
为什么要这么做？
主要原因是由于单台服务的性能已经无法满足我们了，在这个流量剧增的时代，只有多台服务器才能支撑起来现有的用户体系，
而在这种体系下，服务越来越多，逐渐演化出了现在这种微服务化的 RPC 框架。
PRC架构组件以及原理
一个基本的RPC架构里面应该至少包含以下4个组件：
1、 客户端（Client）:服务调用方（服务消费者）
2、 客户端存根（Client Stub）:存放服务端地址信息，将客户端的请求参数数据信息打包成网络消息，再通过网络传输发送给服务端
3、 服务端存根（Server Stub）:接收客户端发送过来的请求消息并进行解包，然后再调用本地服务进行处理
4、 服务端（Server）:服务的真正提供者
具体调用过程：
1、 服务消费者（client客户端）通过调用本地服务的方式调用需要消费的服务；
2、 客户端存根（client stub）接收到调用请求后负责将方法、入参等信息序列化（组装）成能够进行网络传输的消息体；
3、 客户端存根（client stub）找到远程的服务地址，并且将消息通过网络发送给服务端；
4、 服务端存根（server stub）收到消息后进行解码（反序列化操作）；
5、 服务端存根（server stub）根据解码结果调用本地的服务进行相关处理；
6、 本地服务执行具体业务逻辑并将处理结果返回给服务端存根（server stub）；
7、 服务端存根（server stub）将返回结果重新打包成消息（序列化）并通过网络发送至消费方；
8、 客户端存根（client stub）接收到消息，并进行解码（反序列化）；
9、 服务消费方得到 终结果；而RPC框架的实现目标则是将上面的第2-10步完好地封装起来，也就是把调用、编码/解码的过程给封装起来，让用户感觉上像调用本地服务一样的调用远程服务。
RPC和SOA、SOAP、REST的区别
1、REST
可以看着是HTTP协议的一种直接应用，默认基于JSON作为传输格式,使用简单, 学习成本低效率高,但是安全性较低。
2、SOAP
SOAP是一种数据交换协议规范,是一种轻量的、简单的、基于XML的协议的规范。而SOAP可以看着是一个重量级的协议，基于XML、SOAP在安全方面是通过使用XML-Security和XML-Signature两个规范组成了WS-Security来实现安全控制的,当前已经得到了各个厂商的支持 。
它有什么优点？简单总结为：易用、灵活、跨语言、跨平台。
3、SOA
面向服务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。
SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。SOA可以看作是B/S模型、XML（标准通用标记语言的子集）/Web Service技术之后的自然延伸。
4、REST 和 SOAP、RPC 有何区别呢?
没什么太大区别，他们的本质都是提供可支持分布式的基础服务， 大的区别在于他们各自的的特点所带来的不同应用场景 。
RPC框架需要解决的问题？
1、 如何确定客户端和服务端之间的通信协议？
2、 如何更高效地进行网络通信？
3、 服务端提供的服务如何暴露给客户端？
4、 客户端如何发现这些暴露的服务？
5、 如何更高效地对请求对象和响应结果进行序列化和反序列化操作？
RPC的实现基础？
1、 需要有非常高效的网络通信，比如一般选择Netty作为网络通信框架；
2、 需要有比较高效的序列化框架，比如谷歌的Protobuf序列化框架；
3、 可靠的寻址方式（主要是提供服务的发现），比如可以使用Zookeeper来注册服务等等；
4、 如果是带会话（状态）的RPC调用，还需要有会话和状态保持的功能；
RPC使用了哪些关键技术？
1、动态代理
生成Client Stub（客户端存根）和Server Stub（服务端存根）的时候需要用到 Java动态代理技术，可以使用JDK提供的原生的动态代理机制，也可以使用开源的：CGLib代理，Javassist字节码生成技术。
2、序列化和反序列化在网络中，所有的数据都将会被转化为字节进行传送，所以为了能够使参数对象在网络中进行传输，需要对这些参数进行序列化和反序列化操作。
- 序列化：把对象转换为字节序列的过程称为对象的序列化，也就是编码的过程。
- 反序列化：把字节序列恢复为对象的过程称为对象的反序列化，也就是解码的过程。
目前比较高效的开源序列化框架：如Kryo、FastJson和Protobuf等。
1、NIO通信
出于并发性能的考虑，传统的阻塞式 IO 显然不太合适，因此我们需要异步的
IO，即 NIO。Java 提供了 NIO 的解决方案，Java 7 也提供了更优秀的 NIO.2 支持。可以选择Netty或者MINA来解决NIO数据传输的问题。
2、服务注册中心
可选：Redis、Zookeeper、Consul 、Etcd。一般使用ZooKeeper提供服务注册与发现功能，解决单点故障以及分布式部署的问题(注册中心)。
主流RPC框架有哪些
1、RMI
利用java.rmi包实现，基于Java远程方法协议(Java Remote Method Protocol) 和java的原生序列化。
2、Hessian
是一个轻量级的remoting onhttp工具，使用简单的方法提供了RMI的功能。 基于HTTP协议，采用二进制编解码。
3、protobuf-rpc-pro是一个Java类库，提供了基于 Google 的 Protocol Buffers 协议的远程方法调用的框架。基于 Netty 底层的 NIO 技术。支持 TCP 重用/ keep-alive、SSL加密、RPC 调用取消操作、嵌入式日志等功能。
4、Thrift
是一种可伸缩的跨语言服务的软件框架。它拥有功能强大的代码生成引擎，无缝地支持C + +，C#，Java，Python和PHP和Ruby。thrift允许你定义一个描述
文件，描述数据类型和服务接口。依据该文件，编译器方便地生成RPC客户端和服务器通信代码。
初由facebook开发用做系统内个语言之间的RPC通信，2007年由facebook 贡献到apache基金 ，现在是apache下的opensource之一 。支持多种语言之间的RPC方式的通信：php语言client可以构造一个对象，调用相应的服务方法
来调用java语言的服务，跨越语言的C/S RPC调用。底层通讯基于SOCKET。
5、Avro
出自Hadoop之父Doug Cutting, 在Thrift已经相当流行的情况下推出Avro的目标不仅是提供一套类似Thrift的通讯中间件,更是要建立一个新的，标准性的云计算的数据交换和存储的Protocol。支持HTTP，TCP两种协议。
6、Dubbo
Dubbo是 阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高
性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。
RPC的实现原理架构图
PS：这张图非常重点，是PRC的基本原理，请大家一定记住！也就是说两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的函数/方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。
比如说，A服务器想调用B服务器上的一个方法：
User getUserByName(String userName)
1、建立通信首先要解决通讯的问题：即A机器想要调用B机器，首先得建立起通信连接。
主要是通过在客户端和服务器之间建立TCP连接，远程过程调用的所有交换的数据都在这个连接里传输。连接可以是按需连接，调用结束后就断掉，也可以是长连接，多个远程过程调用共享同一个连接。
通常这个连接可以是按需连接（需要调用的时候就先建立连接，调用结束后就立马断掉），也可以是长连接（客户端和服务器建立起连接之后保持长期持有，不管此时有无数据包的发送，可以配合心跳检测机制定期检测建立的连接是否存活有效），多个远程过程调用共享同一个连接。
2、服务寻址要解决寻址的问题，也就是说，A服务器上的应用怎么告诉底层的RPC框架，如何连接到B服务器（如主机或IP地址）以及特定的端口，方法的名称名称是什么。
通常情况下我们需要提供B机器（主机名或IP地址）以及特定的端口，然后指定调用的方法或者函数的名称以及入参出参等信息，这样才能完成服务的一个调用。
可靠的寻址方式（主要是提供服务的发现）是RPC的实现基石，比如可以采用
Redis或者Zookeeper来注册服务等等。
2.1、 从服务提供者的角度看：当服务提供者启动的时候，需要将自己提供的服务注册到指定的注册中心，以便服务消费者能够通过服务注册中心进行查找；当服务提供者由于各种原因致使提供的服务停止时，需要向注册中心注销停止的服务；服务的提供者需要定期向服务注册中心发送心跳检测，服务注册中心如果一段时间未收到来自服务提供者的心跳后，认为该服务提供者已经停止服务，则将该服务从注册中心上去掉。
2.2、 从调用者的角度看：服务的调用者启动的时候根据自己订阅的服务向服务注册中心查找服务提供者的地址等信息；当服务调用者消费的服务上线或者下线的时候，注册中心会告知该服务的调用者；服务调用者下线的时候，则取消订阅。
3、网络传输3.1、序列化
当A机器上的应用发起一个RPC调用时，调用方法和其入参等信息需要通过底层的网络协议如TCP传输到B机器，由于网络协议是基于二进制的，所有我们传输的参数数据都需要先进行序列化（Serialize）或者编组（marshal）成二进制的形式才能在网络中进行传输。然后通过寻址操作和网络传输将序列化或者编组之后的二进制数据发送给B机器。
3.2、反序列化
当B机器接收到A机器的应用发来的请求之后，又需要对接收到的参数等信息进行反序列化操作（序列化的逆操作），即将二进制信息恢复为内存中的表达方
式，然后再找到对应的方法（寻址的一部分）进行本地调用（一般是通过生成代理Proxy去调用,
通常会有JDK动态代理、CGLIB动态代理、Javassist生成字节码技术等），之后得到调用的返回值。
4、服务调用
B机器进行本地调用（通过代理Proxy和反射调用）之后得到了返回值，此时还需要再把返回值发送回A机器，同样也需要经过序列化操作，然后再经过网络传输将二进制数据发送回A机器，而当A机器接收到这些返回值之后，则再次进行反序列化操作，恢复为内存中的表达方式， 后再交给A机器上的应用进行相关处理（一般是业务逻辑处理操作）。通常，经过以上四个步骤之后，一次完整的RPC调用算是完成了，另外可能因为网络抖动等原因需要重试等。
怎么设计一个 RPC 框架
关于这个问题，其实核心考察点就是你对于 RPC 框架的理解，一个成熟的 RPC 框架可以完成哪些功能，其实当我们看过一两个 RPC 框架后，就可以对这个问题回答个七七八八了，我们来举个例子。
首先我们得需要一个注册中心，去管理消费者和提供者的节点信息，这样才会有消费者和提供才可以去订阅 服务，注册服务。
当有了注册中心后，可能会有很多个 provider 节点，那么我们肯定会有一个负载均衡模块来负责节点的调用，至于用户指定路由规则可以使一个额外的优化点。
具体的调用肯定会需要牵扯到通信协议，所以需要一个模块来对通信协议进行封装，网络传输还要考虑序列化。
当调用失败后怎么去处理？所以我们还需要一个容错模块，来负责失败情况的处理。
其实做完这些一个基础的模型就已经搭建好了，我们还可以有更多的优化点，比如一些请求数据的监控，配置信息的处理，日志信息的处理等等。
这其实就是一个比较基本的 RPC 框架的大体思路，大家有没有 get 到？
RPC与Http的区别
无论是微服务还是分布式服务（都是 SOA，都是面向服务编程），都面临着服务间的远程调用。那么服务间的远程调用方式有哪些呢？
常见的远程调用方式有以下几种：
- RPC：Remote Produce Call 远程过程调用，类似的还有 RMI（Remote Methods Invoke 远程方法调用，是 JAVA 中的概念，是 JAVA 十三大技术之一）。自定义数据格式，基于原生 TCP 通信，速度快，效率高。早期的 webservice，现在热门的 dubbo，都是 RPC 的典型
- RPC 的框架：webservie(cxf)、dubbo
- RMI 的框架：hessian
- Http：http 其实是一种网络传输协议，基于 TCP，规定了数据传输的格式。现在客户端浏览器与服务端通信基本都是采用 Http 协议。也可以用来进行远程服务调用。缺点是消息封装臃肿。
现在热门的 Rest 风格，就可以通过 http 协议来实现。- http 的实现技术：HttpClient
- 相同点：底层通讯都是基于 socket，都可以实现远程调用，都可以实现服务调用服务
- 不同点：
RPC：框架有：dubbo、cxf、（RMI 远程方法调用）Hessian
当使用 RPC 框架实现服务间调用的时候，要求服务提供方和服务消费方 都必须使用统一的 RPC 框架，要么都 dubbo，要么都 cxf
跨操作系统在同一编程语言内使用
优势：调用快、处理快
http：框架有：httpClient
当使用 http 进行服务间调用的时候，无需关注服务提供方使用的编程语言，也无需关注服务消费方使用的编程语言，服务提供方只需要提供 restful 风格的接口，服务消费方，按照 restful 的原则，请求服务，即可
跨系统跨编程语言的远程调用框架
优势：通用性强
总结：对比 RPC 和 http 的区别
1 RPC 要求服务提供方和服务调用方都需要使用相同的技术，要么都 hessian，要么都 dubbo
而 http 无需关注语言的实现，只需要遵循 rest 规范
2 RPC 的开发要求较多，像 Hessian 框架还需要服务器提供完整的接口代码 (包名. 类名. 方法名必须完全一致)，否则客户端无法运行
3 Hessian 只支持 POST 请求
4 Hessian 只支持 JAVA 语言
1.1. 认识 RPC
RPC，即 Remote Procedure Call（远程过程调用），是一个计算机通信协议。 该协议允许运行于一台计算机的程序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。说得通俗一点就是：A 计算机提供一个服务，B 计算机可以像调用本地服务那样调用 A 计算机的服务。
通过上面的概念，我们可以知道，实现 RPC 主要是做到两点：
- 实现远程调用其他计算机的服务
- 要实现远程调用，肯定是通过网络传输数据。A 程序提供服务，B 程序通过网络将请求参数传递给 A，A 本地执行后得到结果，再将结果返回给 B 程序。这里需要关注的有两点：
- 1）采用何种网络通讯协议？
- 现在比较流行的 RPC 框架，都会采用 TCP 作为底层传输协议
- 2）数据传输的格式怎样？
- 两个程序进行通讯，必须约定好数据传输格式。就好比两个人聊天，要用同一种语言，否则无法沟通。所以，我们必须定义好请求和响应的格式。另外，数据在网路中传输需要进行序列化，所以还需要约定统一的序列化的方式。
- 1）采用何种网络通讯协议？
- 要实现远程调用，肯定是通过网络传输数据。A 程序提供服务，B 程序通过网络将请求参数传递给 A，A 本地执行后得到结果，再将结果返回给 B 程序。这里需要关注的有两点：
- 像调用本地服务一样调用远程服务
- 如果仅仅是远程调用，还不算是 RPC，因为 RPC 强调的是过程调用，调用的过程对用户而言是应该是透明的，用户不应该关心调用的细节，可以像调用本地服务一样调用远程服务。所以 RPC 一定要对调用的过程进行封装
RPC 调用流程图：
1.2. 认识 Http
Http 协议：超文本传输协议，是一种应用层协议。规定了网络传输的请求格式、响应格式、资源定位和操作的方式等。但是底层采用什么网络传输协议，并没有规定，不过现在都是采用 TCP 协议作为底层传输协议。说到这里，大家可能觉得，Http 与 RPC 的远程调用非常像，都是按照某种规定好的数据格式进行网络通信，有请求，有响应。没错，在这点来看，两者非常相似，但是还是有一些细微差别。
- RPC 并没有规定数据传输格式，这个格式可以任意指定，不同的 RPC 协议，数据格式不一定相同。
- Http 中还定义了资源定位的路径，RPC 中并不需要
- 最重要的一点：RPC 需要满足像调用本地服务一样调用远程服务，也就是对调用过程在 API 层面进行封装。Http 协议没有这样的要求，因此请求、响应等细节需要我们自己去实现。
- 优点：RPC 方式更加透明，对用户更方便。Http 方式更灵活，没有规定 API 和语言，跨语言、跨平台
- 缺点：RPC 方式需要在 API 层面进行封装，限制了开发的语言环境。
例如我们通过浏览器访问网站，就是通过 Http 协议。只不过浏览器把请求封装，发起请求以及接收响应，解析响应的事情都帮我们做了。如果是不通过浏览器，那么这些事情都需要自己去完成。
1.3. 如何选择？
既然两种方式都可以实现远程调用，我们该如何选择呢？
- 速度来看，RPC 要比 http 更快，虽然底层都是 TCP，但是 http 协议的信息往往比较臃肿
- 难度来看，RPC 实现较为复杂，http 相对比较简单
- 灵活性来看，http 更胜一筹，因为它不关心实现细节，跨平台、跨语言。
因此，两者都有不同的使用场景：
- 如果对效率要求更高，并且开发过程使用统一的技术栈，那么用 RPC 还是不错的。
- 如果需要更加灵活，跨语言、跨平台，显然 http 更合适
那么我们该怎么选择呢？
微服务，更加强调的是独立、自治、灵活。而 RPC 方式的限制较多，因此微服务框架中，一般都会采用基于 Http 的 Rest 风格服务。
原文地址
https://www.cnblogs.com/helloworldmybokeyuan/p/11626833.html
若有收获，就点个赞吧
0 人点赞
