[[68242]]

我們開發(fā)第一版的IronWorker已經(jīng)是3年前的事了，是用Ruby寫的，API基于Rails開發(fā)。我們沒用多久就發(fā)展成了相當(dāng)大的規(guī)模，很快我們就觸及到了Ruby程序的承載上限。長話短說，我們切換到了Go語言，請(qǐng)接著讀下去，下面是事情如何一步步發(fā)展的。

最初的設(shè)計(jì)

首先，做一點(diǎn)背景介紹：我們開發(fā)的第一版IronWorker，起初叫做SimpleWorker(很不錯(cuò)的名稱，不是嗎？)，用的是Ruby。我們過去是一個(gè)顧問公司，為其它公司開發(fā)應(yīng)用，在當(dāng)時(shí)有兩個(gè)東西被炒得非常火：亞馬遜的Web Services和Ruby on Rails。所以我們開發(fā)的應(yīng)用都基于AWS的Ruby on Rails架構(gòu)，并因此吸引了不少大客戶。我們開發(fā)IronWorker的初衷是來源我們自身的需求。我們有不少做硬件設(shè)備的客戶，他們會(huì)7×24小時(shí)不停的給我們發(fā)送數(shù)據(jù)，我需要收集這些數(shù)據(jù)，把它們整理成有用的信息。典型的做法就是讓定時(shí)任務(wù)每天每小時(shí)的遍歷這些數(shù)據(jù)。我們想到應(yīng)該開發(fā)一個(gè)東西，能夠處理所有用戶的數(shù)據(jù)，而不必做一大批的定時(shí)任務(wù)為每個(gè)客戶單獨(dú)處理。于是我們開發(fā)了一個(gè)服務(wù)類應(yīng)用，并在內(nèi)部使用了一段時(shí)間，但后來我們認(rèn)為一定會(huì)有其他的人也需要這個(gè)應(yīng)用，于是我們決定公布它，這樣，IronWorker誕生了。

我們的服務(wù)器可承受的CPU使用率大概在50-60%。當(dāng)超過這個(gè)額度，需要增加服務(wù)器來保持它在50%左右。只要我們不介意大量的服務(wù)器租用費(fèi)(我們當(dāng)然介意)，這種模式會(huì)工作的很好。但最大的問題是出現(xiàn)在流量大量陡增時(shí)。當(dāng)一個(gè)大型的流量高峰到來時(shí)，它會(huì)產(chǎn)生多米諾效應(yīng)，會(huì)拖垮我們整個(gè)的服務(wù)器集群。當(dāng)某些指標(biāo)超過50%的閥值時(shí)，我們的Rails服務(wù)器會(huì)吃掉100%的CPU使用率，變成無響應(yīng)狀態(tài)。這會(huì)導(dǎo)致負(fù)載均衡設(shè)備認(rèn)為它已經(jīng)宕了，把它移出分發(fā)池，于是這臺(tái)無響應(yīng)的服務(wù)器上的負(fù)載就會(huì)轉(zhuǎn)移到池中其他服務(wù)器上。因?yàn)槌刂惺Ｏ碌姆?wù)器需要承載這失去的服務(wù)器上的負(fù)載再加上流量高峰，必然會(huì)有第二臺(tái)服務(wù)器倒下，負(fù)載均衡設(shè)備又會(huì)把它移除，前赴后繼。很快池中所有的服務(wù)器都會(huì)耗盡。這種現(xiàn)象也叫做colossal clusterf**k (ref: +Blake Mizerany)。

這里是一個(gè)簡(jiǎn)單描繪多米諾宕機(jī)效應(yīng)的繪圖。

在這種架構(gòu)下避免這種事情發(fā)生的唯一辦法就是保持有大量的額外處理能力，讓我們的服務(wù)器的負(fù)載遠(yuǎn)低于它應(yīng)該能承受的能力，但這意味著要多花一大筆錢。必須讓這種狀態(tài)有所改變。

重寫應(yīng)用

我決定重寫這應(yīng)用。這是一個(gè)很容易的決定，很顯然，我們的Ruby on Rails無法支撐我們業(yè)務(wù)規(guī)模的增長。我們都有多年的開發(fā)Java的經(jīng)歷，曾經(jīng)寫過很多東西只需要很少的資源就能處理大量負(fù)載，遠(yuǎn)比Ruby on Rails的處理能力強(qiáng)的多，我知道我們可以做出很多改進(jìn)。于是，接下來的問題變成了應(yīng)該使用哪種語言？

選擇一種語言

我對(duì)任何新建議都持開放的態(tài)度，最不濟(jì)，我還可以重回到Java。Java是一個(gè)在很多方面（比如性能上）很棒的語言(是嗎？)，但經(jīng)過了多年的Ruby程序編寫后，我已經(jīng)為它的開發(fā)效率所癡迷。Ruby很有趣，樸素，簡(jiǎn)單。

我們搜索了一下比Ruby性能上要好的腳本語言(Ruby并不是很差)，比如Python和Javascript/Node，我們還研究了Java的衍生語言，如Scala和Clojure，和還有其它的語言例如Erlang(AWS使用了它)和Go語言(golang)。Go語言獲勝。事實(shí)上，它的作為基礎(chǔ)組成部分的并發(fā)特征太強(qiáng)悍了；它的標(biāo)準(zhǔn)核心庫提供了我們開發(fā)API服務(wù)需要的所有東西；它簡(jiǎn)潔；它編譯快；很像Ruby，Go語言很有趣；最后，數(shù)字是不會(huì)撒謊的。經(jīng)過了一次原型制作和性能測(cè)試后，我們知道了通過它我們可以將負(fù)載能力做重大的提高。經(jīng)過了征詢團(tuán)隊(duì)的意見(“這很好，它背后有Google支持”)，我們打起了攻堅(jiān)戰(zhàn)。

起初決定押寶Go語言時(shí)，這是一個(gè)有風(fēng)險(xiǎn)的決策。Go語言的社區(qū)并沒大量的形成，沒有多少開源的Go語言工程項(xiàng)目，在正式產(chǎn)品上使用Go語言的成功案例并不多(有嗎？)。而且我們并不敢肯定在認(rèn)定Go語言后能否招到這方面的頂級(jí)人才，但很快我們發(fā)現(xiàn)我們可以招到頂級(jí)人才——正是因?yàn)槲覀冞x擇了Go語言。我們是首個(gè)公司公開的宣稱在我們的產(chǎn)品中使用Go，首個(gè)公司在Go語言郵件列表里貼出Go語言工作職位招聘。很多頂級(jí)程序員希望來我們這里，就是因?yàn)檫@樣他們可以在每日的編程中使用Go語言。

Go語言的表現(xiàn)

[[68243]]

在我們推出了首個(gè)Go語言版本后，我們的服務(wù)器數(shù)量從30個(gè)減少到了2個(gè)，并且只留了2個(gè)服務(wù)器做冗余儲(chǔ)備。它們就像是根本沒有被使用，完全就像沒有任何程序在上面運(yùn)行。我們的CPU使用率低于5%，整個(gè)應(yīng)用的運(yùn)行啟動(dòng)只消耗了幾百KB的內(nèi)存(僅在啟動(dòng)時(shí))，相比之下Rails應(yīng)用要耗用50MB。這種比較甚至是包括了虛擬機(jī)內(nèi)存使用！這真是天與地的差別。從此我們?cè)僖矝]有經(jīng)歷過多米諾宕機(jī)的事故。

相比起之前，我們的業(yè)務(wù)增長了許多。我們有了更大的流量，我們?cè)黾恿藘蓚€(gè)新服務(wù)(IronMQ 和 IronCache)，我們有數(shù)百個(gè)服務(wù)器來支持客戶的需求。這全部是用Go做后臺(tái)馬達(dá)。回想起來，選擇Go語言是一個(gè)明智之舉，它讓我們開發(fā)出更好的產(chǎn)品，幫助公司成長，擴(kuò)大企業(yè)規(guī)模，并且吸引了一流人才。我相信它會(huì)繼續(xù)在可預(yù)見的未來幫助我們進(jìn)步。

英文原文：How We Went from 30 Servers to 2: Go

譯文鏈接：http://www.aqee.net/how-we-went-from-30-servers-to-2-go/