使用另一種語言去重寫一個服務,聽起來是不是很折騰?然而雲服務供應商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。