这很正常。
如果你没接触过分布式微服务项目,基本是接触不到 RPC 这玩意的,并不是个人能力的问题。
不过 RPC 是程序员需要掌握的知识,也是面试官可能会问的题目。
什么是 RPC?RPC 和 HTTP 有什么区别?
下面用 2 分钟给大家讲清楚!
👇 推荐观看视频版:https://bilibili.com/video/BV1y2aPzJEZY
你饿了,想吃鱼皮。

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

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

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

这个过程其实就是 RPC 的核心思想。
RPC 的全称是远程过程调用(Remote Procedure Call),允许一个项目 像调用自己本地的方法一样,调用另一个远程项目的接口,而不需要了解数据的传输处理过程和底层网络通信的细节。

举个例子,项目 A 提供了点餐服务,项目 B 想要调用它完成下单。
如果没有 RPC 框架,项目 B 作为服务消费者,需要找到项目 A 的地址、自己构造请求参数、给项目 A 发送请求并解析响应结果。

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

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

看起来就跟调用自己项目内的方法没有任何区别!是不是很丝滑?
这就是 RPC 框架的作用,隐藏了服务调用的通信细节,让程序员专注于业务逻辑,快速开发分布式、微服务系统。
有同学会问了:“HTTP 协议不也能请求别的服务么,RPC 跟 HTTP 有什么区别呢?”
首先,HTTP 是一种网络通信协议,而 RPC 是一种 “远程调用本地化” 的思想,就像我想吃饭的时候,点外卖找个骑手帮我送,至于骑手是谁、从哪找到骑手、骑手是开车还是骑电动车,可以有不同的选择。

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

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

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

完整的 RPC 框架工作流程:

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

听起来想实现 RPC 很复杂啊!
但别担心,市面上有很多强大的 RPC 框架,比如 gRPC、Dubbo、Thrift、OpenFeign 等,几乎可以满足我们对 RPC 的一切需求。

你们更喜欢用哪个框架呢?
个人建议,对于 Java 开发者来说,首选 Dubbo。
我之前带大家手写过一套 RPC 框架 并且完全开源,感兴趣的同学可以来学习~
开源仓库:https://github.com/liyupi/yu-rpc

OK 以上就是本期分享,还有疑问的话欢迎大家在评论区留言,没疑问的话求个点赞三连 🌹👨🏻💻🧑🏻🦲
