谷歌失败案例赏析：那些年在微服务上踩的坑.docxVIP

谷歌失败案例赏析：那些年在微服务上踩的坑 2021-06-13 Ben Sigelman 是 LightStep 的首席执行官兼联合创始人，他是 Dapper 的共同创始人（Google 的分布式跟踪工具，挂念开发人员理解他们的大型分布式系统），以及开源 OpenTracing API 标准的共同创建者（ 一个 CNCF 内的项目）。在 2021 年 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 位直接汇报人的这一