go語言一年的實踐經驗！

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

導讀	如公司名暗示的那樣，我們是開發行動裝置 App的。在發布一個應用給公眾後，我們很快意識到我們缺失一個工具來檢查使用者實際發生的情況以及他們是如何與應用互動的 - 如果有任何問題或者 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 的各個方面之後，我們意識到 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

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載自：http://www.linuxprobe.com/go-1years-experence.html

免費提供最新Linux技術教程書籍，為開源技術愛好者努力做得更多更好，開來源站點點：http://www.linuxprobe.com/