激活 Google 生产：Google 的网站可靠性工程团队如何使用 Go

Google 运行着少量非常大型的服务。这些服务由覆盖开发者所需一切的全球基础设施提供支持：存储系统、负载均衡器、网络、日志记录、监控等等。尽管如此，它并不是一个静态系统——它不可能是静态的。架构不断演进，新产品和新想法不断涌现，必须推出新版本、推送配置、更新数据库架构等等。我们最终会以每秒数十次的频率向我们的系统部署更改。

由于这种规模和对可靠性的关键需求，Google 率先推出了网站可靠性工程 (SRE)，许多其他公司随后也采用了这一角色。“SRE 是在您将运维视为软件问题时获得的。我们的使命是保护、提供和推进所有 Google 公共服务背后的软件和系统，并始终密切关注其可用性、延迟、性能和容量。” — 网站可靠性工程 (SRE)。

2013-2014 年，Google 的 SRE 团队意识到我们对生产管理的方法在很多方面已经不再奏效。我们已经远远超越了 shell 脚本，但我们的规模有如此多的活动部分和复杂性，以至于需要一种新的方法。我们确定我们需要转向一种称为“Prodspec”的生产声明模型，驱动一种称为“退火”的专用控制平面。

当我们启动这些项目时，Go 刚刚成为 Google 上关键服务的可行选项。大多数工程师更熟悉 Python 和 C++，其中任何一种都是有效的选择。然而，Go 吸引了我们的兴趣。新奇的吸引力当然是一个因素。但更重要的是，Go 承诺在性能和可读性之间找到一个 Python 和 C++ 都无法提供的平衡点。我们针对退火和 Prodspec 的一些初始部分启动了一个小型 Go 实验。随着项目的进展，那些用 Go 编写的初始部分发现自己处于核心位置。我们对 Go 很满意——它的简单性让我们越来越喜欢，性能就在那里，并发原语很难被取代。

在任何时候都没有使用 Go 的强制要求，但我们不想返回 Python 或 C++。Go 在退火和 Prodspec 中有机增长。这是正确的选择，因此现在是我们选择的语言。现在，Google 生产的大部分由我们用 Go 编写的系统管理和维护。

在这些项目中使用简单语言的力量难以夸大。确实有一些功能缺失的情况，例如在代码中强制执行某些复杂结构不应该发生突变的能力。但对于这些情况中的每一个，无疑都有几十或数百个情况，其中简单性有所帮助。

例如，退火影响了各种团队和服务，这意味着我们严重依赖于整个公司的贡献。Go 的简单性让团队外部的人员能够看到某些部分或其他部分为何对他们不起作用，并且经常自己提供修复或功能。这让我们能够快速增长。

Prodspec 和退火负责一些非常关键的组件。Go 的简单性意味着代码易于遵循，无论是在审查期间发现错误还是在尝试确定服务中断期间究竟发生了什么时。

Go 的性能和并发性支持对我们的工作也是至关重要的。由于我们的生产模型是声明性的，我们倾向于处理大量结构化数据，这些数据描述了生产是什么以及应该是什么。我们有大型服务，因此数据可能会增长很大，这通常会使纯顺序处理不够高效。

我们正在以多种方式在许多地方处理此数据。这并不是让一个聪明人想出我们算法的并行版本的问题。这是一个偶然并行的问题，找到下一个瓶颈并对该代码部分进行并行化。而 Go 正是实现了这一点。

由于我们在 Go 上取得了成功，我们现在将 Go 用于 Prodspec 和 Annealing 的每项新开发。

除了网站可靠性工程团队之外，Google 的各个工程团队在其开发过程中都采用了 Go。了解核心数据解决方案、Firebase 托管和Chrome团队如何使用 Go 大规模构建快速、可靠且高效的软件。