Ruby VS. Go, such large difference?
摘要：将服务器数量缩减到之前的十五分之一，并且降低了服务器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 听起来是。 Ruby 从一开始就优先考虑程序员的效率，用ruby写代码的速度几乎无人能比。go 语言编译器的作者那是当今业界的泰山北斗，运行效率和C不相上下。
这不是语言本身的问题，是编译器，解释器架构的问题。
如果把 ruby 直接转换成 go 程序，就不存在这样的问题了。
但是，只有优秀的程序员写的程序，才是很容易移植的，不管用什么语言写。 http://golang.org/ 访问不了 craaazy123 发表于 2013-03-18 07:28 static/image/common/back.gif
http://golang.org/ 访问不了
不存在这样的问题。{:3_185:} {:3_185:} rubyish 发表于 2013-03-19 07:13 static/image/common/back.gif
不存在这样的问题。
我电信的 就这样的 craaazy123 发表于 2013-03-19 04:52 static/image/common/back.gif
我电信的 就这样的
{:3_188:} {:3_185:} 这样?? 本帖最后由 zxfan 于 2013-03-29 18:47 编辑
回复 1# 兰花仙子
麻烦版主解释清楚是RoR这个框架比较的烂。或者说是基于历史原因，这些传统的采用多进程在web架构在本质上与node.js这种采用异步非阻塞进程技术的新框架比，其性能是远远不如的。当然也有用ruby实现的这种非阻塞进程的新架构，比如cramp，效率也很高，只是没啥名气用的人不多，比较小众而已。我不了解go，但我想说的是这个其实不关ruby什么事。 最近ruby和go等口水战很多 本帖最后由 laputa73 于 2013-04-27 12:10 编辑
编程语言本身,对程序员的限制还是很大的,不是语法,而是能力.
页:
[1]