声明：本文来自于微信公众号InfoQ（ID：infoqchina），授权站长之家转载发布。
作者 | Ben Sigelman译者 | 禚娴静Ben Sigelman 是 LightStep 的首席执行官兼联合创始人，他是 Dapper 的共同创始人(Google 的分布式跟踪工具，帮助开发人员理解他们的大型分布式系统)，以及开源 OpenTracing API 标准的共同创建者( 一个 CNCF 内的项目)。在 2018 年 12 月 QCon 大会上 Ben 向我们分享了谷歌在微服务构建路上遇到的经验教训，本文是 Ben 的演讲主要内容的译稿。
大家好，今天和在座的各位分享一些失败的经验教训。聊一聊这一类的话题要比那些成功案例更有意思。行业在进步，我们可以从过去的错误中吸取经验，并主动在未来的计划中避免，这一点很令人鼓舞。
背景信息
在开始之前，先介绍一下我在谷歌的经历。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 年是没有人解决过的问题，也是他们当下所处的情况。“让我们写一些很酷的软件，看看 Github 上有什么”。
然而在 2001 年并没有什么可以替代的方案，所以必须自己做。另一个问题是非常古怪的扩展要求。他们试图做一些当时非常大胆的事情，即索引每个网页的每个字。一些人将每个网页的每个单词收录并编入索引，其他人只是给它建立索引，然后丢弃那些限制竞争对手能力的原始数据。这是一项艰巨的任务，需要用到当时根本不存在的计算机软件。
因此，由于不可靠的 Linux 盒子，该软件必须横向扩展，并且必须在堆栈的任何组件中容纳频繁的例行故障。之前有一篇很棒的文章提出了“机器是牛而不是宠物”。我认为在这件事情上谷歌做对了。这些机器没有来自“星际迷航”的酷炫名字，它们只是 AB 1，2，5，7 类似的东西，那也是机器名。系统对它没有太多的依赖，它死了或者继续运行都不会影响其它部分。这个问题让人们开始思考如何建立更具弹性的系统。
以上是我如何描述事物的方式。在谷歌很多人都有博士学位。记得面试时，我还没有博士学位。而且，我只跟一个没有博士学位的人谈过，面试结束时，他说，“别担心，现在开始雇用没有博士学位的人了”，在那里有很多人比我更聪明，并且真的想将他们的知识应用到 CS 系统研究中，将这种类型的经验和知识应用于现实问题是一件很有趣的事情。
在谷歌有很多自下而上的决策，我的第一位经理在我加入时有 120 位直接汇报人的这一事实也说明了这一点，决策的制定是分散且唯一，那里是一个有抱负的文化氛围，也是一个非常以任务为导向的组织，既有基础设施，还有公司层面，特别是在那个时候，它是一个非常纯粹的理想主义组织。具有讽刺意味的是，现在看到新闻时感觉事情发生了很大的变化，至少就公众形象而言，当然重要的是要记住时间，而且我承认也许有点过分自信。人们可能觉得他们有能力做任何事情，愿意尝试新的大的挑战，并假设确实可以实现，这很酷有很高的风险，但也很有趣。
那些发生的事情
那么，这样的工程要求和文化氛围实际导致的结果是什么呢?
这是一张寒武纪大爆发的图，寒武纪大爆发是进化史上的一个时期，生物多样性迅速，是多种因素共同作用的结果。我今天早上读了维基百科，以确保我引用的事实是正确的。它与氧气的增加有关，钙的增加使得这些生物能够制造它们的壳。那时的许多事情都发生在大致相同的时间，在 2000 万年间，生物多样性的增长非常迅速。
在谷歌也有类似的东西，业务需要构建一个非常大的架构，这个架构需要围绕软件和认为他们可以尝试一些新事物的文化背景而构造。这就导致了在谷歌类似寒武纪大爆发一样的很多基础设施项目的爆发，许多项目现在已经众所周知，如 GFS-Google 被广泛使用的文件系统， BigTable 是 Cassandra 之前的产品，著名的 MapReduce、Borg 是类似于 Kubernetes-ish 的项目。有人可能会因为我这样的观点生气，但它应该很接近真实的情况，也还有一些没有公开但令我印象深刻的项目。
其实不仅这些重要的项目众所周知，他们撰写的论文也使得这些案例在 Google 之外传播开来。这些项目与 Hadoop 项目之间存在一对一的对应关系，并从开源社区推广。但这带来了一个问题，他们引领谷歌的文化走向崇拜这些项目，人们会认为在一些与大型基础设施结构相似的项目上工作真的很酷。这份清单上的所有内容当然都是必要的，Google 也从中受益匪浅。然而谷歌内部的这些货物崇拜导致人们试图模仿这些系统的设计而不去理解为什么选择这些设计。
这些设计在很多方面看起来很像今天的微服务。这就是为什么我们不把它称为微服务，在结构上它们看起来很像微服务。起初想要创造一种可以水平扩展的东西，想要分解像 RPC 服务发现这样的用户级基础设施，但现在“服务网格”中的内容已被考虑到这些巨大的客户端库中，这些库在今天的谷歌被广泛使用，被称为谷歌 3。在谷歌 3 构建一个 Hello World 的二进制文件，它需要消耗 140 兆字节的二进制文件，且只是为了链接这个用户级别的内核。谷歌 3 为了完成所有这些工作而将其考虑在内，后来也转向了一些看起来有点像 CI、CD 的东西。它开始感觉很像微服务了，但是这样做的决定是出于计算机科学的需求，我认为这是今天大多数组织构建微服务的一个有趣的理由。
