我们是如何让服务器从30台缩减到2台的:从ruby迁移到go语言

来源:外刊评论,英文原文:how we went from 30 servers to 2: go

我们开发第一版的ironworker已经是3年前的事了，是用ruby写的，api基于rails开发。我们没用多久就发展成了相当大的规模，很快我们就触及到了ruby程序的承载上限。长话短说，我们切换到了go语言，请接着读下去，下面是事情如何一步步发展的。

最初的设计

首先，做一点背景介绍：我们开发的第一版ironworker，起初叫做simpleworker(很不错的名称，不是吗？)，用的是ruby。我们过去是一个顾问公司，为其它公司开发应用，在当时有两个东西被炒得非常火：亚马逊的web services和ruby on rails。所以我们开发的应用都基于aws的ruby on rails架构，并因此吸引了不少大客户。我们开发ironworker的初衷是来源我们自身的需求。我们有不少做硬件设备的客户，他们会7×24小时不停的给我们发送数据，我需要收集这些数据，把它们整理成有用的信息。典型的做法就是让定时任务每天每小时的遍历这些数据。我们想到应该开发一个东西，能够处理所有用户的数据，而不必做一大批的定时任务为每个客户单独处理。于是我们开发了一个服务类应用，并在内部使用了一段时间，但后来我们认为一定会有其他的人也需要这个应用，于是我们决定公布它，这样，ironworker诞生了。

我们的服务器可承受的cpu使用率大概在50-60%。当超过这个额度，需要增加服务器来保持它在50%左右。只要我们不介意大量的服务器租用费(我们当然介意)，这种模式会工作的很好。但最大的问题是出现在流量大量陡增时。当一个大型的流量高峰到来时，它会产生多米诺效应，会拖垮我们整个的服务器集群。当某些指标超过50%的阀值时，我们的rails服务器会吃掉100%的cpu使用率，变成无响应状态。这会导致负载均衡设备认为它已经宕了，把它移出分发池，于是这台无响应的服务器上的负载就会转移到池中其他服务器上。因为池中剩下的服务器需要承载这失去的服务器上的负载再加上流量高峰，必然会有第二台服务器倒下，负载均衡设备又会把它移除，前赴后继。很快池中所有的服务器都会耗尽。这种现象也叫做colossal clusterf**k (ref: +blake mizerany)。

这里是一个简单描绘多米诺宕机效应的绘图。

在这种架构下避免这种事情发生的唯一办法就是保持有大量的额外处理能力，让我们的服务器的负载远低于它应该能承受的能力，但这意味着要多花一大笔钱。必须让这种状态有所改变。

重写应用

我决定重写这应用。这是一个很容易的决定，很显然，我们的ruby on rails无法支撑我们业务规模的增长。我们都有多年的开发java的经历，曾经写过很多东西只需要很少的资源就能处理大量负载，远比ruby on rails的处理能力强的多，我知道我们可以做出很多改进。于是，接下来的问题变成了应该使用哪种语言？

选择一种语言

我对任何新建议都持开放的态度，最不济，我还可以重回到java。java是一个在很多方面（比如性能上）很棒的语言(是吗？)，但经过了多年的ruby程序编写后，我已经为它的开发效率所痴迷。ruby很有趣，朴素，简单。

我们搜索了一下比ruby性能上要好的脚本语言(ruby并不是很差)，比如python和javascript/node，我们还研究了java的衍生语言，如scala和clojure，和还有其它的语言例如erlang(aws使用了它)和go语言(golang)。go语言获胜。事实上，它的作为基础组成部分的并发特征太强悍了；它的标准核心库提供了我们开发api服务需要的所有东西；它简洁；它编译快；很像ruby，go语言很有趣；最后，数字是不会撒谎的。经过了一次原型制作和性能测试后，我们知道了通过它我们可以将负载能力做重大的提高。经过了征询团队的意见(“这很好，它背后有google支持”)，我们打起了攻坚战。

起初决定押宝go语言时，这是一个有风险的决策。go语言的社区并没大量的形成，没有多少开源的go语言工程项目，在正式产品上使用go语言的成功案例并不多(有吗？)。而且我们并不敢肯定在认定go语言后能否招到这方面的顶级人才，但很快我们发现我们可以招到顶级人才——正是因为我们选择了go语言。我们是首个公司公开的宣称在我们的产品中使用go，首个公司在go语言邮件列表里贴出go语言工作职位招聘。很多顶级程序员希望来我们这里，就是因为这样他们可以在每日的编程中使用go语言。

go语言的表现

在我们推出了首个go语言版本后，我们的服务器数量从30个减少到了2个，并且只留了2个服务器做冗余储备。它们就像是根本没有被使用，完全就像没有任何程序在上面运行。我们的cpu使用率低于5%，整个应用的运行启动只消耗了几百kb的内存(仅在启动时)，相比之下rails应用要耗用50mb。这种比较甚至是包括了虚拟机内存使用！这真是天与地的差别。从此我们再也没有经历过多米诺宕机的事故。

相比起之前，我们的业务增长了许多。我们有了更大的流量，我们增加了两个新服务(ironmq 和 ironcache)，我们有数百个服务器来支持客户的需求。这全部是用go做后台马达。回想起来，选择go语言是一个明智之举，它让我们开发出更好的产品，帮助公司成长，扩大企业规模，并且吸引了一流人才。我相信它会继续在可预见的未来帮助我们进步。