在国企干了 5 年 Java，居然不知道 RPC？这正常吗？

在国企干了 5 年 Java，居然不知道 RPC 是什么？这正常吗？

这很正常。

如果你没接触过分布式微服务项目，基本是接触不到 RPC 这玩意的，并不是个人能力的问题。

不过 RPC 是程序员需要掌握的知识，也是面试官可能会问的题目。

什么是 RPC？RPC 和 HTTP 有什么区别？

下面用 2 分钟给大家讲清楚！

什么是 RPC？

你饿了，想吃鱼皮。

如果是在 20 年前，你只能自己吭哧吭哧跑到店里去买。

但现在有了手机、网络和外卖平台，你只需要在家动动手指点个外卖，骑手就能直接把鱼皮配送到家。

你不需要关注网络是怎么传输的、平台是怎么操作的、骑手是怎么配送的，只负责享受鲜嫩多汁、丝滑爽口的鱼皮就行了。

这个过程其实就是 RPC 的核心思想。

RPC 的全称是远程过程调用（Remote Procedure Call），允许一个项目 像调用自己本地的方法一样，调用另一个远程项目的接口，而不需要了解数据的传输处理过程和底层网络通信的细节。

举个例子，项目 A 提供了点餐服务，项目 B 想要调用它完成下单。

如果没有 RPC 框架，项目 B 作为服务消费者，需要找到项目 A 的地址、自己构造请求参数、给项目 A 发送请求并解析响应结果。

如果项目 B 要调用很多第三方服务，每个都这么写，是不是很麻烦？

但如果使用 RPC 框架，只需要一行代码就能完成调用！

看起来就跟调用自己项目内的方法没有任何区别！是不是很丝滑？

这就是 RPC 框架的作用，隐藏了服务调用的通信细节，让程序员专注于业务逻辑，快速开发分布式、微服务系统。

RPC 和 HTTP 的区别？

有同学会问了：“HTTP 协议不也能请求别的服务么，RPC 跟 HTTP 有什么区别呢？”

首先，HTTP 是一种网络通信协议，而 RPC 是一种 “远程调用本地化” 的思想，就像我想吃饭的时候，点外卖找个骑手帮我送，至于骑手是谁、从哪找到骑手、骑手是开车还是骑电动车，可以有不同的选择。

因此，RPC 完全可以 基于 HTTP 协议来实现数据的传输，只不过主流的 RPC 实现更多的使用基于 TCP 的二进制格式，传输的数据更紧凑，传输效率也更高。

一般来说，HTTP 适用于前端和后端的交互、对外提供的 RESTful API 服务；而 RPC 更适合分布式系统的服务间的内部通信。

除了数据传输外，RPC 的实现一般还需要依赖注册中心、序列化器、负载均衡、重试容错机制等等。

注册中心：就像服务的通讯录，记录着各个服务在哪台机器上，消费者想找服务时查一下就能知道地址。
序列化器：相当于数据翻译官，把内存里的对象转换成能在网络上传输的格式（比如二进制），到了对方那里再翻译回去，确保双边都能看懂。
负载均衡：就像调度员，当多个机器都提供同一个服务时，它来决定把请求发给哪台机器，避免有的机器累死，有的机器闲着。
重试容错机制：备用方案，调用服务失败时会自动重试几次（比如网络卡了、宕机了），如果一直失败就用其他方法（比如返回缓存数据），不让整个系统因为一个小故障就崩溃。

完整的 RPC 框架工作流程：

服务消费者和提供者都需要引入 RPC 框架：

有哪些 RPC 框架？

听起来想实现 RPC 很复杂啊！

但别担心，市面上有很多强大的 RPC 框架，比如 gRPC、Dubbo、Thrift、OpenFeign 等，几乎可以满足我们对 RPC 的一切需求。

你们更喜欢用哪个框架呢？

个人建议，对于 Java 开发者来说，首选 Dubbo。

开源项目

我之前带大家手写过一套 RPC 框架并且完全开源，感兴趣的同学可以来学习~

开源仓库：https://github.com/liyupi/yu-rpc

OK 以上就是本期分享，还有疑问的话欢迎大家在评论区留言，没疑问的话求个点赞三连 ‍‍