PRC和HTTP(rest)过程的区别

HTTP 与 RPC 的关系就好比国际化与地方化的关系(可以认为标准的国际拳击手和随意的自由拳击手)。

要进行跨企业服务调用时，往往都是通过 HTTP API， 虽然效率不高，但是通用，没有太多沟通的学习成本。但是在企业内部还是 RPC 更加高效，因为http学习的成本实在是太高了。

注：PRC和PRC协议 不是同一个意思 ，PRC是一个过程，而实现PRC的协议有很多，可以是tcp或http协议。而HTTP也类似PRC，但他是基于HTTP协议。

两种风格的API区别，总结一下其实非常简单：

（1）RPC-api面向过程，只发送 GET 和 POST 请求。GET用来查询信息，其他情况下一律用POST。请求参数是"动词"，直接描述动作本身。当然RPC不仅仅是一种API设计风格，它的概念比这要广得多,就不一介绍。

（2）RESTful-api面向资源(http使用的是RESTful，需要注意的是http协议的框架就是rest框架。

。)，使用 POST、DELETE、PUT、GET 请求，分别对应增、删、改、查操作。请求参数是"名词"，这个名词就是“增删改查”想要操作的对象。

在HTTP和RPC的选择上，可能有些人是迷惑的，主要是因为，有些RPC框架配置复杂，如果走HTTP也能完成同样的功能，那么为什么要选择RPC，而不是更容易上手的HTTP来实现了。

本文主要来阐述HTTP和RPC的异同，让大家更容易根据自己的实际情况选择更适合的方案。

1）传输协议

RPC，可以基于TCP协议，也可以基于HTTP协议

HTTP，基于HTTP协议（在TCP协议之上进行封装）

2）传输效率

RPC，使用自定义的TCP协议，可以让请求报文体积更小，或者使用HTTP2协议，也可以很好的减少报文的体积，提高传输效率HTTP，如果是基于HTTP1.1的协议，请求中会包含很多无用的内容，如果是基于HTTP2.0，那么简单的封装以下是可以将http作为一个RPC来使用的，这时标准RPC框架更多的是服务治理 。

3）性能消耗，主要在于序列化和反序列化的耗时

RPC，可以基于thrift实现高效的二进制传输

HTTP，大部分是通过json来实现的，字节大小和序列化耗时都比thrift要更消耗性能

当然 还有别的区别 这里 就不一样说明。

4）总结：

RPC主要用于公司内部的服务调用，性能消耗低，传输效率高，服务治理方便。

HTTP主要用于对外的异构环境，浏览器接口调用，APP接口调用，第三方接口调用等。

5）既然两种方式都可以实现远程调用，我们该如何选择呢？

（1）速度来看，RPC要比http更快，虽然底层都是TCP，但是http协议的信息往往比较臃肿，不过可以采用gzip压缩。

（2）难度来看，RPC实现较为复杂，http相对比较简单

（3）灵活性来看，http更胜一筹，因为它不关心实现细节，跨平台、跨语言。

因此，两者都有不同的使用场景：

（4）如果对效率要求更高，并且开发过程使用统一的技术栈，那么用RPC还是不错的。

（5）如果需要更加灵活，跨语言、跨平台，显然http更合适微服务，更加强调的是独立、自治、灵活。而RPC方式的限制较多，因此微服务框架中，一般都会采用基于Http的Rest风格服务 。

http就相当于是普通话，rpc相当于方言。