为什么需要RPC，而不是简单的HTTP接口

1. 为什么需要RPC，而不是简单的HTTP接口

http接口实在接口不多、系统与系统交互较少的情况下，解决信息孤岛初期常使用的一种通信手段；优点就是简单、直接、开发方便。利用现成的http协议进行传输。但是如果是一个大型的网站，内部子系统较多、接口非常多的情况下，RPC框架的好处就显示出来了，首先就是长链接，不必每次通信都要像http一样去3次握手什么的，减少了网络开销；其次就是RPC框架一般都有注册中心，有丰富的监控管理；发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作。第三个来说就是安全性。最后就是最近流行的服务化架构、服务化治理，RPC框架是一个强力的支撑
rpc是一种概念，http也是rpc实现的一种方式。论复杂度，dubbo/hessian用起来是超级简单的。最近用dubbo和hessian比较多，http的几乎都被废弃了。
至于为什么用，其实很简单，业务场景不一样。我最早的单位所有的代码都在一个工程里，一次要发布几百m的代码。这种架构是非常有利于小程序的。但是我们为什么要应用rpc层呢，一个功能，一套代码下来不就解决了么？我觉得有几个好处：
1 灵活部署 2 解耦 至于为什么，当你用到的时候，你会体会。

2. 了解一下RPC，为何诞生RPC，和HTTP有什么不同？

 【简单理解】：两台不同计算机（程序）， 计算机A 有一个 约定协议 ， 计算机B 想调用 计算机A 需要通过 约定协议 来进行通讯调用。
                                           其实早在1982年左右RPC就被人用来做分布式系统的通信，最早发明『远程过程调用』这个词语的人是『布鲁斯·杰伊·尼尔森 (Bruce Jay Nelson)』大约是在1981年。
   我们所熟知的Java在1.1版本提供了Java版本的RPC框架（RMI），此时在1990年后，基本上RPC被广泛用于系统之间的调用。但是只在后端方向熟知，对于大众更多的还是接触HTTP等协议，也因此RPC更晚让大众了解认知。
   HTTP： Hypertext Transfer Protocol 即超文本传输协议。
   HTTP协议在1990年才开始作为主流协议出现；之所以被我们所熟知，是因为通常HTTP用于web端，也就是web浏览器和web服务器交互。当ajax和json在前端大行其道的时候，json也开始发挥其自身能力，简洁易用的特性让json成为前后端数据传输主流选择。HTTP协议中以Restful规范为代表，其优势很大。它 可读性好 ，且 可以得到防火墙的支持、跨语言的支持 。
   HTTP的缺点也很快暴露：

3. RPC的实现原理，是基于HTTP协议的还是tcp协

RPC可以基于TCP协议也可以基于HTTP协议，RPC的主要目的只是获取由远程机器上的程序所执行的结果。
利用Socket API实现基于TCP协议的RPC调用，由服务的调用方与服务的提供方建立Socket连接，并由服务的调用方通过Socket将需要调用的接口名称、方法名称和参数序列化后传递给服务的提供方，服务的提供方反序列化后再利用反射调用相关的方法，最后将结果返回给服务的调用方。
基于HTTP协议的RPC调用则更像是我们访问网页一样，只是它的返回结果更加单一简单。其大致流程为：由服务的调用者向服务的提供者发送请求，这种请求的方式可能是GET、POST、PUT、DELETE等中的一种（服务的提供者可能会根据不同的请求方式做出不同的处理，或者某个方法只允许某种请求方式），而调用的具体方法则根据URL进行方法调用，而方法所需参数则可能是对服务调用方传输过去的XML数据或JSON数据解析后的结果，最后返回JOSN或XML的数据结果（这需要根据实际应用定义相关的协议）。由于目前有很多开源的WEB服务器，如Tomcat，JBoss等，所以其实现起来更加容易（就跟做Web项目一样）。