使用 Go 一年的体验

Aleix Ventayol 的头像

·

·

·

10,164 次阅读

我们公司 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 库,因此你或许需要依赖其他人写的不能一直保证质量的库。

比如,对于使用 RedisElasticSearch 有很好的库,但是对于其他服务比如 Mixpanel 或者 Stripe 还没有好的。

我们建议在使用 Go 之前事先检查对于你需要的产品是否有好的库可用。

我们在 Go 的包管理系统上也遇到了很多问题。它处理版本的方式远没有达到最好,并且在过去的一年中,我们在不同的团队成员之间使用同一个库的不同版本上遇到了很多问题。然而,最近要归功于 Go 新支持的 vendor 包特性,除了 gopkg.in 服务外,这个问题基本被解决了。

开发者工具

由于 Go 是一门相对新的语言,你或许发现相比其他成熟的语言像 Java,它可用的开发工具并不很好。当我们开始 Bugfender 时,使用任何 IDE 都很困难,似乎没有 IDE 支持 Go。但是在过去的一年中,随着 IntelliJVisual 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中国 荣誉推出

2 条回复

  1. 编程浪子 [Chrome 58.0|Windows 7] 的头像
    编程浪子 [Chrome 58.0|Windows 7]

    从C++转做Go快两年了,感觉还可以,起码不用像C++一样担心内存泄漏(一般情况不会泄漏,也不排除特殊)。从C++转go比较方便,上手快,相当于由俭入奢;如果由python转go就比较麻烦(身边很多原python程序员成天抱怨。。。),会感觉没有python方便,相当于由奢入俭。各有利弊,各取所长吧。

    来自北京
  2. 枫落夜舞 [Chrome 59.0|Windows 10] 的头像
    枫落夜舞 [Chrome 59.0|Windows 10]

    用了Golang一段时间了,目前有几个难以接受的问题:
    1.没有成熟的异常处理机制,通过错误返回值来判断是否异常过于原始,很多时候需要完整的异常堆栈信息。
    2.没有泛型机制,无法很好的复用代码。静态强类型语言不支持泛型让我直接感觉回到了Java1.5之前,很难想象这是一门2009年发布的语言。

    Golang语言特性很少,加上由gofmt这样的工具统一团队代码风格,可以说是工程性很优秀的语言,但一些关键特性的缺失还是令很多人望而却步(说得好听叫简洁,说得难听叫简陋)。

    来自郑州

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注