# Iron.io 從 Ruby 遷移到 Go：減少了 28 臺服務器并避免了巨大的 Clusterf ** ks > 原文： [http://highscalability.com/blog/2013/3/13/ironio-moved-from-ruby-to-go-28-servers-cut-and-colossal-clu.html](http://highscalability.com/blog/2013/3/13/ironio-moved-from-ruby-to-go-28-servers-cut-and-colossal-clu.html)  在過去的幾個月中，我一直在使用 Go 編寫系統程序，因此我一直在尋找信息以補充我的確認偏見。 當 Iron.io 用 Go 重寫他們原來忙于工作的作業執行系統 IronWorker 時，Iron.io 寫下了他們的[經驗，這時機會突然出現，最初是用 Ruby 編碼的。](http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2-go.html) 結果： * 從 30 臺服務器降至 2 臺，第二臺服務器僅用于冗余。 * CPU 利用率降至 5％以下。 * 內存使用率下降。 只有“幾百 KB 的內存（在啟動時）與我們的 Rails 應用程序（約 50 MB）（在啟動時）”。 * 級聯故障現在已成為過去。 * 在數百臺服務器上運行的新服務全部用 Go 編寫。 * 他們相信使用 Go 可以使他們“制造出色的產品，成長和擴展并吸引 A 級人才。而且我相信它將繼續幫助我們在可預見的未來發展。” 通常，建議根據人才庫的規模選擇一種語言，他們發現選擇 Go 語言可以幫助他們吸引頂尖人才。 * 部署很容易，因為 Go 可以編譯為一個靜態映像。 * Go 的次要缺點：學習新語言和有限的庫。 * 對于將獲得大量流量的服務器以及要為突然增長做好準備的服務器，Go 是一個不錯的選擇。 當然，不受第二系統效果影響的重寫速度可能要快得多，但您可能還記得，LinkedIn 也有類似的經歷： [LinkedIn 從 Rails 遷移到節點：27 臺服務器被削減，速度提高了 20 倍](http://highscalability.com/blog/2012/10/4/linkedin-moved-from-rails-to-node-27-servers-cut-and-up-to-2.html) 這是 Go 問題解決的解釋： * 使用 Ruby，持續的服務器 CPU 使用率介于 50％和 60％之間。 添加服務器以將 CPU 使用率保持在 50％，以便可以正常處理流量高峰。 這種方法的缺點是需要水平擴展昂貴的服務器。 * 他們有一個非常有趣的失敗模式。 當流量激增時，Rails 服務器將達到 100％CPU。 這導致服務器出現故障，這導致負載均衡器將流量路由到其余服務器，這導致更多服務器的 CPU 使用率達到 100％。 最終結果是級聯失敗。 使用 Ruby 的上市時間論點很有道理。 性能并不是一切，但在這里我們看到了性能的價值，尤其是在 Web 層之外。 優質的服務是魯棒性和成本上的雙贏。 通常，弱點被數量掩蓋，數量昂貴且并不總是有效。 性能起到緩沖的作用，使系統能夠吸收流量而不會中斷，而在打卡機打孔后又能承受打卡機的沖擊。 即時分配，拆分新實例需要花費時間，時間足夠長，以至于流量峰值可能會導致級聯故障。 通過為性能而不是上市時間進行編碼，可以防止這些問題的發生。 ## 去并不完美 如果您查看 Go 的 Google 小組，Go 并非沒有[性能問題](https://groups.google.com/forum/?fromgroups#!searchin/golang-nuts/performance$20problem)。 這些問題通常可以被編碼。 例如，使用 bufio.ReadSlice 而不是 bufio.ReadString 可以刪除數據副本，神奇的是您的代碼快了 X 倍。 學習這些技巧需要時間，尤其是使用這種新語言時。 Go 絕對處于劣勢的地方是 JVM 和 V8 JavaScript Engine 多年來優化垃圾收集和代碼生成的地方。 Go 可能需要一段時間才能趕上。 表演從來都不是免費的。 您必須編寫聰明的代碼。 最小化共享狀態，不要浪費內存，不要像地獄那樣配置文件，了解您的語言并通過它來做正確的事情。 ## 相關文章 * [低級可伸縮性解決方案-條件收集](http://highscalability.com/blog/2013/3/11/low-level-scalability-solutions-the-conditioning-collection.html)-將工作盲目地排入隊列并不總是最好的方法。 * [規模甚大甚至贏不了-Google 和 Facebook 示例](http://highscalability.com/blog/2013/2/11/at-scale-even-little-wins-pay-off-big-google-and-facebook-ex.html) * [Google：馴服長時延的尾巴-當更多的機器等于更差的結果時](http://highscalability.com/blog/2012/3/12/google-taming-the-long-latency-tail-when-more-machines-equal.html) * [黑客新聞](https://news.ycombinator.com/item?id=5365096)的原始文章 * [發生了什么](http://jmoiron.net/blog/whats-going-on/)-現代語言中的 Hash 成癮探索 * [分析 Go 程序](http://blog.golang.org/2011/06/profiling-go-programs.html) 為什么去？ 為什么不選擇 Erlang？ Go 與這個故事無關。 根本原因是 Ruby。 當 Ruby 消失并被任何工業語言（可能是 Java，C＃或任何經過驗證的語言）取代時，問題也就消失了。 對于那些決定遷移到 Go 的用戶，有[高度優化的庫用于進程內緩存](https://github.com/valyala/ybc/tree/master/bindings/go/ybc)，[快速 Memcache 客戶端庫](https://github.com/valyala/ybc/tree/master/libs/go/memcache)和[為 SSD](https://github.com/valyala/ybc/tree/master/apps/go/memcached) 優化的 Memcache 服務器，全部以 走 ：） 仍然不知道您的問題是來自紅寶石還是鐵軌 為什么不使用 Python？ Waaat？ 從解釋代碼移至編譯代碼，并且性能得到改善？！ 這些“工程師”一定是天才！！！ 它們從 30 臺服務器減少到 2 臺服務器，這一事實證明了 Ruby 最初的選擇是多么的糟糕。 但是現在他們正在轉向 Go-一種更加晦澀的語言？ 這使我懷疑他們是否考慮了客戶的需求，或者他們是否只是想炫耀自己在最新技術方面的優勢。