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

Question

有个问题想请教OSC的大神，请不吝赐教。

目前有很多Java的RPC框架，有基于Json的，有基于XML，也有基于二进制对象的。

论复杂度，RPC框架肯定是高于简单的HTTP接口的。但毋庸置疑，HTTP接口由于受限于HTTP协议，需要带HTTP请求头，导致传输起来效率或者说安全性不如RPC。

现在问题是，遇到怎样的瓶颈了才需要或者说更适合用RPC（比如像阿里这么大的请求并发量，简单的HTTP肯定达不到预期），但问题是大家所在的公司，要有像阿里这么大的量是比较少的，甚至说1/1000的量可能都没有，那我们还需要使用RPC吗？

技术应该不是为了使用新技术而去使用，而应该是旧技术存在某些瓶颈，存在难以支撑或者扩展性越老越差等问题暴露出来之后，用新技术来进行解决。

那RPC最大的优点，或者说它相比简单的HTTP接口，它的优势、更适合它的业务场景是怎样呢？简单的HTTP又哪里不足，哪些场景明显不太适合呢？

Answer 1

水平扩展是指接口迭代吗？ 如果接口本来只处理A事情，现在又需要处理B事情，那也只是服务端内部逻辑调整，接口也不用变。 如果是需要增加入参，或者增加出参，HTTP需要改的，RPC也需要改，这样并没有看出RPC哪里优秀或者哪里方便啊

Answer 2

控制层去调用service层，现在人多了，service层有大量的计算，这个时候就要复制多个service层去供控制层调用，而不是整个把项目复制粘贴一份。service也可以做成一个单独的服务，供别人使用

Answer 3

p

Answer 4

mvc http水平扩展需要c rpc扩展可以是只有一个c  但是有多个m或者service 另外有些异构的系统 没有http 只支持webservice

Answer 5

体现在哪里呢？ HTTP接口的扩展性和维护性不行吗，要改的话改一下入参出参就好了。 至于降低复杂度，现在随便去拉一个应届生，一天培训完了，他也会调HTTP吧。。。

Answer 6

我的理解是：

服务器通讯原理就是一台socket服务器A,另一台socket客户端B,现在如果要通讯的话直接以流方式写入或读出。这样能实现通讯，但有个问题。如何知道更多信息？比如需要发送流大小，编码，Ip等。这样就有了协议，协议就是规范，就是发送的流中携带了很多的内容。那回到刚刚的问题。

发送的内容就是文本类型，客户端就得序列化，那么常用的就有json，xml之类

如果想把内容变得更小，那就有二进制了。把文本变成二进制传递。

说到 rpc 与http接口，不要太复杂了。rpc 协议更简单内容更小，那么来说效率是要高一点

然后rpc 是什么。就是socket 加动态代理，你去想想，为什么客户端能调用你的service .

你去看看http://javatar.iteye.com/blog/1123915，希望对你有帮助。

Answer 7

回复
你看下thrift或者grpc就明白了

Answer 8

回复
RPC的扩展性和维护性更好，HTTP应届生需要培训一天，RPC不需要培训或简单培训一两小时就知道怎样调用。

Answer 9

回复
rpc就像调用本地方法一样，对调用者完全透明

Answer 10

回复
之前在一家公司，就是用thrift，然后我问负责推动这个的人，说为什么需要用到thrift，是因为简单的HTTP不能满足业务了吗。他说，哥就是想玩玩新的，仅此而已。。。。

Answer 11

什么样的场景，是适合RPC，不适合HTTP的呢？

Answer 12

为了更好的扩展性和维护性，降低开发复杂度

Answer 13

恩 RPC只是一个统称的概念，怎样的场景更适合RPC，或者说RPC诞生的意义是为了什么诞生的呢？

Answer 14

同意这个看法。 事实上绝大多数rpc都是基于http或者其他成熟的协议之上实现的。 没必要神化这个东东。 如果说传输效率或者安全性的话。。。 http也有压缩协议， 安全性也有ssl.这样说来好像也区别不大吧。。。 除非你的通讯不是基于万维网， 而是常连接的局域网就能顶得住了。。。

Answer 15

COM+ -> WebService(SOAP) -> RPC -> WebAPI

Answer 16

rpc和http 不是一个层面的东西，不能这样比较的，有的rpc是基于http协议实现的。

Answer 17

系统做大了，肯定是需要做微服务的。 现在我们做电商就是这样，单独有一个订单系统，支付系统，商品系统，用户系统。都是分开部署，单独上线的。 但我们交互是用HTTP接口来交互的，我想转用RPC，但问题是我现在还没发现为什么需要用RPC，我还没能理解它的作用和意义

Answer 18

回复
真巧，我也是做电商的，各个系统分离，提供http/hessian/dubbo。你们用http交互其实就已经属于rpc了，你已经在使用了，你所理解的rpc可能指的是hessian/dubbo之类的框架吧。

Answer 19

回复
至于为什么用dubbo/hessian，我觉得有几点，一是调用简单，真正提供了类似于调用本地方法一样调用接口的功能 。二是参数返回值简单明了 参数和返回值都是直接定义在jar包里的，不需要二次解析。 三是 轻量，没有多余的信息。 四是便于管理，基于dubbo的注册中心。当然，这种方式 其实还是有缺点的。

Answer 20

回复
多谢，终于听到一个中肯的回答了，谢谢大虾，哈哈

Answer 21

rpc是一种概念，http也是rpc实现的一种方式。论复杂度，dubbo/hessian用起来是超级简单的。最近用dubbo和hessian比较多，http的几乎都被废弃了。

至于为什么用，其实很简单，业务场景不一样。我最早的单位所有的代码都在一个工程里，一次要发布几百m的代码。这种架构是非常有利于小程序的。但是我们为什么要应用rpc层呢，一个功能，一套代码下来不就解决了么？我觉得有几个好处：

1 灵活部署 2 解耦 至于为什么，当你用到的时候，你会体会。

Answer 22

这个问题不错，我也有此困惑，希望看到精彩、有价值的回复！

Answer 23

这个解释最通俗易懂

Answer 24

RPC:远程过程调用。RPC的核心并不在于使用什么协议。RPC的目的是让你在本地调用远程的方法，而对你来说这个调用是透明的，你并不知道这个调用的方法是部署哪里。通过RPC能解耦服务，这才是使用RPC的真正目的。RPC的原理主要用到了动态代理模式，至于
http协议，只是传输协议而已。
简单的实现可以参考spring remoting，复杂的实现可以参考dubbo。

Answer 25

是的，我们学技术也应该是知其然知其所以然，我们得明白什么场景，或者什么业务需要它，它能解决其他技术不能解决或者不方便解决的问题

Answer 26

RPC=Remote Produce Call 是一种技术的概念名词. HTTP是一种协议,RPC可以通过HTTP来实现,也可以通过Socket自己实现一套协议来实现.所以楼主可以换一个问法,为何RPC还有除HTTP之外的实现法,有何必要.毕竟除了HTTP实现外,私有协议不具备通用性.那么我想唯一的答案就在于HTTP不能满足其业务场景的地方,所以这个就要具体案例具体分析了.

Answer 27

http的服务端如果开启了keepalive，那么每次请求就不是握手三次而是握手一次即可。

Answer 28

http接口是在接口不多、系统与系统交互较少的情况下，解决信息孤岛初期常使用的一种通信手段；优点就是简单、直接、开发方便。利用现成的http协议进行传输。但是如果是一个大型的网站，内部子系统较多、接口非常多的情况下，RPC框架的好处就显示出来了，首先就是长链接，不必每次通信都要像http一样去3次握手什么的，减少了网络开销；其次就是RPC框架一般都有注册中心，有丰富的监控管理；发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作。第三个来说就是安全性。最后就是最近流行的服务化架构、服务化治理，RPC框架是一个强力的支撑