使用Go代替Ruby,将服务器数量从30降到2

来源: 投稿
作者: taohongfei
2013-03-14

摘要:将服务器数量缩减到之前的十五分之一,并且降低了服务器CPU的使用率,Iron.io成功的做到了。Iron.io在遭遇了Ruby的限制后,大刀阔斧般的使用Go语言重写其名下服务IronWorker。

使用另一种语言去重写一个服务,听起来是不是很折腾?然而云服务供应商Iron.io就这么做了,并成功的将服务器从30台降至了2台。Iron.io在其官方博客上公布了整个事件的始末,下面来了解一下:

Iron.io与IronWorker

Iron.io起初为帮助其它公司建立应用程序的咨询公司,现为云服务供应商。Iron.io开发IronWorker的理由同样很老套:

之前说过Iron.io曾是家咨询公司,而在IronWorker开发的那段时间,AWS和Ruby on Rails是两个非常火的领域。而Iron.io有几个客户建立的硬件设施会不断的(7X24小时)给其发送数据,为了收集和处理这些数 据,Inro.io建立了他们自己的内部服务“worker as a service”。至于发行的原因就很老套了,在自己使用的同时,忽然觉得其它机构可能也会有类似的需求(很类似“书贩子”Amazon?),于是就诞生 了发行版IronWorker。

理所当然, IronWorker首发版使用的是Ruby和基于Rails的API。起先, IronWorker表现的很不错,花很少的精力和时间就可以支撑相当重的负载。然而很快 IronWorker就受到了Rails的限制:

又是RoR惹的祸

为了保持服务的流畅,Iron.io一直将其服务器CPU使用率保持在50-60%;CPU使用率一旦超过这个范围,就会增加服务器数量。当然如果不介意一直增加服务数量,这也是可行的,然而很快他们就介意了!

当某个“巨大”请求连接到它们的服务器,很可能就会产生一个多米效应导致整个服务器集群的崩溃:

一旦某些线程占用高于50%以上,Rails服务器CPU使用率将随之飙升到100%,而这个服务器将变的异常缓慢。负载均衡器则会认为这个服务器 发生故障,将其从服务器集群中移除;但是被移除服务器上的作业将会被分配到剩余的服务器上,于是问题就发生了——导致整个事件发生的线程并未被移除或得到 处理。就这样恶性循环产生,集群中的服务器被一台又一台的移除,直至整个系统崩溃。

唯一避免这个问题产生的方法就是增加足够的计算能力,这就意味着巨额成本的产生。基于多年的优秀(使用更少资源承担更多负载)开发经验,Iron.io决定重写API,做掉罪魁祸首的Rails,这样首先他们面临的就是究竟该使用什么编程语言。

Go的脱颖而出

首先他们考虑的就是回到Java的性能优势上来,然而经过多年使用Ruby的简洁、明了及有趣,Java因为编码效率上的劣势被抛弃。接着是又考虑 了一些比Ruby具备更高性能的脚本语言,比如:Python、JavaScript/Node;Java的派生物,比如:Scala和Clojure; 还有一些其它语言,比如:Erlang、Go等。而在一些原型和性能测试后,最终他们选择了Go。

而在当时的那个环境下选用Go伴随着很大的风险,因为:当时Go还没有很大的社区,也没有许多开源项目,同样也没有许多成功的用例。使用Go有太多不可预测性存在,比如招聘优秀的工程师;不过这些大部分都没有发生。

Go版本使用情况

Go版本推出后,Iron.io的服务器数量直接从30台减到了2台,附加的两台实现冗余服务器更是从未用到。CPU的使用率不到5%,而初始化过程中对比Rubby使用接近50M的内存,Go版本只是用了不到几百K。

原文链接: How We Went from 30 Servers to 2: Go (编译/仲浩 审校/王旭东)

展开阅读全文
100 收藏
分享
加载中
更多评论
180 评论
100 收藏
分享
返回顶部
顶部