在很久以前，笔者刚毕业开始工作那会儿，对于企业开发的模式一直以为HTTP接口开发，也就是我们常说的RESTful风格的服务接口。的确，对于在接口不多、系统与系统交互较少的情况下，解决信息孤岛初期常使用的一种通信手段；优点就是简单、直接、开发方便。
但是到了大公司后，才发现后端服务之间使用的都是RPC服务，为什么不用HTTP服务了呢？
先说说RPC和HTTP的本质区别：
- RPC主要是基于TCP/IP协议的，而HTTP服务主要是基于HTTP协议的
所以效率来看的话，RPC当然是要更胜一筹啦
HTTP服务
HTTP服务是利用现成的http协议进行传输。在上一家公司做后台开发的时候，主要就是进行接口的开发，还要写一大份接口文档，严格地标明输入输出是什么。但是后端开发都会选择使用swagger文档，省去了写文档的痛苦。。。
接口可能返回一个JSON字符串或者是XML文档。然后客户端再去处理这个返回的信息，从而可以比较快速地进行开发。
优势是开发、调试、使用都简单快速
RPC服务
一个完整的RPC架构里面包含了四个核心的组件，分别是Client ,Server,Client Stub以及Server Stub，这个Stub大家可以理解为存根。分别说说这几个组件：
客户端（Client），服务的调用方。
服务端（Server），真正的服务提供者。
客户端存根，存放服务端的地址消息，再将客户端的请求打包成网络消息，然后通过网络远程发送给服务方；
服务端存根，接收客户端发送过来的消息，将消息解包，并调用本地的方法
为什么用RPC
RPC主要是用在大型企业里面，因为大型企业里面系统繁多，业务线复杂，而且效率优势非常重要的一块，这个时候RPC的优势就比较明显了。实际的开发当中是这么做的。当然还是看图理解理解
正常的小公司的系统可能是下面这样
查询链路：前端->服务端->数据库
服务链路很简单，只请求1个后端服务，查1次数据库。一次请求的耗时正常能保证在200ms以内，HTTP完全能胜任。
但是大公司的业务系统中，一次请求可能是下面这样
一次请求跨了几十个应用，这时候如果还用HTTP，可能一次请求的耗时就是2~3秒钟了，用户可能无法忍受的，就像你刷短视频，刷着突然卡了几秒钟，这能忍得了？
而RCP请求的耗时正常能在20ms内，而如果只是单独查机器内存数据，响应时间能在5ms内，优势大大体现出来了。
流行的RPC框架
这里说一说现在流行的RPC框架
gRPC框架
gRPC是Google公布的开源软件，基于最新的HTTP2.0协议，并支持常见的众多编程语言。我们知道HTTP2.0是基于二进制的HTTP协议升级版本，这个RPC框架是基于HTTP协议实现的，底层使用到了Netty框架的支持。官方文档：https://www.grpc.io/docs
Dubbo框架
Dubbo是阿里集团开源的一个极为出名的RPC框架，在很多互联网公司和企业应用中广泛使用。协议和序列化框架都可以插拔是及其鲜明的特色。同样的远程接口是基于Java Interface，并且依托于spring框架方便开发。可以方便的打包成单一文件，独立进程运行，和现在的微服务概念一致。官方文档：https://dubbo.apache.org/zh/overview/quickstart/
HSF框架
别名：“好舒服”，阿里集团内部王牌RPC框架，可惜没有对外开源。对比Dubbo新增了很多特性，支持服务优雅上线下线、分层发布、服务鉴权等功能。
到此，我们也理解了为什么大厂要用RPC请求作为服务通信方式。主要原因还是业务系统庞大、服务较多，使用RPC比HTTP更有优势。
