使用 Go 一年的體驗
我們公司 Mobile Jazz 從一個內部試驗性項目開始使用 Go。如公司名暗示的那樣,我們是開發移動應用的。
在發布一個應用給公眾後,我們很快意識到我們缺失一個工具來檢查用戶實際發生的情況以及他們是如何與應用交互的 - 如果有任何問題或者 bug 的報告,這將會相當方便。
現在有幾款工具聲稱能在這個方面幫助開發者,但是沒有一個能完全滿足要求,因此我們決定自己構建一個。我們開始創建一組基礎的腳本,如今它很快進化成了完整的工具,稱為 Bugfender!
由於這最初是一個實驗,我們決定使用一種新的趨勢技術。對學習以及持續教育的熱愛是 Mobile Jazz 的核心價值的之一,因此我們決定使用 Go 構建。這是一個由 Google 開發的相對較新的編程語言。它是編程世界的的新玩家,已經有許多受尊敬的開發者對它讚不絕口。
一年後,這個實驗變成了一個初創項目,我們擁有了一個已經幫助了來自全世界的數以千計的開發者的令人難以置信的工具。我們的伺服器每天處理來自 700 萬台設備的超過 200GB 的數據。
在使用 Go 一年之後,我們想要分享我們將一個小小的實驗變成處理百萬日誌的生產伺服器的一些想法和經驗。
Go 生態系統
公司中沒有人有使用 Go 的經驗。Bugfender 是我們第一次深入這個語言。
學習基本上相當直接的。我們之前在 C/C++/Java/Objective-C/PHP 的經驗讓我們學習 Go 相當快,並且在幾天內就開始開發了。當然會有一些新的和不常見的東西需要學習,包括 GOPATH 還有如何處理包,但這在我們的預期之內。
幾天之內,我們意識到即使是一個以簡化為設計目的的語言,Go 也是非常強大的。它能夠做任何現代編程語言應該能做的事:能夠處理 JSON、伺服器之間通訊甚至訪問資料庫也沒問題(並且只需要幾行代碼)。
在構建一個伺服器時,你應該首先決定是否使用任何第三方庫或者框架。對於 Bugfender,我們決定使用:
Martini
Martini 是一個強大的 Go 的 web 框架。我們開始這個實驗時,它是一個很棒的解決方案,至今也是,我們還沒遇到任何問題。然而如果我們今天再次開始這個實驗的話,我們會選擇一個不同的框架,因為 Martini 不在維護了。
我們還試驗了 Iris(我們目前的最愛)還有 Gin。Gin 是 Martini 繼任者,並且遷移到這上能讓我們重用已有的代碼。
在過去的一年中,我們意識到 Go 的標準庫是非常強大的,你不必依靠一個臃腫的 web 框架來構建一個伺服器。最好在特定任務上使用專門的高性能庫。
Iris 是我們目前最喜歡的,並且將來我們將使用它重寫服務來替代 Martini/Gin,但這目前並不是優先的。
修改: 在討論了 Iris 的各個方面之後,我們意識到 Iris 或許不是最好的選擇。如果我們決定重寫我們的 web 組件,我們或許會研究其他的選擇,我們歡迎你的建議。
Gorm
有些人喜歡 ORM,而有些人則不喜歡。我們決定使用 ORM,更確切地說是 GORM。我們的實現只針對 web 前端,對於日誌提取 API 仍然繼續使用手工優化的 SQL。在一開始,我們確實很喜歡它,但是隨著時間的推移,我們開始發現問題,並且我們很快將它從代碼中完全移除,並且使用 sqlx 這個標準 SQL 庫。
GORM 的一個主要問題是 Go 的生態系統。作為一個新語言,自我們開始開發產品以來 Go 已經有很多新版本。在這些新版本中的一些改變並不向後兼容,因此要使用最新的庫版本,我們要經常重寫已有代碼並檢查我們為解決版本問題所做的 hack。
上述這兩個庫是大多數 web 服務的主要組件,因此做一個好的選擇很重要,因為將來更改會很困難,並且會影響你伺服器的性能。
第三方服務
在創建一個實際使用的產品的另外一個重要方面是考慮庫、第三方服務和工具的可用性。在這方面,Go 還缺乏成熟度,大多數公司還沒有提供 Go 庫,因此你或許需要依賴其他人寫的不能一直保證質量的庫。
比如,對於使用 Redis 和 ElasticSearch 有很好的庫,但是對於其他服務比如 Mixpanel 或者 Stripe 還沒有好的。
我們建議在使用 Go 之前事先檢查對於你需要的產品是否有好的庫可用。
我們在 Go 的包管理系統上也遇到了很多問題。它處理版本的方式遠沒有達到最好,並且在過去的一年中,我們在不同的團隊成員之間使用同一個庫的不同版本上遇到了很多問題。然而,最近要歸功於 Go 新支持的 vendor 包特性,除了 gopkg.in 服務外,這個問題基本被解決了。
開發者工具
由於 Go 是一門相對新的語言,你或許發現相比其他成熟的語言像 Java,它可用的開發工具並不很好。當我們開始 Bugfender 時,使用任何 IDE 都很困難,似乎沒有 IDE 支持 Go。但是在過去的一年中,隨著 IntelliJ 和 Visual Studio Code Go 插件的引入,這一切改善了很多。
最後看下其他的 Go 工具,調試器並不很好,而分析器甚至更糟,因此有時調試你的代碼或者嘗試優化它會很困難。
前往生產
這確實是 Go 最好的東西之一,如果你想要部署一些東西到生產環境中,你只需要構建你的二進位並發送到伺服器中,沒有依賴,不需要安裝額外的軟體,你只需要能在伺服器中運行二進位文件就行。
如果你習慣於處理那些需要包管理器或者需要小心你使用的語言解釋器的語言,用 Go 工作會感到很高興。
我們對 Go 的穩定性也很滿意,因為伺服器似乎從沒有崩潰過。我們在發送大量數據給 Go Routines 時遇到過一個問題,但是我們幾乎沒見到任何崩潰。注意:如果你需要發送大量數據給 Go Routine,你需要小心堆溢出。
如果你對性能感興趣,我們沒法與其他語言相比較,因為我們從零開始使用 Go,但是對於我們處理的數據量,我們感覺性能是非常好的,我們絕對不能如此輕鬆地使用 PHP 處理同等數量的請求。
總結
在過去的一年中,我們對 Go 的感覺起起伏伏。最初我們是興奮的,但是在實驗變成真實的產品後我們開始發現問題。我們幾次考慮過用 Java 完全重寫,但是目前為止,仍舊使用的是 Go,並且過去的一年中, Go 生態已經有了很大的提升,這簡化了我們的工作。
如果你想要使用 Go 構建你的產品,你可以保證它可以工作,但是你確實需要小心一件事:可以僱傭的開發者。矽谷中只有很少的高級 Go 開發者,並且在其他地方尋找也是一件非常困難的任務。
via: https://bugfender.com/one-year-using-go
作者:ALEIX VENTAYOL 譯者:geekpi 校對:wxy
本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive