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

kewin · 2013年03月14日 · 最后由 yfractal 回复于 2017年09月29日 · 11726 次阅读

摘要：将服务器数量缩减到之前的十五分之一，并且降低了服务器 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（编译/仲浩审校/王旭东）转自 http://www.oschina.net/news/38585/how-we-went-from-30-servers-to-2-go

6 个赞