Centos系统下载大全 | Redhat系统下载大全 | Windows2012系统下载大全 | Windows2008系统下载大全| CMS教程 | 网站地图 51运维网-专注Linux/Unix系统安全运维!
当前位置:51运维网 > 编程 > Ruby > 正文

Ruby 社区应该去 Rails 化了(1)

时间:2015-01-29 11:50 来源:网络整理 作者:51ou.com 阅读:

  从Linkedin和Iron.io抛弃ruby说起

  最近半年关于Ruby编程语言最负面的两条新闻莫过于2012年10月的报导:Linkedin从ruby迁移到node.js,30台服务器减到3台,以及2013年3月的报导:Iron.io从ruby迁移到Go,30台服务器减到2台

  node.js和Go都是最近两年服务器端高并发编程的热门语言,Linkedin和Iron.io抛弃Ruby迁移之后,都获得10倍以上的系统 性能提升,效果非常好。当然这两篇新闻报导引发的争议也非常大,最大的争议在于:原有Ruby编写的应用是随着业务经过长时间代码演化而成的,代码可维护 性和架构都已经存在严重的问题,即使沿用Ruby on rails重写,也会获得巨大的性能提升,非编程语言迁移之功。

  诚然,继续沿用Ruby on rails重写或者重构应用,性能可能会有一两倍的提升,但无法弥合10倍以上的性能差距,难道说ruby真的如此不堪吗?注定要被node.js或者Go所取代吗?

  Ruby的性能真的如此不堪吗?

  JGW Maxwell在2011年底做了一个Ruby Web框架的并发处理能力测试,还做了node.js的对比测试。用250个并发去做压力测试,后端使用MongoDB数据库,总共跑完10万个请求,测试结果如下:

  

Ruby 社区应该去 Rails 化了(1)

  纤程IO模型的性能是传统多进程模型的3-4倍,而Event IO则是多进程的6-7倍。值得一提的是Ruby的Event IO框架Cramp甚至性能超过了node.js。看来并发性能差的原因并不在Ruby。

  如果说这仅仅只是测试,不能说明问题,那么我再举一个真实的应用数据。去年年底我和@黄志敏交流,得知他为公司最近开发的一个API Server使用了Ruby的纤程框架Goliath,线上数据:

  ·VPS上总共使用了16个CPU内核,跑了16个单进程实例

  ·每个进程实例稳定消耗50MB内存

  ·Web框架使用Goliath, URL分发是grape,数据库访问使用ActiveRecord,缓存使用Redis

  ·应用吞吐量达到了1800 request/s

  这个数据意味着一台配备了4颗4核CPU,2G内存的服务器,每天可以处理 1.5亿次 web请求。由此可见,Ruby完全可以做到高并发IO的应用。问题主要不在ruby解释器上,而在Rails框架上。更准确的说就是, ruby on rails作为一个full-stack的web开发框架,并不适合用来开发Linkedin和Iron.io的后台web服务,从某种意义上来说,属于rails的时代已经过去了

  移动时代,Web服务将取代Web网站

  随着最近几年智能手机的迅速普及,如今来自智能手机和移动设备的总体Web访问和服务请求量已经超过了传统的PC,这意味着Web时代主流的 Browser/Server的架构重新回到了Mobile Client/Server的架构。在B/S架构下,在服务器端生成完整的HTML页面,我们需要开发一个完整的Website;但在移动时代,服务器端 的功能大大简化了,退化成了Web API调用接口提供者,而复杂的界面构造、交互和运算都是在移动客户端完成的。

  传统的Website将越来越让位于Web Service,移动客户端无论是iOS,Android还是HTML5都通过API调用获取服务器端的json/xml格式的数据,无需服务器端生成 HTML页面了。这种B/S架构重新往C/S架构的迁移,也意味着full-stack Web框架将越来越没有用武之地了。

  Web服务器端并发常见的三种应用场景:

  ·Website:传统Web网站

  ·Web Service:Web服务端提供API调用接口

  ·real-time:Web实时推送

  

Ruby 社区应该去 Rails 化了(1)

  我们看Linkedin和Iron.io的案例,都是非常典型的Web Service的应用场景:Linkedin使用Rails开发了移动服务器的API网关,而Iron.io用Rails开发了搜集客户设备数据的后台服 务,这些都不是Rails最擅长的开发website的场景,所以最终Rails被抛弃,并不是一个很意外的结果。

  Rails为何不适合做Web Service?

  我发现了一个有意思的现象,最早的一批用Ruby开发Web Service服务的网站,都选择了用Rails开发,而在最近几年又不约而同抛弃Rails重写Web服务框架。当初用Rails的原因很简单,因为产 品早期起步,不确定性很高,使用Rails快速开发,可以最大限度节约开发成本和时间。但为何当请求量变大以后,Rails不再适合了呢?

  这主要是因为Rails本身是一个full-stack的Web框架,所有的设计目标就是为了开发Website,所以Rails框架封装过于厚重,对于需要更高性能更轻薄的Web Service应用场景来说,暴露出来了很多缺陷:

  Rails调用堆栈过深,URL请求处理性能很差

  Rails的设计目标是提供Web开发的 最佳实践 ,所以无论你需要不需要,Rails默认提供了开发Website所有可能的组件,但其中绝大部分你可能一辈子都用不上。例如Rails项目默认添加了20个middleware,但其中10个都是可以去掉的,我们自己的项目当中手工删除了这些middleware:

  config.middleware.delete'Rack::Lock'    # 多线程加锁,多进程模式下无意义  
  config.middleware.delete'Rack::Runtime' # 记录X-Runtime(方便客户端查看执行时间)  
  config.middleware.delete'ActionDispatch::RequestId' # 记录X-Request-Id(方便查看请求在群集中的哪台执行)  
  config.middleware.delete'ActionDispatch::RemoteIp'  # IP SpoofAttack  
  config.middleware.delete'ActionDispatch::Callbacks' # 在请求前后设置callback  
  config.middleware.delete'ActionDispatch::Head'      # 如果是HEAD请求,按照GET请求执行,但是不返回body  
  config.middleware.delete'Rack::ConditionalGet'      # HTTP客户端缓存才会使用  
  config.middleware.delete'Rack::ETag'    # HTTP客户端缓存才会使用  
  config.middleware.delete'ActionDispatch::BestStandardsSupport' # 设置X-UA-Compatible, 在nginx上设置  

  其中最夸张的是ActionDispatch::RequestIdmiddleware,只有在大型应用部署在群集环境下进行线上调试才可能用到的功能,有什么必要做成默认的功能呢? Rails的哲学是:提供最全的功能集给你,如果你用不到,你自己手工一个一个关闭掉 ,但是这样带来的结果就是默认带了太多不必要的冗余功能,造成性能损耗极大。

  我们看一个Ruby web框架请求处理性能评测 ,这个评测不访问数据库,也不测试并发性能,主要是测试框架处理URL请求路由,渲染文本,返回结果的处理速度。

  

Ruby 社区应该去 Rails 化了(1)

  Sinatra至少是Rails速度的3倍以上。

标签: Rails Ruby

感谢您对【51运维网 http://www.51ou.com/】的支持,我们为您免费提供《Ruby 社区应该去 Rails 化了(1)》技术文章,《Ruby 社区应该去 Rails 化了(1)》详细使用和说明,有时《Ruby 社区应该去 Rails 化了(1)》可能不完善、敬请谅解!如果《Ruby 社区应该去 Rails 化了(1)》有错误请给我们留言,我们将尽快修复文章错误,如果您觉得本站不错,请分享给周围的朋友!谢谢!

顶一下
(0)
0%
踩一下
(0)
0%
发表评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
验证码:点击我更换图片