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

清风-蓝魔泪 发布于 2016/03/06 15:21
阅读 23K+
收藏 19

【Gopher China万字分享】华为云的Go语言云原生实战经验!>>>

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

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

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

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

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

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

加载中
6
熊猫也天真
熊猫也天真

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

DraeneiYong
DraeneiYong
http的服务端如果开启了keepalive,那么每次请求就不是握手三次而是握手一次即可。
3
小耶果
小耶果
RPC=Remote Produce Call 是一种技术的概念名词. HTTP是一种协议,RPC可以通过HTTP来实现,也可以通过Socket自己实现一套协议来实现.所以楼主可以换一个问法,为何RPC还有除HTTP之外的实现法,有何必要.毕竟除了HTTP实现外,私有协议不具备通用性.那么我想唯一的答案就在于HTTP不能满足其业务场景的地方,所以这个就要具体案例具体分析了.
清风-蓝魔泪
清风-蓝魔泪
是的,我们学技术也应该是知其然知其所以然,我们得明白什么场景,或者什么业务需要它,它能解决其他技术不能解决或者不方便解决的问题
2
xtuhcy
xtuhcy
RPC:远程过程调用。RPC的核心并不在于使用什么协议。RPC的目的是让你在本地调用远程的方法,而对你来说这个调用是透明的,你并不知道这个调用的方法是部署哪里。通过RPC能解耦服务,这才是使用RPC的真正目的。RPC的原理主要用到了动态代理模式,至于http协议,只是传输协议而已。简单的实现可以参考spring remoting,复杂的实现可以参考dubbo。
kimown
kimown
这个解释最通俗易懂
1
OpenIoT
OpenIoT
这个问题不错,我也有此困惑,希望看到精彩、有价值的回复!
1
sss6666
sss6666

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

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

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

清风-蓝魔泪
清风-蓝魔泪
回复 @Isaac-c : 多谢,终于听到一个中肯的回答了,谢谢大虾,哈哈
sss6666
sss6666
回复 @清风-蓝魔泪 : 至于为什么用dubbo/hessian,我觉得有几点,一是调用简单,真正提供了类似于调用本地方法一样调用接口的功能 。二是参数返回值简单明了 参数和返回值都是直接定义在jar包里的,不需要二次解析。 三是 轻量,没有多余的信息。 四是便于管理,基于dubbo的注册中心。当然,这种方式 其实还是有缺点的。
sss6666
sss6666
回复 @清风-蓝魔泪 : 真巧,我也是做电商的,各个系统分离,提供http/hessian/dubbo。你们用http交互其实就已经属于rpc了,你已经在使用了,你所理解的rpc可能指的是hessian/dubbo之类的框架吧。
清风-蓝魔泪
清风-蓝魔泪
系统做大了,肯定是需要做微服务的。 现在我们做电商就是这样,单独有一个订单系统,支付系统,商品系统,用户系统。都是分开部署,单独上线的。 但我们交互是用HTTP接口来交互的,我想转用RPC,但问题是我现在还没发现为什么需要用RPC,我还没能理解它的作用和意义
0
huan
huan
rpc和http 不是一个层面的东西,不能这样比较的,有的rpc是基于http协议实现的。
清风-蓝魔泪
清风-蓝魔泪
恩 RPC只是一个统称的概念,怎样的场景更适合RPC,或者说RPC诞生的意义是为了什么诞生的呢?
行业协汇袁斌
行业协汇袁斌
同意这个看法。 事实上绝大多数rpc都是基于http或者其他成熟的协议之上实现的。 没必要神化这个东东。 如果说传输效率或者安全性的话。。。 http也有压缩协议, 安全性也有ssl.这样说来好像也区别不大吧。。。 除非你的通讯不是基于万维网, 而是常连接的局域网就能顶得住了。。。
0
小耶果
小耶果

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

清风-蓝魔泪
清风-蓝魔泪
什么样的场景,是适合RPC,不适合HTTP的呢?
0
长安俞白眉
长安俞白眉
为了更好的扩展性和维护性,降低开发复杂度
清风-蓝魔泪
清风-蓝魔泪
回复 @来自星星的码农 : 之前在一家公司,就是用thrift,然后我问负责推动这个的人,说为什么需要用到thrift,是因为简单的HTTP不能满足业务了吗。他说,哥就是想玩玩新的,仅此而已。。。。
长安俞白眉
长安俞白眉
回复 @清风-蓝魔泪 : rpc就像调用本地方法一样,对调用者完全透明
长安俞白眉
长安俞白眉
回复 @清风-蓝魔泪 : 你看下thrift或者grpc就明白了
penngo
penngo
回复 @清风-蓝魔泪 : RPC的扩展性和维护性更好,HTTP应届生需要培训一天,RPC不需要培训或简单培训一两小时就知道怎样调用。
清风-蓝魔泪
清风-蓝魔泪
体现在哪里呢? HTTP接口的扩展性和维护性不行吗,要改的话改一下入参出参就好了。 至于降低复杂度,现在随便去拉一个应届生,一天培训完了,他也会调HTTP吧。。。
0
唐代de豆腐
唐代de豆腐

我的理解是:

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

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

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

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

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

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

hibegin
hibegin
p
0
护士的小黄瓜
护士的小黄瓜
mvc http水平扩展需要c rpc扩展可以是只有一个c  但是有多个m或者service 另外有些异构的系统 没有http 只支持webservice
护士的小黄瓜
护士的小黄瓜
控制层去调用service层,现在人多了,service层有大量的计算,这个时候就要复制多个service层去供控制层调用,而不是整个把项目复制粘贴一份。service也可以做成一个单独的服务,供别人使用
清风-蓝魔泪
清风-蓝魔泪
水平扩展是指接口迭代吗? 如果接口本来只处理A事情,现在又需要处理B事情,那也只是服务端内部逻辑调整,接口也不用变。 如果是需要增加入参,或者增加出参,HTTP需要改的,RPC也需要改,这样并没有看出RPC哪里优秀或者哪里方便啊
OSCHINA
登录后可查看更多优质内容
返回顶部
顶部