RPC是远程过程调用的缩写（Remote Procedure Call），通俗地说就是调用远处的一个函数。
远处到底有多远呢？
可能是同一个文件内的不同函数
可能是同一个机器的另一个进程的函数
远到它们之间说着完全不同的语言，语言就成了两边的沟通障碍。而Protobuf因为支持多种不同的语言（甚至不支持的语言也可以扩展支持），其本身特性也非常方便描述服务的接口（也就是方法列表），因此非常适合作为RPC世界的接口交流语言。
Go语言的RPC规则：方法只能有两个可序列化的参数，其中第二个参数是指针类型，并且返回一个error类型，同时必须是公开的方法。
RPC 比较
旧restful 短连接,效率低, 需要手动序列化, 数据严谨性差
- gRPC是Google最近公布的开源软件，基于最新的HTTP2.0协议，并支持常见的众多编程语言。 我们知道HTTP2.0是基于二进制的HTTP协议升级版本，目前各大浏览器都在快马加鞭的加以支持。 这个RPC框架是基于HTTP协议实现的，底层使用到了Netty框架的支持。
- Thrift是Facebook的一个开源项目，主要是一个跨语言的服务开发框架。它有一个代码生成器来对它所定义的IDL定义文件自动生成服务代码框架。用户只要在其之前进行二次开发就行，对于底层的RPC通讯等都是透明的。不过这个对于用户来说的话需要学习特定领域语言这个特性，还是有一定成本的。
- Dubbo是阿里集团开源的一个极为出名的RPC框架，在很多互联网公司和企业应用中广泛使用。协议和序列化框架都可以插拔是及其鲜明的特色。同样 的远程接口是基于Java Interface，并且依托于spring框架方便开发。可以方便的打包成单一文件，独立进程运行，和现在的微服务概念一致。
阿里内部已经不怎么使用dubbo啦，现在用的比较多的叫HSF，又名“好舒服”。后面有可能会开源，大家拭目以待。
rpc和http的区别是什么
http请求是使用具有标准语义的通用的接口定向到资源的，这些语义能够被中间组件和提供服务的来源机器进行解释。结果是使得一个应用支持分层的转换(layers of transformation)和间接层(indirection)，并且独立于消息的来源，这对于一个Internet规模、多个组织、无法控制的可伸缩性的信息系统来说，是非常有用的。
与之相比较，rpc的机制是根据语言的API(language API)来定义的，而不是根据基于网络的应用来定义的。
HTTP和RPC的优缺点
传输协议
RPC:可以基于TCP协议，也可以基于HTTP协议
HTTP:基于HTTP协议
传输效率
RPC:使用自定义的TCP协议，可以让请求报文体积更小，或者使用HTTP2协议，也可以很好的减少报文的体积，提高传输效率
HTTP:如果是基于HTTP1.1的协议，请求中会包含很多无用的内容，如果是基于HTTP2.0，那么简单的封装以下是可以作为一个RPC来使用的，这时标准RPC框架更多的是服务治理
性能消耗
RPC:可以基于thrift实现高效的二进制传输
HTTP:大部分是通过json来实现的，字节大小和序列化耗时都比thrift要更消耗性能
负载均衡
RPC：基本都自带了负载均衡策略
HTTP：需要配置Nginx，HAProxy来实现
服务治理
RPC：能做到自动通知，不影响上游
HTTP:需要事先通知，修改Nginx/HAProxy配置
总结
RPC主要用于公司内部的服务调用，性能消耗低，传输效率高，服务治理方便。
HTTP主要用于对外的异构环境，浏览器接口调用，APP接口调用，第三方接口调用等。
若有收获，就点个赞吧
0 人点赞
