rpc ,http, restful的区别
网上充斥着各类类似于这样的文章：rpc 比 http 快了多少倍？既然有了 http，为什么还要用 rpc 调用等等。遇到这类文章，说明对 http 和 rpc 是由理解误区的。
实际上二者存在性以及速度是不好比的。
通信协议并不是rpc重点。rpc是一个方法，而http是一种协议。
http1.1这种和自定义的tcp协议有什么区别：http的头部有太多的冗余信息，而且是文本编码的。但是信息简单不是主要区别，比如grpc就是基于http2.0的他可以优化头部编码效率，好像是基于一个表记录了常见的字段，用简单的二进制信息来表示。
所以，更多的是封装了 “服务发现”，“负载均衡”，“熔断降级” 一类面向服务的高级特性。可以这么理解，rpc框架是面向服务的更高级的封装。
所以为什么要用rpc调用？
因为良好的 rpc 调用是 面向服务的封装，针对服务的 可用性 和 效率 等都做了优化。单纯使用http调用则缺少了这些特性。一般大公司内部通信用的是这个。而用于访问就是http了。
那么，为什么会有http,rpc比较这种问题呢？
可能是因为要想让服务A 调用 服务B 中的方法，最先想到的就是通过 HTTP 请求实现。首先接口比较简单（restful），可以通过防火墙，随便一个web容器就能访问，不需要双方语言一致。
但是，如果遇到服务间调用很多的话。http缺点就暴露了，首先效率低（不包括http2）,再者封装调用比较复杂需要很多函数名和参数。
而RPC就是解决这一点的，RPC要求在调用方中放置被调用的方法的接口，就像调用本地的方法一样，不需要函数和参数了。另外，它的效率比较高（不是绝对的）。
最重要的一点其实是，rpc有面向服务的更多特性，比如服务发现，均衡负载，熔断机制等，更加可用性。
正是因为以上三点，导致一般大公司内部通信用rpc框架（因为内部的框架一致是前提条件，再者内部通信需要效率和可用性，其次不需要http可读性的优势因为封装在内部，你只需要调用接口）。而用户访问公司网站就是http。因为用户和公司的架构不一致，只有浏览器。
rpc调用框架是：服务端有个stub,他可以把服务B的接口作为参数序列化，然后通过传输协议（http2，protobuf等）给B，B反序列化然后计算得到结果返回给A。
常见的rpc框架有，brpc,dubbo(阿里），thrift、
总结: 首先阐述本质，二者不是一个东西，一个是方法，一个是协议。rpc重要的不是协议，更重要的对一些高级特效的封装。
二者的关系可以使包含也可以是并列。正是因为并列所以会产生二者比较的问题。A,B调用可以用http，也可以用rpc。包含的话就是rpc可以用http2作为传输协议。
一般而言，Http优点是可读性好，双方不用同一架构，只要浏览器就可以。可以通过防火墙。
缺点：rpc不需要封装很多函数和参数；效率高；有更多的特性可用性好。