HTTP RPC RMI 及发送HTTP请求的工具集

   HTTP ： 应用层中的不同应用进程之间 进行数据交换的一种约束、规定、 学名协议，在和导师的对话中的一个问题 ： rmi 和 rpc 或者说实现他们的工具集 他们各种依据的什么样的协议？

导师说的hessian okhttp 是基于http 协议，rpc 是可以基于自己规定的协议的，自己好像没有思考过这个层面的问题（或者就是因为这个层面的知识少，不能联想到），其实自己对 tcp 的知识 部分了解，对http印象中并不很清楚，只是知道他在应用层，http  是不加密，http1.1 长连接 和 https是经过加密的等特别知识化的东西， 借此问题去看这些问题。

   翻了一下，计算机网络，书中很明确的描述说，传输层为应用进程提供了端到端的通信服务，但不同网络应用的应用进程之间，还需要不同的通信规则，因此在传输层上，还要有去规定传输通信规定的应用层。每个应用层的协议都是为了解决某一类应用的问题（这里的每一类问题，比如说http 发出请求响应请求  ftp 文件传输  talent 远程控制），而问题的解决又必须通过位于不同主机中的多个应用进程之间的通信和协同工作完成的。应用进程之间的这种通信必须遵守严格的规则，应用层的具体内容就是去定义这些通信规则。

• 应用进程交换的报文类型，如请求报文和响应报文
• 各种报文类型的语法，如报文中的各个字段及其详细描述
• 字段的语义，即包含在字段中的信息的含义。
• 进程何时、如何发送报文，以及对报文进行响应的规则。

看上去很知识化，但是你联想到问题，rpc所用的协议或者让你去定义一个应用通信的协议，是不是可以从这几个方法进行入手，其实书中说的很明白，解决不同网络的应用进程之间的 通信规则，rmi 远程方法调用 rpc 远程服务调用，都是为了解决 当你要去使用其他server提供的方法服务时的手段，只不过RMI就是开发百分之百纯Java的网络分布式应用系统的核心解决方案之一。其实RMI可以被看作是RPC的Java版本（实现）。详细的rmi 和rpc 之间的区别

按照基于网络协议的RPC 可以分为

•  基于HTTP的RPC
•  基于TCP的RPC

按照数据形式，RPC分为:

•  基于xml
•  基于json
•  基于二进制

    因此思路到这里，既rmi 是rpc 的实现版，而且rpc 作用就是去服务通信，那么去看一下rpc相关的知识，和我们刚看的http 应用层之间有什么联系，才能看出rpc 其实是怎样去是实现的。

既然有 HTTP 请求，为什么还要用 RPC 调用？

根据最高赞易哥的回答， http 方式是通过正常的controller 去处理，而rpc 是直接调用方法服务的接口来使用。 

那反问两者都可以去实现方法服务的调用 ，两者的不同，出现的原因，解决的痛点在哪里呢？

   HTTP 方式的缺点是传输报文包含了无用的头信息，效率低，使用HTTP协议调用远程方法（请求）比较复杂，要封装各种参数名和参数值。

   牺牲可读性提升效率、易用性是可取的。基于这种思路，RPC产生了。调用方只要调用了这些接口，就相当于调用了被调用方的实际方法，十分易用。于是，调用方可以像调用内部接口一样调用远程的方法，而不用封装参数名和参数值等操作。

发现 rpc 的通信方式才是前浪：

下面一堆答案给题主科普各种RPC和HTTP的原理，什么RPC也可以包含HTTP协议，其实并没有解答题主的困惑。题主的问题准确来讲，是说：既然有HTTP请求可以解决系统间调用的问题了，为什么还会有人使用RPC调用？题主明显是只看到现状，而忽略了两种远程请求调用的历史进程。RPC在1984年就被人用来做分布式系统的通信，Java在1.1版本提供了Java版本的RPC框架（RMI），而HTTP协议在1990年才开始作为主流协议出现，而且HTTP发明的场景是用于web架构，而不是分布式系统间通信，这导致了在很长一段时间内，HTTP都是浏览器程序和后端web系统通信用的东西，上面的文档格式都是HTML（非常啰嗦），没有人会把HTTP作为分布式系统通信的协议。在很长一段时间内，RPC才是正统。随着前端技术的发展，AJAX技术和JSON文档在前端界逐渐成为主流，HTTP调用才摆脱HTML，开始使用JSON这一相对简洁的文档格式，为后面用于系统间调用定下基础。最后随着RESTFUL思潮的兴起，越来越多系统考虑用HTTP来提供服务，但这时候，RPC已经是各种大型分布式调用的标配了。所以题主的问题真正应该要反过来问，既然有RPC了，为什么还要有HTTP请求？这个问题不难回答，因为现在大部分的系统都是给浏览器使用的，因此HTTP协议必不可少，而这大部分系统中的绝大部分，对于后端系统间调用的性能都是要求不高的，毕竟走的都是内网，它们关心的是前端和后端的性能，因此后端系统间调用如果能够采用和前端一样的技术栈，那无疑是维护成本最低的，而这时HTTP的技术生态也刚好满足这个条件，所以就星星之火可以燎原了。那么对于少数的部分系统，他们需要使用RPC，一可能是老架构，也不敢动这块，二是性能要求可能只有RPC可以满足。就我个人而言，我所任职的公司的云平台也早就统一要求走HTTP了，性能，有别的路可以想办法，而且HTTP2也有了很大改进了。

链接：https://www.zhihu.com/question/41609070/answer/1040163258 来源：知乎

理解单点式RPC框架和分布式RPC框架的区别

最基本的RPC框架就是单点式的，因为A服务直接调用B服务，不经过第三方，这种是最简单的。但是必须是A和B同时部署一套，A1只能调用B1，A2只能调用B2。

假设现在B服务出现了性能瓶颈，部署多台B服务的同时，也只能部署多台A服务，很浪费资源。

所以需要一台A服务对多台B服务，利用第三方服务(注册中心)找到其他B服务，而不是写死B服务的地址。这种RPC才是分布式RPC，也是业内主流。

单点RPC框架只需要：

1. 序列化协议
2. 传输协议

但是我们要做分布式的啊，所以需要：

1. 序列化协议
2. 传输协议
3. 服务注册发现中心

实际上在生产环境中，我们需要实时监控服务的调用情况，所以需要一个微服务管理中心，甚至是一个自动化运维的管理中心，所以需要：

1. 序列化协议
2. 传输协议
3. 服务注册发现中心
4. 服务监控管理中心

在文章的第二节我们看到大佬论文中对RPC的总结，其中一个很重要的一点：“通用”。

• 对的，30年前的初衷更大的是需要解决异构系统的服务调用问题，序列化协议和传输协议必须是通用的才是好的RPC框架，你总不能只能Java用，然后C#用不了，Scala用不了，Go用不了吧。
• 比如某个服务的并发需求高需要用GO来解决，因为以前用的Java性能低下。然后你的RPC框架不支持GO，完蛋啦，中间的一个服务是GO写的，上层服务是Java来调用的，不支持跨语言的RPC，Go语言写的新服务完全用不了。

所以我们需要：

1. 序列化协议
2. 传输协议
3. 服务注册发现中心
4. 服务监控管理中心
5. 能跨语言调用（无关语言）

来源： RPC协议及实现方式(分布式微服务治理的核心)

经过rpc 使用的协议和  跟随rpc 框架的发展流程，了解到了开始可能和http 请求差不多简单的服务通信方式，逐渐发展到了现在的庞然大物，引入的服务注册发现中心和服务监控管理中心其实和起初上的rpc 调用感觉关系不大，只是管理服务的工具。但就从我现在接触到编程知识的环境来说，很多教育机构比较鼓吹这些名词 ，其实应该多关注如何实现，一个工具总归是被用的，但的你的code 程序 还是你自己一步一步想它怎么去写的。

以下是一些HTTP请求的工具，因此都是使用的http 协议进行通讯规定。

OkHttp是一个高效的HTTP客户端，作为当前Android端最火热的网络请求框架之一，它有以下默认特性：

• 支持HTTP/2，允许所有同一个主机地址的请求共享同一个socket连接
• 连接池减少请求延时
• 透明的GZIP压缩减少响应数据的大小
• 缓存响应内容，避免一些完全重复的请求

HttpClient：代码复杂，还得操心资源回收等。代码很复杂，冗余代码多，不建议直接使用，最后在finally中关闭资源。

RestTemplate： 是 Spring 提供的用于访问Rest服务的客户端， RestTemplate 提供了多种便捷访问远程Http服务的方法,能够大大提高客户端的编写效率。

真要说这几个工具的不同：

OkHttp允许所有同一个主机地址的请求共享同一个socket连接。

HttpClient 最后需要关闭资源。

最后RPC 是一种服务调用的过程，没有特别要把 HTTP 和RPC 放在一起对比，两者并不是一层次的东西。只是在看应用层要解决的不同网络应用的应用进程之间，还需要不同的通信规则 这个为切点进行的切入进行了解，我和知乎这个题主同样提问  既然有 HTTP 请求，为什么还要用 RPC 调用？ 。

简单RPC的项目：

https://github.com/yeecode/EasyRPC