將服務(wù)器數(shù)量縮減到之前的十五分之一，并且降低了服務(wù)器CPU的使用率，Iron.io成功的做到了。Iron.io在遭遇了Ruby的限制后，大刀闊斧般的使用Go語言重寫其名下服務(wù)IronWorker。

[[66756]]

使用另一種語言去重寫一個(gè)服務(wù)，聽起來是不是很折騰？然而云服務(wù)供應(yīng)商Iron.io就這么做了，并成功的將服務(wù)器從30臺(tái)降至了2臺(tái)。Iron.io在其官方博客上公布了整個(gè)事件的始末，下面來了解一下：

Iron.io與IronWorker

Iron.io起初為幫助其它公司建立應(yīng)用程序的咨詢公司，現(xiàn)為云服務(wù)供應(yīng)商。Iron.io開發(fā)IronWorker的理由同樣很老套：

之前說過Iron.io曾是家咨詢公司，而在IronWorker開發(fā)的那段時(shí)間，AWS和Ruby on Rails是兩個(gè)非常火的領(lǐng)域。而Iron.io有幾個(gè)客戶建立的硬件設(shè)施會(huì)不斷的（7X24小時(shí)）給其發(fā)送數(shù)據(jù)，為了收集和處理這些數(shù) 據(jù)，Inro.io建立了他們自己的內(nèi)部服務(wù)“worker as a service”。至于發(fā)行的原因就很老套了，在自己使用的同時(shí)，忽然覺得其它機(jī)構(gòu)可能也會(huì)有類似的需求（很類似“書販子”Amazon？），于是就誕生 了發(fā)行版IronWorker。

理所當(dāng)然， IronWorker首發(fā)版使用的是Ruby和基于Rails的API。起先， IronWorker表現(xiàn)的很不錯(cuò)，花很少的精力和時(shí)間就可以支撐相當(dāng)重的負(fù)載。然而很快 IronWorker就受到了Rails的限制：

又是RoR惹的禍

為了保持服務(wù)的流暢，Iron.io一直將其服務(wù)器CPU使用率保持在50-60%；CPU使用率一旦超過這個(gè)范圍，就會(huì)增加服務(wù)器數(shù)量。當(dāng)然如果不介意一直增加服務(wù)數(shù)量，這也是可行的，然而很快他們就介意了！

當(dāng)某個(gè)“巨大”請求連接到它們的服務(wù)器，很可能就會(huì)產(chǎn)生一個(gè)多米效應(yīng)導(dǎo)致整個(gè)服務(wù)器集群的崩潰

一旦某些線程占用高于50%以上，Rails服務(wù)器CPU使用率將隨之飆升到100%，而這個(gè)服務(wù)器將變的異常緩慢。負(fù)載均衡器則會(huì)認(rèn)為這個(gè)服務(wù)器 發(fā)生故障，將其從服務(wù)器集群中移除；但是被移除服務(wù)器上的作業(yè)將會(huì)被分配到剩余的服務(wù)器上，于是問題就發(fā)生了——導(dǎo)致整個(gè)事件發(fā)生的線程并未被移除或得到 處理。就這樣惡性循環(huán)產(chǎn)生，集群中的服務(wù)器被一臺(tái)又一臺(tái)的移除，直至整個(gè)系統(tǒng)崩潰。

***避免這個(gè)問題產(chǎn)生的方法就是增加足夠的計(jì)算能力，這就意味著巨額成本的產(chǎn)生?；诙嗄甑膬?yōu)秀（使用更少資源承擔(dān)更多負(fù)載）開發(fā)經(jīng)驗(yàn)，Iron.io決定重寫API，做掉罪魁禍?zhǔn)椎腞ails，這樣首先他們面臨的就是究竟該使用什么編程語言。

Go的脫穎而出

[[66757]] 

首先他們考慮的就是回到Java的性能優(yōu)勢上來，然而經(jīng)過多年使用Ruby的簡潔、明了及有趣，Java因?yàn)榫幋a效率上的劣勢被拋棄。接著是又考慮 了一些比Ruby具備更高性能的腳本語言，比如：Python、JavaScript/Node；Java的派生物，比如：Scala和Clojure； 還有一些其它語言，比如：Erlang、Go等。而在一些原型和性能測試后，最終他們選擇了Go。

而在當(dāng)時(shí)的那個(gè)環(huán)境下選用Go伴隨著很大的風(fēng)險(xiǎn)，因?yàn)椋寒?dāng)時(shí)Go還沒有很大的社區(qū)，也沒有許多開源項(xiàng)目，同樣也沒有許多成功的用例。使用Go有太多不可預(yù)測性存在，比如招聘優(yōu)秀的工程師；不過這些大部分都沒有發(fā)生。

Go版本使用情況

Go版本推出后，Iron.io的服務(wù)器數(shù)量直接從30臺(tái)減到了2臺(tái)，附加的兩臺(tái)實(shí)現(xiàn)冗余服務(wù)器更是從未用到。CPU的使用率不到5%，而初始化過程中對比Rubby使用接近50M的內(nèi)存，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