在產生環境中使用 Go 語言兩年的總結

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

在iron.io的生產環境使用Go語言兩年後，我想分享我們的經驗和感受。我們是第一批在生產環境中使用Go（Go語言）的公司之一，長久以來我們不知道該有怎樣的預期，但到目前為止，很棒。 在之前發表的一篇文章從Ruby切換到Go中我談了一些，但這次將更具細節一些，我們喜歡這門語言以及一路上我們學到的東西。介紹沒有特定順序，按下面這樣： 效能表現（Performance） 記憶體佔用（Memory） 並發性（Concurrency） 可靠性（Reliability） 部署（Deployment） 天賦（Talent）

效能表現 當我們第一次決定要使用什麼語言時我們做了一些調研，為我們的應用環境、訊息佇列建立了一些類比。我用Go寫了我偏愛的beanstalkd的一個副本實現，使用beanstalkd協議，這樣我可以使用現有的用戶端測試。Go的表現的很好，幾乎和官方的C語言版本一樣（而且令人驚訝的容易寫）。 你可以在電腦語言基準測試遊戲網站找到Go和其他語言基準測試的比較。下面的圖是和Java（Java可能是Go語言不存在時我們應該使用的語言）比較的結果：   更多

這個基準測試表明，Go在一些例子下更快一些，但在其他例子中要比Java慢。然而，對於一個只有幾歲的語言來說不是太差勁，毫無疑問我認為再給它一些時日它肯定會趕上的。其中你也可以看到，記憶體佔用方面表現也很不錯。 只是為了好玩，到底來說C與Go和Ruby之間還有區別，在效能和記憶體使用量方面更讓人瘋狂。   更多  兩年以來，Go從來沒成為我們的瓶頸，瓶頸總在資料庫上。

記憶體佔用 Go不需要載入虛擬機器或解釋程式，所以它啟動快速和小巧。IronMQ啟動時使用~ 6444 KB的記憶體，其中還包括載入配置、建立串連等。當它運行一段時間後，記憶體使用量增加是因為它增加緩衝等。現在，我們的生產伺服器運行時記憶體佔用在~400 MB（這個我認為無關緊要，這取決於你的應用程式）。 兩年來，我們從來沒遇到過記憶體流失或其他記憶體相關的問題。 並發性（Concurrency） 並發是Go很重要的一部分，但高層次的結構讓使用起來很簡單。我使用Java很多年了，使用java.util.concurrency包很舒服，這是一個很好的並發性的工具，但它在使用簡易性和底層實現上不如Go。Go中使用Goroutines進行並行作業，使用channels在它們之間進行通訊。Goroutines非常有趣：

"Goroutines are part of making concurrency easy to use. The idea, which has been around for a while, is to multiplex independently executing functions—coroutines—onto a set of threads. When a coroutine blocks, such as by calling a blocking system call, the run-time automatically moves other coroutines on the same operating system thread to a different, runnable thread so they won't be blocked. The programmer sees none of this, which is the point. The result, which we call goroutines, can be very cheap: unless they spend a lot of time in long-running system calls, they cost little more than the memory for the stack, which is just a few kilobytes. To make the stacks small, Go's run-time uses segmented stacks. A newly minted goroutine is given a few kilobytes, which is almost always enough. When it isn't, the run-time allocates (and frees) extension segments automatically. The overhead averages about three cheap instructions per function call. It is practical to create hundreds of thousands of goroutines in the same address space. If goroutines were just threads, system resources would run out at a much smaller number." Source One thing we had to do here was limit concurrency to make sure we didn't overload our database or other services during spikes. We did this with a simple semaphore using Go channels.

可靠性 語言的可靠性是難以量化的，但我們發現我們的Go應用非常強大。我們碰到過一些失效/崩潰但是因為一些外部的問題（讀：資料庫或一些設計差的庫）。一般說來，現在有很多高品質的Go開源庫。我們還沒有發現記憶體流失和重大核心庫錯誤。 我甚至發現我們的代碼品質高是由於它是用Go寫的。我不知道這是為什麼，但用Go時寫東西時我感到溫暖和柔順。也許它是非常嚴格的編譯器，甚至迫使我們刪掉無用的引用和變數。也許它是用少量程式碼完成更多事的語言。今後我會找出類似的更多並把它們寫出來。

部署 Go 將所有的源碼編譯成單個的靜態連結的檔案，所以部署很簡單，只要上傳檔案然後啟動就可以，沒有任何的依賴。沒有運行時的依賴。不需要在伺服器上安裝Go。並且編譯完的二進位很小，IronMQ二進位檔案大約6MB 復原 如果你部署完成後運行有問題並且你需要復原到先前的程式，只要關閉錯誤的程式，重新運行先前的程式.程式編譯成單個二進位檔案後，不需要擔心升級之後的依賴問題。

天賦 在我們冒了很大的風險選擇Go的時候，Go並沒有被很多數人所瞭解，聽說過它的都很少。我們是第一個在Go語言愛好者郵件清單上發出Go招聘職位的公司，我們對申請人的應用品質吃了一驚。我們收到的職位申請中國，有一些使具有非凡經驗的頂尖科技公司的開發人員，有工作在某些核心項目的博士。大多數都不是使用Go做全時段編程，但在熟練Go和傳遞他們的經驗和知識方面都很努力。我不確定我們試圖建立的是否重要，但他們想用Go去工作。 我們第一個Go僱用者是一個Go的核心開發人員， Evan Shaw，他現在一直和我們在一起。

總結 經過兩年使用Go工作後我可以自信地說，我們做了正確的選擇。如果現在我們才開始iron.io的話，Go是想都不用想的選擇。很多其他公司現在正在使用Go，包括Heroku，Google及和我說及過Go的人都有類似的意見。Rob Pike，一個Go的創造者的說： “我們意識到我們在Google構建的軟體使用我們已有的語言並不能完全如設想的提供服務”Pike在2011說。“Robert Griesemer、Ken Thompson和我決定建立一門語言來寫Google需要的那類程式。 ” Derek Collison， Apcera的創立者，近期在 Wired的文章上說： “新技術的管理層和基礎設施層提供了這種雲交付模型？“他在Wired上這樣說。“在兩年之內，大部分將用Go來寫。 ” Go是我們一直在等待的下一代語言嗎？這一個點言之過早，但無疑是一個好的開始。

本文中的所有譯文僅用於學習和交流目的，轉載請務必註明文章譯者、出處、和本文連結
我們的翻譯工作遵照 CC 協議，如果我們的工作有侵犯到您的權益，請及時聯絡我們