计划,每天学习两小时,坚持带来大改变。

一个虐你千百遍的问题:“RPC好,还是RESTful好?”

架构设计 阿尤 70浏览 0评论
看到知乎上有这样一个问题
WEB开发中,使用JSON-RPC好,还是RESTful API好?
还有其他优秀的推荐方案吗?
-----------------------------------------------------------------
先科普一下
REST 和 RESTful 什么区别?
REST,即Representational State Transfer的缩写。翻译过来是表现层状态转换。
如果一个架构符合REST原则,就称它为RESTful架构。
啥叫json-rpc?
接口调用通常包含两个部分,序列化和通信协议。常见的序列化协议包括json、xml、hession、protobuf、thrift、text、bytes等;通信比较流行的是http、soap、websockect,RPC通常基于TCP实现,常用框架例如netty。
RESTful通常采用http+JSON实现。
JSON-RPC是指通信协议采用二进制方式,而不是http,序列化采用JSON的形式。
被赞的最多的一个回答
翁伟 262 人赞同

JSON-RPC比RESTful API好很多。
======
我厌恶restful API如同我厌恶OOP;但与其说我厌恶restful,倒不如说我厌恶鼓吹restful API的一些伪·程序员。
很多鼓吹restful API的程序员,实际上并不理解restful的设计理念,纯粹是在人言亦言,随便看了几篇网文在说restful,自己便也更着鼓吹。
做为一个合格的技术人员,最基础的要求是要对自己所使用的技术有了解,明白各种技术的适用场景,然后因地制宜。
restful首先是要求必须把所有的应用定义成为“resource”,然后只能针对资源做有限的四种操作。
这是对API一个非常糟糕的抽象,有太多现实中需要的API,无法顺当的融入到restful所定义的规范中。
比方说,user login / resetpassword等等。
restful的信徒,他们会说可以根据这个那个规范,把login / password等也纳入为某种资源,然后进行增删改查。这在我看来,纯粹是在解决一些原本不存在,根本不需要解决的问题,纯浪费。
所有的接口,服务器端原本就存在有相应的函数,它们本来就有自身的命名空间,接受的参数、返回值、异常等等。
采用轻便的方式暴露出来即可。
无需把一堆函数重新归纳到“资源”,再削减脑袋把所有的操作都映射为“增删改查”。
对应到web上,rpc的成熟方案非常多,有古老的soap,也有轻量的json rpc。
JSON rpc基本上仅是要求所有的请求必须有msg id,有函数名,然后可定义参数,并且区分返回值与异常;也可定义『命名空间』来对函数模块做划分。
这与大多数语言的模块、函数定义相符,使用起来是非常便利的。
很多json rpc是供web前端ajax调用,若前端调用抽象得当,调用远程API,实际上与调用本地函数无甚区别。
实际上,json rpc也未必需要跟http绑定,即便是在web上,它也可以走web socket,这样子,前端可以使用同一web socket管道批量发送请求,而服务器端乱序返回结果时,前端也可以根据msg id做准确的回调。
websocket,批量调用,乱序返回,这些都可以显著提高API的输出吞吐,这些是在json rpc的设计考量内。
调用更方便,性能也更好,两全其美是完全可能的。
想当然的为了“快”,为了“简单”就必须牺牲别的,这是严重的思维误区。
有些方案,纯粹就是糟糕的方案。
restful API仅适用与业务非常简单的场景,比方说,就是为了提供少量数据表单的增删改查。而这种场景实在是太过简单,实际中几乎找不到。
----------------------------------------------------------
我的观点
实际上,这个问题本质上是RESTful和RPC之争。这两种风格都是随着架构发展而来。分别适用不同的场景。
http vs 高性能二进制协议
http相对更规范,更标准,更通用,无论哪种语言都支持http协议。如果你是对外开放API,例如开放平台,外部的编程语言多种多样,你无法拒绝对每种语言的支持,相应的,如果采用http,无疑在你实现SDK之前,支持了所有语言,所以,现在开源中间件,基本最先支持的几个协议都包含RESTful。
RPC协议性能要高的多,例如Protobuf、Thrift、Kyro等,(如果算上序列化)吞吐量大概能达到http的二倍。响应时间也更为出色。千万不要小看这点性能损耗,公认的,微服务做的比较好的,例如,netflix、阿里,曾经都传出过为了提升性能而合并服务。如果是交付型的项目,性能更为重要,因为你卖给客户往往靠的就是性能上微弱的优势。
RESTful的规范到底是不是鸡肋?
我认为,微服务的盛行,开放平台的盛行,的确让RESTful过于“流行”了。你可以看看,无论是Google、Amazon、netflix(据说很可能转向grpc),还是阿里,实际上内部都是采用性能更高的RPC方式。而对外开放的才是RESTful。
如果你的应用非常简单,无论用哪种都无所谓了,基本都能满足要求。
关于无状态、幂等
这个跟你是否采用RESTful无关,主要还是看接口内部实现,所以,把这个作为RESTful优点的可以闭嘴了。
安全性
显然,基于Http更安全一些,默认80端口,防火墙友好。
RESTful也分为严格的和自由的
RESTful还有个好处是制定了一系列规范,但是大多数使用者都是自由风格的,根本不是严格按照RESTful规范实现。当然存在就是道理,这样做更高效,但是不够通用。
无疑,严格按照资源抽象,API看起来更清晰,更容易被大家理解。同时,开发人员的复杂度也更高。
最后建议
对外开放给全世界的API推荐采用RESTful,是否严格按照规范是一个要权衡的问题。要综合成本、稳定性、易用性、业务场景等等多种因素。
内部调用推荐采用RPC方式。当然不能一概而论,还要看具体的业务场景。
另外一个因素是人,关键是你有什么人,postgresql、mysql都有用的不错的,迁来迁去,关键是你的人对哪个更熟悉。

感兴趣的可以去知乎看原文:http://www.zhihu.com/question/28570307


转载请注明:阿尤博客 » 一个虐你千百遍的问题:“RPC好,还是RESTful好?”

游客
发表我的评论 换个身份
取消评论

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
  • 验证码 (必填)点击刷新验证码