RPC(远程过程调用)和HTTP调用之前一直不太清楚，俩者都是实现服务通信，都是写一个服务端然后在客户端调用，但具体有啥区别，还是一脸模糊。因此抽了一点时间开始研究一波。
RPC和HTTP最本质的区别，RPC是基于TCP/IP协议的，而HTTP服务则是基于HTTP协议的，HTTP协议是在传输层协议TCP上面的，效率来看，RPC更好。
RPC可以说是如今分布式架构直接促进而诞生的。
在传统的单体应用的时候，当你调用Studen类中的add方法来执行一个学生注册的业务，直接new一个student类，然后调用add方法就可以了，这也就是常说的本地函数调用，因为在同一个地址空间，或者说在同一块内存，通过方法栈和参数栈就可以实现，但是如今随着业务的不断增长，基于高性能等诸多因素，将传统的单体应用改造成分布式应用，将很多功能单独抽取出来，比如说注册功能，单独抽离一个学生服务，如果业务需要执行注册功能的话，直接让别的服务去调用它。
但是遇到问题啦：
A服务调用注册服务，A服务中是没有Student类，更不要说其中的add（）方法。这时一个方案是通过Restful接口也就是所说的HTTP服务，在B服务中暴漏一个接口，然后A服务通过调用这个暴漏的接口来调用其中的add方法，这种方法需要每次请求都要写以传http请求的代码。
这时就用到RPC，RPC很少用到http协议来进行数据传输，毕竟只是传输数据而已，不需要用到文本传输的应用层协议，直接使用二进制传输。
网络的七层模型：(从上到下)
1、应用层，定义了用于在网络中进行通信和传输数据的接口
2、表示层，定义不同系统中数据的传输格式，编码和解码规范
3、会话层，管理用户的会话，空间用户间逻辑连接的建立和中断
4、传输层，管理着网络中的端到端的数据传输
5、网络层，定义网络设备如何传输数据
6、链路层，将上面的网络层的数据包装成数据帧，便于在物理层传输
7、物理层，主要传输二进制数据
实际中，主要就是五层协议，没有表示层和会话层，它们的功能与应用层合并；HTTP是应用层协议，而TCP是传输层协议，因此RPC比HTTP服务效率会好一点
RPC架构：
RPC服务基本架构---->客户端，客户端存根，服务端，服务端存根
主要执行过程
步骤一：建立通信，首先要通过客户端和服务端之间建立TCP连接，远程过程调用的所有交换数据都在这个连接里传输，连接可以是按需连接，调用结束后就断掉，也可以是长连接，多个远程过程调用共享一个连接
步骤二：服务寻址，A服务上的应用如何告诉底层的RPC框架，如何连接到B服务器以及特定的端口，方法名称。通常情况下我们需要提供B服务器主机名或ip地址，以及特定的端口，然后指定调用的方法或者函数的名称以及入参出参等信息，这样才能完成服务的一个调用。另外可以采用redis和zookeeper来注册服务等。
从服务提供者的角度来看，当提供者服务启动时，需要自动向注册中心注册服务，当提供者服务停止时，需要向注册中心注销服务。提供者需要定时想注册中心发送心跳
从服务消费者的角度来看，调用者启动时订阅注册中心的消息并从注册中心获取提供者的地址，调用者下线，取消订阅
步骤三：网络传输，当A机器上的一个应用发起一个RPC调用时，调用方法和其入参等信息需要通过底层协议如TCP传输到B机器，因为协议是基于二进制的，所有我们传输的参数都需要先序列化成二进制的形式才能在网络中进行传输。B机器接受到A机器发出的请求之后，会进行反序列操作，将二进制转化过来，然后再找到对应的方法进行本地调用(JDK动态代理)
步骤四：服务调用，B机器进行本地调用之后得到了返回值，此时还需要把返回值发送回A机器
常用的RPC框架：
1、Dubbo,阿里开源的RPC框架，远程接口是基于JAVA interface,并且依托Spring框架开发，可以方便的打包成单一文件，独立进程运行，和现在的微服务概念一致
HTTP服务：
之前的开发模式一直为HTTP接口开发，也就是我们说的RESTful风格的服务接口，这种方式简单，直接，开发方便。利用现成的http协议进行传输。对于接口不多，系统与系统交互较少二点情况下，这种解决方案值得应用，但是对大型企业来说，内部子系统，使用RPC是一个更佳的选择，RPC不需要每次通信都要弄个3次握手，减少了网络开销，其次RPC框架一般都有注册中心，有丰富的监控管理。