文章目录

一、概述
二、RPC
- 2.1、RPC定义
- 2.2、RPC主要组成部分
三、影响RPC框架性能的因素
四、问题
- 1.面试官：公司使用什么 RPC 框架？，可以介绍一下 RPC 的工作原理吗？
- 2.面试官：服务启动的时候服务基本信息被注册到注册中心，如果服务提供者挂了，注册中心如何知道服务不可用了呢？
- 3.面试官：如果注册中心挂了，比如你用的是 Zookeeper，如果 Zookeeper 挂了，那服务之间还能相互调用吗？
- 4.面试官：你对 RPC 了解的很透彻，那你能否自己写一个 RPC 框架？可以简答描述下思路也行。
- 5.深入分析已经有 http 协议接口，或者说 RestFul 接口，为什么还要使用 RPC 技术？
- 6.总结
五、RPC 和 HTTP 理解
- 1.详解
- 2.解答
- 3.不单效率那么简单
- 4.RPC 底层是怎么实现的

一、概述

随着公司规模的扩大，以及业务量的激增，单体应用逐步演化为服务/微服务的架构模式，服务之间的调用大多采用rpc的方式调用，或者消息队列的方式进行解耦。几乎每个大厂都会创建自己的rpc框架，或者基于知名的rpc框架进行改造。

目前, rpc框架主要沿着两条路线发展，一个是目标为了跨语言，服务端可以用不同的语言实现，客户端也可以用不同的语言实现，不同的语言实现的客户端和服务器端可以互相调用。很显然，要支持不同的语言，需要基于那种语言实现相同协议的框架，并且协议设计应该也是跨语言的，其中比较典型的是 grpc,基于同一个IDL，可以生成不同语言的代码，并且语言的支持也非常的多。

另一个rpc框架发展的目标是支持服务治理，主要的精力放在服务发现、路由、容错处理等方面，主要围绕一个语言开发，可能也有一些第三方曲折的实现服务的调用和服务的实现，这其中的代表，也是比较早的开源的框架就是阿里巴巴的dubbo。

有些rpc框架协议的涉及一开始就没有考虑的跨语言，其中使用了语言的一些特有的属性，比如Java的ObjectInputStream/ObjectOutputStream, Golang的Gob等，有些在协议的设计上就考虑了通用性，使用JSON或者Protobuffer作为数据序列化。

有些框架是基于TCP的二进制流的数据传输，有些基于http的request/response模型进行请求，也有基于http2的流式传输，更有一些支持可信赖的UDP进行数据传入，比如quic、kcp等。

有些提供了生态圈的一些框架，比如gateway、agent等，有些restful风格的rpc框架天然支持API gateway进行负载均衡。

二、RPC

2.1、RPC定义

RPC（Remote Procedure Call Protocol）远程过程调用协议。一个通俗的描述是：客户端在不知道调用细节的情况下，调用存在于远程计算机上的某个对象，就像调用本地应用程序中的对象一样。比较正式的描述是：一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。那么我们至少从这样的描述中挖掘出几个要点：

RPC是协议：既然是协议就只是一套规范，那么就需要有人遵循这套规范来进行实现。目前典型的RPC实现包括：Dubbo、Thrift、GRPC、Hetty等。这里要说明一下，目前技术的发展趋势来看，实现了RPC协议的应用工具往往都会附加其他重要功能，例如Dubbo还包括了服务治等功能。
网络协议和网络IO模型对其透明：既然RPC的客户端认为自己是在调用本地对象。那么传输层使用的是TCP/UDP还是HTTP协议，又或者是一些其他的网络协议它就不需要关心了。既然网络协议对其透明，那么调用过程中，使用的是哪一种网络IO模型调用者也不需要关心。
信息格式对其透明：我们知道在本地应用程序中，对于某个对象的调用需要传递一些参数，并且会返回一个调用结果。至于被调用的对象内部是如何使用这些参数，并计算出处理结果的，调用方是不需要关心的。那么对于远程调用来说，这些参数会以某种信息格式传递给网络上的另外一台计算机，这个信息格式是怎样构成的，调用方是不需要关心的。
应该有跨语言能力：为什么这样说呢？因为调用方实际上也不清楚远程服务器的应用程序是使用什么语言运行的。那么对于调用方来说，无论服务器方使用的是什么语言，本次调用都应该成功，并且返回值也应该按照调用方程序语言所能理解的形式进行描述。

那么上面的描述情况可以用下图表示：

2.2、RPC主要组成部分

当然，上图是作为RPC的调用者所观察到的现象（而实际情况是客户端或多或少的还是需要知道一些调用RPC的细节）。但是我们是要讲解RPC的基本概念，所以RPC协议内部是怎么回事就要说清楚：

Client：RPC协议的调用方。就像上文所描述的那样，最理想的情况是RPC Client在完全不知道有RPC框架存在的情况下发起对远程服务的调用。但实际情况来说Client或多或少的都需要指定RPC框架的一些细节。
Server：在RPC规范中，这个Server并不是提供RPC服务器IP、端口监听的模块。而是远程服务方法的具体实现（在JAVA中就是RPC服务接口的具体实现）。其中的代码是最普通的和业务相关的代码，甚至其接口实现类本身都不知道将被某一个RPC远程客户端调用。
Stub/Proxy：RPC代理存在于客户端，因为要实现客户端对RPC框架“透明”调用，那么客户端不可能自行去管理消息格式、不可能自己去管理网络传输协议，也不可能自己去判断调用过程是否有异常。这一切工作在客户端都是交给RPC框架中的“代理”层来处理的。
Message Protocol：在上文我们已经说到，一次完整的client-server的交互肯定是携带某种两端都能识别的，共同约定的消息格式。RPC的消息管理层专门对网络传输所承载的消息信息进行编码和解码操作。目前流行的技术趋势是不同的RPC实现，为了加强自身框架的效率都有一套（或者几套）私有的消息格式。
Transfer/Network Protocol：传输协议层负责管理RPC框架所使用的网络协议、网络IO模型。例如Hessian的传输协议基于HTTP（应用层协议）；而Thrift的传输协议基于TCP（传输层协议）。传输层还需要统一RPC客户端和RPC服务端所使用的IO模型；
Selector/Processor：存在于RPC服务端，用于服务器端某一个RPC接口的实现的特性（它并不知道自己是一个将要被RPC提供给第三方系统调用的服务）。所以在RPC框架中应该有一种“负责执行RPC接口实现”的角色。包括：管理RPC接口的注册、判断客户端的请求权限、控制接口实现类的执行在内的各种工作。
IDL：实际上IDL（接口定义语言）并不是RPC实现中所必须的。但是需要跨语言的RPC框架一定会有IDL部分的存在。这是因为要找到一个各种语言能够理解的消息结构、接口定义的描述形式。如果您的RPC实现没有考虑跨语言性，那么IDL部分就不需要包括，例如JAVA RMI因为就是为了在JAVA语言间进行使用，所以JAVA RMI就没有相应的IDL。

一定要说明一点，不同的RPC框架实现都有一定设计差异。例如生成Stub的方式不一样，IDL描述语言不一样、服务注册的管理方式不一样、运行服务实现的方式不一样、采用的消息格式封装不一样、采用的网络协议不一样。但是基本的思路都是一样的，上图中的所列出的要素也都是具有的。

三、影响RPC框架性能的因素

在物理服务器性能相同的情况下，以下几个因素会对一款RPC框架的性能产生直接影响：

使用的网络IO模型：RPC服务器可以只支持传统的阻塞式同步IO，也可以做一些改进让RPC服务器支持非阻塞式同步IO，或者在服务器上实现对多路IO模型的支持。这样的RPC服务器的性能在高并发状态下，会有很大的差别。特别是单位处理性能下对内存、CPU资源的使用率。
基于的网络协议：一般来说您可以选择让您的RPC使用应用层协议，例如HTTP或者HTTP/2协议，或者使用TCP协议，让您的RPC框架工作在传输层。工作在哪一层网络上会对RPC框架的工作性能产生一定的影响，但是对RPC最终的性能影响并不大。但是至少从各种主流的RPC实现来看，没有采用UDP协议做为主要的传输协议的。
消息封装格式：选择或者定义一种消息格式的封装，要考虑的问题包括：消息的易读性、描述单位内容时的消息体大小、编码难度、解码难度、解决半包/粘包问题的难易度。当然如果您只是想定义一种RPC专用的消息格式，那么消息的易读性可能不是最需要考虑的。消息封装格式的设计是目前各种RPC框架性能差异的最重要原因，这就是为什么几乎所有主流的RPC框架都会设计私有的消息封装格式的原因。dubbo中消息体数据包含dubbo版本号、接口名称、接口版本、方法名称、参数类型列表、参数、附加信息
Schema 和序列化（Schema & Data Serialization）：序列化和反序列化，是对象到二进制数据的转换，程序是可以理解对象的，对象一般含有 schema 或者结构，基于这些语义来做特定的业务逻辑处理。考察一个序列化框架一般会关注以下几点： Encoding format 。是 human readable（是否能直观看懂 json）还是 binary(二进制)。 Schema declaration 。也叫作契约声明，基于 IDL，比如 Protocol Buffers/Thrift，还是自描述的，比如 JSON、XML。另外还需要看是否是强类型的。 语言平台的中立性 。比如 Java 的 Native Serialization 就只能自己玩，而 Protocol Buffers 可以跨各种语言和平台。 新老契约的兼容性 。比如 IDL 加了一个字段，老数据是否还可以反序列化成功。 和压缩算法的契合度 。跑 benchmark (基准)和实际应用都会结合各种压缩算法，例如 gzip、snappy。性能。这是最重要的，序列化、反序列化的时间，序列化后数据的字节大小是考察重点。序列化方式非常多，常见的有 Protocol Buffers， Avro，Thrift，XML，JSON，MessagePack，Kyro，Hessian，Protostuff，Java Native Serialize，FST 。
实现的服务处理管理方式：在高并发请求下，如何管理注册的服务也是一个性能影响点。您可以让RPC的Selector/Processor使用单个线程运行服务的具体实现（这意味着上一个客户端的请求没有处理完，下一个客户端的请求就需要等待）、您也可以为每一个RPC具体服务的实现开启一个独立的线程运行（可以一次处理多个请求，但是操作系统对于“可运行的最大线程数”是有限制的）、您也可以线程池来运行RPC具体的服务实现（目前看来，在单个服务节点的情况下，这种方式是比较好的）、您还可以通过注册代理的方式让多个服务节点来运行具体的RPC服务实现。

四、问题

1.面试官：公司使用什么 RPC 框架？，可以介绍一下 RPC 的工作原理吗？

问题分析： 面试官想了解基础设施是否和我们项目用的一样，一样最好了，能直接上手，不一样了解其它一个别的应该也问题不大，毕竟原理技术都大同小异，说你最熟悉的一个。

**答：**RPC 是一个分布式计算的 CS 模式，总是由 Client 向 Server 发出一个执行若干过程请求，Server 接受请求，使用者客户端提供的参数，计算完成之后将结果返回给客户端。

使用最广泛的 Spring Cloud，基于 Spring Boot 特性整合了开源行业中优秀的组件，整体对外提供了一套在微服务架构中服务治理的解决方案。

国内开源的框架中，使用比较广泛的有阿里的 Dubbo，后来捐献给了 Apache。还有腾讯的 Tars 框架，还有 Thrift 框架，也有基于 Thrift 二次开发的 RPC 框架，比如美团的 Mtthrift。

这些 RPC 大致原理基本都是一样的。（这个时候，跟面试官要纸和笔，画图解释 RPC 原理）

这个图既不显得太过复杂给自己挖坑，也不会显得简单潦草。

1-5 逐行解释：

服务集成 RPC 后，服务（这里的服务就是图中的 Provider，服务提供者）启动后会通过 Register（注册）模块，把服务的唯一 ID 和 IP 地址，端口信息等注册到 RPC 框架注册中心（图中的 Registry 部分）。
当调用者（Consumer）想要调用服务的时候，通过 Provider 注册时的的服务唯一 ID 去注册中心查找在线可供调用的服务，返回一个 IP 列表（3.notify 部分）。
第三步 Consumer 根据一定的策略，比如随机 or 轮训从 Registry 返回的可用 IP 列表真正调用服务（4.invoke）。
最后是统计功能，RPC 框架都提供监控功能，监控服务健康状况，控制服务线上扩展和上下线（5.count）

有清晰的流程图，有每一步的解释，面试官表示很满意，继续追加提问。

2.面试官：服务启动的时候服务基本信息被注册到注册中心，如果服务提供者挂了，注册中心如何知道服务不可用了呢？

答：服务掉线分为主动下线和心跳检测

比如服务由于发版时，在重启之前先主动通知注册中心：我要重启了，有流量进来先不要分给我，让别的机器服务，等我重启成功后在放流量进来，或者是在管理后台手动直接摘掉机器，这个是主动下线。

心跳检测是处理服务非正常下线（如断电断网）的情况，这个时候如果注册中心不知道该服务已经掉线，一旦被其调用就会带来问题。为了避免出现这样的情况，注册中心增加一个心跳检测功能，它会对服务提供者（Provider）进行心跳检测，比如每隔 30s 发送一个心跳，如果三次心跳结果都没有返回值，就认为该服务已下线，赶紧更新 Consumer 的服务列表，告诉 Consumer 调用别的机器。

问题分析： 阐述了服务端挂了注册中心如何感知的问题，你以为此问题已经完事儿了？还没有，你成功给自己挖了个坑，面试官可能继续深挖，服务提供者（Provider）挂了注册中心能解决，那注册中心自己就不挂了吗？三连问继续。

3.面试官：如果注册中心挂了，比如你用的是 Zookeeper，如果 Zookeeper 挂了，那服务之间还能相互调用吗？

** 答：**首先注册中心挂掉也要分两种情况，如果数据库挂了，ZK 还是能用的，因为 ZK 会缓存注册机列表在缓存里。

其次 ZK 本身就是一个集群的，一台机器挂了，ZK 会选举出集群中的其他机器作为 Master 继续提供服务，如果整个集群都挂了也没问题，因为调用者本地会缓存注册中心获取的服务列表。省略和注册中心的交互，Consumer 和 Provider 采用直连方式，这些策略都是可配置的。

问题分析： 面试是一个自由交流时间，任何一个点都可能被发散继续深入挖掘，刨根问题，总有你覆盖不到的知识盲区，目的不是为难你，是想了解你的技术沉淀深度。

4.面试官：你对 RPC 了解的很透彻，那你能否自己写一个 RPC 框架？可以简答描述下思路也行。

**答：**这个问题，虽然没有自己动手写过，但是我阅读过源码，大致实现思路是这样的。（画图给面试官）

客户端 invoke 方法编写，使用 JDK 的动态代理技术，客户端调用远程服务方法时调用的是 InvocationHandler 的 invoke 方法。
客户端 Filter 方法编写，完善的 RPC 框架少不了监控、路由、降级、鉴权等功能。
创建 Socket，在 Filter 方法中实现 Client.write 方法，其逻辑为从连接池（ChannelPool）中获取连接，然后将数据写进 Channel。
实现数据序列化、压缩，目的减少网络传输的数据量，向服务端发送 request 数据，这里可以使用 Netty 异步通讯框架。
服务端收到客户端发过的消息后，从 Channel 中将消息读出来之前，也会先经反序列化解压。
请求就到了服务端 Filter 中。请求依次经过监控、鉴权方法。
根据客户端传递来的服务信息和参数，通过反射调用相应的业务服务并拿到业务处理结果。然后在 ResponseFilter 中将返回结果写入 Channel。
服务端序列化、压缩等，发送给客户端。
客户端收到消息后，经过客户端反序列化、解压缩，后交给 ResponseThreadPoolProcessor 线程池处理。
ResponseThreadPoolProcessor 收到消息后，就将结果返回给之前的方法调用，整个调用请求就结束了。

面试官： 可以可以，确实是看了，这个问题就到这。（面试官心理：虽然目前项目里不会让你真正去写一个 RPC 框架，知其然知其所以然，遇到这类 RPC 相关问题一定能搞定了，项目组正好缺一个这样的人）

5.深入分析已经有 http 协议接口，或者说 RestFul 接口，为什么还要使用 RPC 技术？

在接⼝不多的情况下，使用 http 确实是一个明智的选择，比如在初创企业，我们不确定业务能顺利开展下去，可能面临随时倒闭，开发人员也不足，这个时候使用简洁高效的技术，先把东西做出来是最明智的选择，无需一步登天。

系统与系统交互较少的情况下，使用 http 协议优点显而易见：开发简单、测试也比较直接、部署方便，利用现成的 http 协议进行系统间通讯，如果业务真的慢慢做大，系统也慢慢扩大，RPC 框架的好处就显示出来了，⾸先 RPC 支持长链接，通信不必每次都要像 http 一样去重复 3 次握⼿，减少了网络开销。

其次就是 RPC 框架一般都有注册中心模块，有完善的监控管理功能，服务注册发现、服务下线、服务动态扩展等都方便操作，服务化治理效率大大提高。

基于 TCP 协议实现的 RPC，能更灵活地对协议字段进行定制，相比 http 能减少网络传输字节数，降低网络开销（握手）提高性能。实现更大的吞吐量和并发数，但是需要更多的关注底层复杂的细节，对开发人员的要求也高，增加开发成本。

6.总结

在面试官夺命三连问的攻击下，前三个题目一定要掌握，最后一个加分项徒手写 RPC 深入分析，可以大大拉升面试官对你的好感，只要有亮点，即使其他问题答得不好，那么问题也不大。

RPC 工作原理总结：

Provider：服务提供方，CS 模型中的 Server。
Consumer：调用远程服务服务消费方，CS 模型中的 Client。
Registry：服务注册与发现的服务管理中心。
Monitor：统计服务的调用次数和调用时间的监控中心。
Container：服务运行容器，如 jetty。

RPC 执行过程总结：

服务容器负责启动，加载，运行服务提供者。
服务提供者在启动时，向注册中心注册自己提供的服务，暴露自己的 IP 和端口信息。
服务消费者在启动时，向注册中心订阅自己所需的服务。
注册中心返回服务提供者列表给消费者，如果有变更，注册中心将基于长连接推送给数据消费者。
服务消费者，从提供这地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另外一台服务调用。
服务消费者和提供者，在内存中累计调用次数和调用时间，定时发送一次统计数据到监控中心。

五、RPC 和 HTTP 理解

网上充斥着各类类似于这样的文章：rpc 比 http 快了多少倍？既然有了 http，为什么还要用 rpc 调用等等。遇到这类文章，说明对 http 和 rpc 是由理解误区的。

这里再次重复强调一遍，通信协议不是 rpc 最重要的部分，不要被这类回答带偏。如果要了解 rpc 请更多的去了解服务治理(SOA)的一些基本策略，推荐去看看 dubbo 的相关文档。

1.详解

rpc是远端过程调用，其调用协议通常包含：传输协议和序列化协议。

传输协议：

比如著名的 grpc，它底层使用的是 http2 协议；还有 dubbo 一类的自定义报文的 tcp 协议

序列化协议：

例如基于文本编码的 json 协议；也有二进制编码的 protobuf、hession 等协议；还有针对 java 高性能、高吞吐量的 kryo 和 ftc 等序列化协议

因此我理解大部人理解误区的问题应该是：为什么要使用自定义 tcp 协议的 rpc 做后端进程通信？

2.解答

要解决这个问题就应该搞清楚 http 使用的 tcp 协议，和我们自定义的 tcp 协议在报文上的区别。

首先要否认一点 http 协议相较于自定义tcp 报文协议，增加的开销在于连接的建立与断开。

第一、http协议是支持连接池复用的，也就是建立一定数量的连接不断开，并不会频繁的创建和销毁连接

第二、http也可以使用 protobuf 这种二进制编码协议对内容进行编码

因此二者即 http 和 rpc 最大的区别还是在传输协议上

通用定义的http1.1协议的tcp报文包含太多废信息，一个POST协议的格式大致如下

HTTP/1.0 200 OK
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84<html><body>Hello World</body>
</html>

即使编码协议也就是 body 是使用二进制编码协议，报文元数据也就是header头的键值对却使用了文本编码，非常占字节数。如上图所使用的报文中有效字节数仅仅占约 30%，也就是70%的时间用于传输元数据废编码。当然实际情况下报文内容可能会比这个长，但是报头所占的比例也是非常可观的。

那么假如我们使用自定义tcp协议的报文如下

报头占用的字节数也就只有16个byte，极大地精简了传输内容。

这也就是为什么后端进程间通常会采用自定义tcp协议的 rpc 来进行通信的原因。

3.不单效率那么简单

所谓的效率优势是针对 http1.1协议来讲的，http2.0协议已经优化编码效率问题，像 grpc 这种 rpc 库使用的就是 http2.0协议。这么来说吧，http容器的性能测试单位通常是kqps，自定义tpc协议则通常是以 10kqps 到 100kqps 为基准

简单来说成熟的 rpc库相对 http容器，更多的是封装了 “服务发现”，“负载均衡”，“熔断降级” 一类面向服务的高级特性。可以这么理解，rpc框架是面向服务的更高级的封装。如果把一个http servlet 容器上封装一层服务发现和函数代理调用，那它就已经可以做一个rpc框架了。

所以为什么要用rpc调用？

因为良好的 rpc 调用是面向服务的封装，针对服务的可用性和效率等都做了优化。单纯使用http调用则缺少了这些特性。

可以这样说：用http不是因为它性能好，而是因为它普适，随便一个web容器就能跑起来你的应用。

4.RPC 底层是怎么实现的

之前有看过几个帖子，评论区有激烈的争吵，主要围绕两点，具体如下：

1. HTTP 和 RPC 是同一级别，还是被 RPC 包含？

2. Restful 也属于 RPC 吗？

对于以上两个问题，这里用一个图来一一说明：

上图是一个比较完整的关系图，这时我们发现HTTP（图中蓝色框）出现了两次。

其中一个是和 RPC并列的，都是跨应用调用方法的解决方案；

另一个则是被RPC包含的，是RPC通信过程的可选协议之一。

因此，第一个问题的答案是都对。看指的是哪一个蓝色框。从题主的提问看，既然题主在纠结这两者，应该是指与RPC并列的蓝色框。

第二个问题是在问远程过程调用（红色框）是不是包含了Restful（黄色框），这种理解的关键在于对RPC的理解。

RPC字面理解是"远程过程调用"，即在一个应用中调用另一个应用的方法。那Restful是满足的，通过它可以实现在一个应用中调用另一个应用的方法。

但是，上述理解使得RPC的定义过于宽泛。RPC通常特指在一个应用中调用另一个应用的接口而实现的远程调用，即红色框所指的范围。这样，RPC是不包含Restful的。

因此，第二个问题的答案是Restful不属于RPC。

RPC的英文全称是：Remote Procedure Call，翻译为中文叫 “远程过程调用”。其中稍显晦涩的其实就是“过程”，过程其实就是“方法”。所以，可以把RPC理解为“远程方法调用”。

要了解远程过程调用，那先理解过程调用。非常简单，如下图，就是调用一个方法。这太常见了，不多解释。

而在分布式系统中，因为每个服务的边界都很小，很有可能调用别的服务提供的方法。这就出现了服务A 调用服务B 中方法的需求，即远程过程调用。

要想让服务A 调用服务B 中的方法，最先想到的就是通过 HTTP 请求实现。是的，这是很常见的，例如服务B 暴露 Restful接口，然后让服务A 调用它的接口。基于Restful的调用方式因为可读性好（服务B暴露出的是Restful接口，可读性当然好）而且HTTP请求可以通过各种防火墙，因此非常不错。

然而，如前面所述，基于Restful的远程过程调用有着明显的缺点，主要是效率低、封装调用复杂。当存在大量的服务间调用时，这些缺点变得更为突出。

服务A 调用服务B 的过程是应用间的内部过程，牺牲可读性提升效率、易用性是可取的。基于这种思路，RPC产生了。

通常，RPC要求在调用方中放置被调用的方法的接口。调用方只要调用了这些接口，就相当于调用了被调用方的实际方法，十分易用。于是，调用方可以像调用内部接口一样调用远程的方法，而不用封装参数名和参数值等操作。
　
那要想实现这个过程该怎么办呢？别急，咱们一步一步来。

第一、首先，调用方调用的是接口，必须得为接口构造一个假的实现。显然，要使用动态代理。这样，调用方的调用就被动态代理接收到了。

第二、动态代理接收到调用后，应该想办法调用远程的实际实现。这包括下面几步：

1. 识别具体要调用的远程方法的 IP、端口

2. 将调用方法的入参进行序列化

3. 通过通信将请求发送到远程的方法中

第三、这样，远程的服务就接收到了调用方的请求。它应该：

1. 反序列化各个调用参数

2. 定位到实际要调用的方法，然后输入参数，执行方法

3. 按照调用的路径返回调用的结果

整个过程如下所示。

这样，RPC操作就完成了。

调用方调用内部的一个方法，但是被RPC框架偷梁换柱为远程的一个方法。之间的通信数据可读性不需要好，只需要RPC框架能读懂即可，因此效率可以更高。通常使用UDP或者TCP作为通讯协议，当然也可以使用HTTP。

【RPC】RPC和Http的理解相关推荐

面试精讲之面试考点及大厂真题 - 分布式专栏 05 公司使用什么RPC框架，聊聊你理解的RPC原理
05 公司使用什么RPC框架,聊聊你理解的RPC原理引言前些年我们在做一个规模不大的系统的时候,也就是单体架构,一台服务器部署上一个应用和数据库也就够了.但是现代化互联网公司业务逐渐扩大,服务逐渐 ...
Outlook通过RPC/RPC Over HTTPS访问Exchange邮箱
上一篇博文介绍了一些邮箱的简单配置,这篇我们介绍Outlook通过RPC/RPC Over HTTPS访问Exchange邮箱我们先看一下有哪些方式可以访问Exchange ①Outlook作为 ...
bench.h:39:10: 致命错误：rpc/rpc.h：没有那个文件或目录
在搭建lmbench的时候,在linux服务器系统上make results的时候,出现以下问题: bench.h:39:10: 致命错误:rpc/rpc.h:没有那个文件或目录解决方法如下: su ...
什么是 RPC?RPC原理是什么?
什么是 RPC?RPC原理是什么? 什么是 RPC? RPC(Remote Procedure Call)-远程过程调用,它是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议.比 ...
分布式 - 公司使用什么RPC框架，聊聊你理解的RPC原理
不啰嗦,我们直接开始! 引言以前在做一个规模不大的系统的时候,用的是单体架构,一台服务器部署上一个应用和数据库也就够了. 但是现代化互联网公司业务逐渐扩大,服务逐渐细分,很多服务之间需要通过远程分布 ...
RPC——RPC协议介绍及原理详解
common wx:CodingTechWork 介绍 RPC框架概念 RPC(Remote Procedure Call Protocol) 远程过程调用协议. RPC是一种通过网络从远程计算机程 ...
八：对微服务通讯方式RPC vs REST的理解
微服务专栏地址专栏:微服务微服务系列总目录目录微服务专栏地址目录 1. 简介 2. 关于RPC 2.1 什么是RPC 2.2 RPC有什么用 2.3 RPC的框架有哪些 2.3.1 服务治理 ...
RPC和Restful深入理解
一.RPC RPC 即远程过程调用(Remote Procedure Call Protocol,简称RPC),像调用本地服务(方法)一样调用服务器的服务(方法).通常的实现有 XML-RPC , J ...
任务队列，消息队列和rpc的区别是什么？
2019独角兽企业重金招聘Python工程师标准>>> 首先,这几个概念本就不是同一层次上的东西,本身风马牛不相及. 先说RPC RPC通常指的是PRC框架(分布式框架),或者PRC ...
徒手撸框架--实现 RPC 远程调用
微服务,已经是每个互联网开发者必须掌握的一项技术.而 RPC 框架,是构成微服务最重要的组成部分之一.趁最近有时间.又看了看 dubbo 的源码.dubbo 为了做到灵活和解耦,使用了大量的设计模式和 ...

【RPC】RPC和Http的理解