译注：发表这篇文章 ， 不代表我认同作者的观点 。 大家都知道 ， 在国内 ， Go 已经被很多大厂使用 ， 早就可以用于企业系统 。
对一门语言的爱 ， 可以接受任何不同的观点 ， 真理总是越辩越明 ， 相信有不同的声音 ， Go 也会越来越好 。 欢迎大家留言发表你的看法 。
介绍企业应用程序是一个寿命长、可靠的系统 ， 具有多年的持久数据 。 如今 ， Golang 的世界并没有提供以企业系统构建方式构建系统的可能性 。
文章插图
Martin Fowler 的“企业应用程序”
Golang 的发展文化让我们考虑几个问题 ， 如错误处理不当、 手动组合的 SQL 查询和面向轮子开发 。
错误处理不当Golang 在错误处理方面提供了更多的自由 。 由于开发人员方面缺乏责任 ， 这通常会导致应用程序中的错误处理不当 。
最常见的情况与 sql 查询的执行有关：
defer rows.Close() // omitted errors from sql driver没有明确的方法来处理此返回的错误 。 实际上 ， 该语言提供了捕获错误的特定方法：
result, err := foo()该错误是一个典型的返回值 ， 可以通过各种方式忽略：
defer rows.Close() // omitted errors from sql driverdefer body.Close() // omitted IO errorsresult, _ := foo() // omitted errors from foo function
文章插图
sketch: Now you come to Me and you say “Don Gopher, handle Me.” But you don’t ask with respect. you don’t offer friendship.
此外 ， 它会导致应用程序在 panic 函数调用后立即崩溃的风险增加 ， 并且通常会降低可靠性 。
根据 M.Nygard 的 “Release it!” ， 可靠的系统必须处理每个不重要的错误而不会崩溃 。 没有权衡 。
作为解决方案 ， 我们可以使用其他语言的 try/catch/finally 结构添加可靠的机制 。 此外 ， 还需要消除 panic 函数 。 当然 ， 这将是一种较慢的方法 ， 但更可靠 。
手动编写 SQL 查询语句Golang 中处理数据库查询的典型方法是手动编写查询 。 如果 SQL 查询被手工编写的 ， 那么数据库集成将是一个瓶颈 。 并非所有开发人员都擅长 SQL 和使用数据库 。 诸如 Hibernate（Java）和 Entity Framework（.NET）之类的功能齐全的 ORM 生成的典型查询已开放 ， 用于数据库和缓存数据优化 。 这是根据 ‘Release it’ 来编写可靠的应用程序的最有效方法之一 。
有些库将来可能是功能齐全的ORM（例如 GORM 和 XORM） 。 我相信 ， 与手工编写的 SQL 查询相比 ， 它们将来会更受欢迎 。
重新发明轮子通常 ， Golang 开发人员都在选择重新发明轮子 。 轮子无处不在：task scheduler ， 迁移工具 ， logger ， worker pool ， 十进制数字的库 ， 授权库和其他工具 。
它们没有经过良好的测试 ， 没有良好的文档 ， 在生产中使用不足 。 风险太高 ， 不能在企业应用程序中使用它们 。
为了减少使用风险代码的可能性 ， 检查是否有可用的解决方案 。 例如可以查看： 。
生态系统Go 世界的生态系统包括 Consul, Kubernetes, Zipkin 和 Tr?fik 等 。 它是一个非常年轻且发展迅速的技术栈 ， 没有公认的使用标准 。
Golang 生态系统中没有任何工具可以帮助建立可靠的企业系统 。
考虑到以上所有情况 ， 我们需要非常谨慎地将第三方中间件集成到基础架构中 ， 公司必须有足够的专业知识支持该过程 。 否则 ， 它将成为具有不同技术的生产环境中的雷区 。 好消息是 ， 市场有很多管理解决方案 ， 以最大限度地降低风险 。 不幸的是 ， 它很贵 。
Golang 生态系统太年轻 ， 缺乏工具、编程文化 ， 但我相信它将来会成为一个伟大的生态系统 ， 并拥有伟大的程序员 。 语言社区正朝着正确的方向努力：性能和简化 。 但是 ， 我们不能忘记可靠性也很重要 。 我们越早了解可靠性的价值 ， 我们就会越快地用 Golang 编码更多、更好的企业系统 。
P.S.【观点：Go 尚未准备好用于企业系统，原因在这里】我很惊讶 ， 这篇文章有这么多的解释 。 可惜很多人错过了文章的重点 。
这篇文章：
1）不是关于我
2）不是关于我的技能
3）不是关于我的狗
*4）*不是关于“为什么我的狗在其企业狗系统中不需要使用 Golang”
5）不是关于 Golang 的最佳编码实践
6）不是关于与处理 go 错误有关的最佳实践
7）不是关于如何以正确的方式选择正确的工具