背景信息

在开始之前，先介绍一下我在谷歌的经历。2003 年大学毕业后我直接加入了谷歌，在这之前我是一个音乐营地的营地顾问，营地顾问之前我在一家冰激凌店工作。我还记得在谷歌的第一天，第一个项目的技术负责人是 Andrew Fights，他现在是类似谷歌杰出的工程师的角色，我记得当时告诉他，我得去找人聊一聊因为实在不知道我在做什么，今天想起来还是很有趣的事情。在谷歌里我像海绵一样快速的吸收技术和其他的信息。今天我在这里谈论的一些事情其实要早于我在谷歌的时间，大约 2000 年和 2001 年左右。让我们从微服务，即谷歌的微服务版本开始讲起。

当时，谷歌的业务仍然押注在 GSA（谷歌搜索服务器）产品，其实最终 GSA 也并没有像想象中的那么顺利。当然了，其它事情也是这样，毕竟不能将一个虚拟的垄断产品与像广告这样数十亿美元的巨额业务相对比。不过，谷歌最开始是以搜索起家的，并专注在解决这一类的技术问题。

接下来要讨论的很多内容的原始驱动力来自于这张幻灯片。在经济危机之前，很多企业都将他们的基础设施构建在 Sun Microsystems 的硬件之上，并将 Solaris 作为操作系统。如果不考虑成本的话，这一套解决方案比现有的其它东西都要好，很多人买了很多这种 Sun box 也是基于这样的原因。但 Sun box 真的很贵，尤其是一个拥有庞大数据中心的企业，整个数据中心需要填满这种机箱以支撑业务的发展，成本就会影响到其业务渠道和活下去的底线。

(相关资料图)

谷歌当时就处在这样一个状况。当时的人会很自然的说：“Linux 虽然不够完美，不过功能也够用，它的硬件又很便宜，所以平衡下来我们可以选择 Linux 作为替代”。一定程度上，我也认同这些过往的事情是真实的，当时的人们成本意识很强，所以他们会不遗余力的去解决一系列 RAM、芯片等 Linux 出现的一切故障，以降低成本。而这就带来了一个结果 – 即 Linux 真的不可靠，特别是使用垃圾站硬件的时候，且问题很严重。我认为，谷歌从 Compaq DEC 并购中受益匪浅，这也是导致 90 年代一些真正令人难以置信的研究实验室死亡的原因。许多人比如 Jeff Dean 和 Sanjay Kumar 都来自那个世界，他们现在几乎都是质量工程师。当时的他们对如何在那些难以令人置信的不可靠硬件之上构建软件这个问题产生了强大的兴趣，后面发生的事情也是很多接下来要分享的内容。

然而在 2001 年并没有什么可以替代的方案，所以必须自己做。另一个问题是非常古怪的扩展要求。他们试图做一些当时非常大胆的事情，即索引每个网页的每个字。一些人将每个网页的每个单词收录并编入索引，其他人只是给它建立索引，然后丢弃那些限制竞争对手能力的原始数据。这是一项艰巨的任务，需要用到当时根本不存在的计算机软件。

因此，由于不可靠的 Linux 盒子，该软件必须横向扩展，并且必须在堆栈的任何组件中容纳频繁的例行故障。之前有一篇很棒的文章提出了“机器是牛而不是宠物”。我认为在这件事情上谷歌做对了。这些机器没有来自“星际迷航”的酷炫名字，它们只是 AB 1,2,5,7 类似的东西，那也是机器名。系统对它没有太多的依赖，它死了或者继续运行都不会影响其它部分。这个问题让人们开始思考如何建立更具弹性的系统。

以上是我如何描述事物的方式。在谷歌很多人都有博士学位。记得面试时，我还没有博士学位。而且，我只跟一个没有博士学位的人谈过，面试结束时，他说，“别担心，现在开始雇用没有博士学位的人了”，在那里有很多人比我更聪明，并且真的想将他们的知识应用到 CS 系统研究中，将这种类型的经验和知识应用于现实问题是一件很有趣的事情。

我认为构建微服务的唯一充分理由是组织结构，并且这也应该是大多数组织构建微服务的唯一原因。然而，这并不是谷歌构建微服务的原因。谷歌构建微服务是为了计算机科学，在这里，我不会去争辩从这个角度构建微服务其实也没有什么好处，当然肯定是有很多痛点驱动。

开始构建微服务之后，如果简单的认为它一定会很顺利，也没有事先调研所有可能的失败情况，那么一定不会顺利，而且实际上也可能会带来很多令人遗憾的结果。我和很多企业讨论过这个问题，这些企业也因为迁移的过程实在太痛苦了而放弃了向微服务的迁移。所以，一定要事先了解构建微服务的动因。就像谷歌里有很多人效仿大型的基础设施项目一样，有时我认为他们在构建一些并不必须的架构。理智的投资方式应该是遵循以下原则：“如果你不需要就不要去做，否则只会会让事情变得更困难”。

这样做的主要原因是最大限度地减少团队之间的人员沟通成本，一个超过 10 个或 12 个人的团队无法在一个工程项目上成功协作，它与人员沟通结构和工作授权有很大关系。因此，将项目团队映射到微服务可以减少人与人之间的沟通开销，从而提高开发速度。这是一个选择微服务的合理原因，但这也并不是我们在谷歌构建微服务的原因。

我认为可观察性包括两件事，一个是检测关键信号，即 SLI 的部分，它需要非常精确；另一个则是改进搜索空间。每增加一个微服务，可能发生的故障模式的数量随着服务数量的增长而几何式增长。我并不认为机器学习或 AI 可以神奇地解决这个问题。我们需要尽快发现可以帮助减少人脑假设的方法，只有在使用巨型仪表板之外的技术时才能实现引导过程。巨型仪表板在单体环境中运行良好，但我看到人们采用这种理念并围绕它构建微服务的可观察性。我认为有必要使用仪表板，但肯定不够。我采访过的 SRE 小组当时正在构建巨大的仪表板，我们的效率明显低于让它设计上更紧凑的团队，之后再使用其他工具来改进搜索空间。所以，不要混淆搜索空间的可视化和对它的精炼优化。整个搜索空间太大了且无法可视化，而且人类迄今也无法处理那么多信息。

在 LightStep，我们看到很多客户一直在努力解决这类问题。我不知道在座的各位是否经历过同样的情况，但我认为这是一种失败模式，谷歌肯定也明白这一点。曾经有一个大型的 Google 服务，大概名字是家庭类型之类的服务，它不得不使用代码生成器生成告警配置，最终导致了 35,000 行还要长的代码。我不记得其中的所有原因。但随后他们不得不开始手动维护这 35,000 行代码，然而这些配置是在 Google 内部完全模糊的 DSL 中编写的，手动维护所带来的痛苦程度无法比拟，这就是因为他们混淆了对 SLI 的告警信息和可能是根本原因的告警信息。监控不应该对根本原因发出告警，它应该是细化过程的一部分；而应该对 SLI 发出告警，对于任何特定系统，SLI 的信息不会有那么多而导致无法处理。