微信号:infoqchina

介绍:有内容的技术社区媒体

从Ruby迁移到Go能解决什么问题?看看Iron.io的经验吧

2013-03-26 16:42 InfoQ

Iron.io中非常忙碌的作业执行系统最初是用Ruby编写的。


用Go重写的结果是:

  • 服务器数量从30台减少到2台,而且第2台仅用于实现冗余。

  • CPU利用率下降至5%以下。

  • 所用内存也下降了很多。Rails应用在启动时需要接近50MB内存,而Go版本在启动时只需要几百KB内存。

  • 连锁故障成为历史。

  • 运行于成百上千台服务器上的新服务完全用Go编写。

  • 他们认为,Go的使用使他们得以“构建伟大的产品,得以成长和扩展,同时还能吸引一流人才”。他们的博客中写道:“我们认为,在可预见的未来,它将继续帮助我们成长。”一般建议根据人才库的规模来选择编程语言,他们发现Go语言的选择帮助他们吸引了顶级人才。

  • 容易部署,因为Go程序会编译为一个单一静态映像。

  • Go存在的小问题:需要学习一种新语言,库还有限。

  • 如果服务器流量很高,或者你想应对突发的增长,Go是很好的选择。

当然,如果没有第二系统效应(Second System Effect)的影响,重写会快得多,不过你可能会回想起LinkedIn的类似经验:LinkedIn从Rails迁移到Node后,服务器减少了27台,速度提升多达20倍。


下面说明一下Go解决的问题:

  • 在使用Ruby时,服务器的CPU利用率维持在50%到60%之间。为将CPU利用率保持在50%左右,可以增加服务器,这样就可以优雅地处理流量峰值。但这种方式有个缺点:需要昂贵的服务器来进行水平扩展。

  • 他们有一个非常有趣的故障模式。当流量出现峰值时,Rails服务器的CPU利用率将达到100%。这就致使该服务器看上去是失效了,进而引发负载均衡器把流量路由到其余服务器上,这样更多服务器的CPU利用率会飙升到100%。最终导致连锁故障。

使用Ruby有助于产品快速上市,这个理由十分在理。虽说性能并非一切,但这里我们看到了性能的价值,尤其是在Web层之外,性能更为重要。表现良好的服务在健壮性和成本方面都有巨大优势。


点击“阅读原文”查看更多内容并吐槽吧。

 
InfoQ 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 豆瓣对服务化改造实践的若干思考 为什么redis内存不宜过大 Android中so知识总结和常见问题归纳以及插件开发过程中加载so的方案解析 ffmpeg基础 适用于 BootStrap 站点的 15 个免费 jQuery 轮播图插件