# Google+是使用您也可以使用的工具构建的：闭包，Java Servlet，JavaScript，BigTable，Colossus，快速周转 > 原文： [http://highscalability.com/blog/2011/7/12/google-is-built-using-tools-you-can-use-too-closure-java-ser.html](http://highscalability.com/blog/2011/7/12/google-is-built-using-tools-you-can-use-too-closure-java-ser.html)  Plaxo 的前首席技术官 Joseph Smarr（解释了我认出他的照片的原因）在[中，我是 Google+团队的技术负责人。 问我什么](http://anyasq.com/79-im-a-technical-lead-on-the-google+-team)，揭示用于构建 Google+的堆栈： > 如今，我们的协议栈是 Google 应用程序的标准价格：我们将 Java servlet 用于服务器代码，将 JavaScript 用于 UI 的浏览器端，很大程度上是由（开源）Closure 框架构建的，其中包括 Closure 的 JavaScript 编译器和模板系统 。 我们采取了一些巧妙的技巧：即使使用的是 AJAX 应用程序，我们也使用 HTML5 历史记录 API 来维护漂亮的 URL（对于较旧的浏览器，它采用哈希碎片）； 并且我们经常在服务器端渲染 Closure 模板，以便在加载任何 JavaScript 之前先渲染页面，然后 JavaScript 找到正确的 DOM 节点并挂接事件处理程序等，以使其具有响应能力（因此，如果您在 缓慢的连接，您很快就会点击内容，您可能会注意到它在执行任何操作之前都存在滞后，但幸运的是，大多数人实际上并没有遇到这种情况）。 我们的后端主要建立在 BigTable 和 Colossus / GFS 之上，并且我们使用了许多其他常见的 Google 技术，例如 MapReduce（同样，与许多其他 Google 应用程序一样）。 起初，我读了 Clojure，这真是一个真正的惊喜，但是它是 Closure，这是一套 JavaScript 工具，由[库](http://code.google.com/closure/library/)，[编译器](http://code.google.com/closure/compiler/)和[模板](http://code.google.com/closure/templates/)组成 。 该编译器是用于 JavaScript 的真正编译器，可加快 JavaScript 下载和运行速度。 该库是模块化和跨浏览器的 JavaScript 库。 模板是服务器端模板系统，可帮助您动态构建可重用的 HTML 和 UI 元素。 它都是开源的，因此您也可以使用它。 虽然您没有可用的 Google 堆栈，但确实有一些开源选项。 [HBase](http://wiki.apache.org/hadoop/Hbase) 替代了 BigTable。 然后是 [Hadoop MapReduce](http://hadoop.apache.org/mapreduce/) 。 [Colossus](http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf) 是 Google 的[下一代文件系统](http://highscalability.com/blog/2010/9/11/googles-colossus-makes-search-real-time-by-dumping-mapreduce.html)，是 GFS 的替代品。 由于我们对 Colossus 知之甚少，因此很难说出合适的替代品。 有 Hadoop 分布式文件系统 [HDFS](http://hadoop.apache.org/hdfs/) 。 如果您正在寻找一些像基础架构胶之类的云，则可以使用 [OpenStack](http://www.openstack.org/) （它也具有存储系统）。 Google 可能使用了自定义的 [Java servlet](http://en.wikipedia.org/wiki/Java_Servlet) 容器，但是此处的选择并不重要。 大部分工作将以并行方式产生，并在以 [C ++，Java 或 Python](http://www.quora.com/Which-programming-languages-does-Google-use-internally) 实现的其他服务器上执行。 尽管几乎没有与 Google 的交流，但 Google+开发团队的响应速度明显加快，可以快速，一致地实现明显的改进。 约瑟夫告诉我们原因：*我们特别强调工程速度/敏捷性-我们尝试每天发布代码更新，同时仍保持质量/稳定性/延迟与您对 google 的期望一样高。 这有助于我们快速行动并快速响应用户反馈。 我们尝试（几乎）每天都进行一次完全推送，有时，如果需要，有时我们也会潜入补丁程序发行版中。 但是有很多人参与其中，这不是“如果所有测试都通过都会自动推动”的情况或类似的情况。* 对于 Google+最具创新性的功能，即环聊视频会议，GigaOM 在该堆栈上有一篇[不错的文章，该文章基于由技术负责人 Justin Uberti 撰写的](http://gigaom.com/video/google-hangouts-technology/)[宣布 Google+ Hangouts](http://juberti.blogspot.com/2011/06/announcing-google-hangouts.html) 。 与以经济高效的 P2P 模式运行的 Skype 不同，环聊完全由 Google 托管。 这必须花费惊人的金钱。 你自己一个人在这里。 没有人可以取代 Google 童话捐赠的带宽。 那就是 Google。 再一次，一位前 Google 员工认为[您可以使用 MessagePack，JSON，Hadoop，jQuery 和 MongoDB 更好地完成](http://rethrick.com/#waving-goodbye)。 如果您可以为全球十亿用户群做得更好，那将是另一个完全不同的问题。 ## 相关文章 * [封闭库](http://code.google.com/closure/library/) / [封闭模板](http://code.google.com/closure/templates/) / [封闭编译器](http://code.google.com/closure/compiler/) * [VMware 公开了计划成为云操作系统](http://gigaom.com/cloud/vmware-exposes-its-plans-to-be-the-os-for-the-cloud)-另一种基础架构选项。 * [罗得岛巨像](http://en.wikipedia.org/wiki/Colossus_of_Rhodes)-世界奇观。 * [Colossus Computer](http://en.wikipedia.org/wiki/Colossus_computer) -英国密码破解者使用的电子计算设备，用于在第二次世界大战期间帮助读取加密的德语消息。 他们使用真空管（热电子阀）进行计算。 * [巨像：Forbin 项目](http://en.wikipedia.org/wiki/Colossus:_The_Forbin_Project)-一部名为 Colossus 的大型美国防御计算机的科幻电影，引起了人们的注意并决定接管世界。 * 这篇文章[关于黑客新闻](http://news.ycombinator.com/item?id=2758177) * 这篇文章[在 Reddit 上](http://www.reddit.com/r/programming/comments/iod09/google_is_built_using_tools_you_can_use_too/) * [OpenGSE 发布](http://google-opensource.blogspot.com/2009/01/opengse-released.html)-*开放源代码爱好者可能感兴趣的是最近发布的 Open Google Servlet Engine（OpenGSE）。 以前，Google 内的工程师开发了自己的快速，轻量级的 servlet 引擎，我们在 Google 内部将其简称为“ Google Servlet 引擎”或 GSE。* * 在 Quora 上： *[谷歌的软件基础设施是否已过时？](http://www.quora.com/Google/Is-Googles-software-infrastructure-obsolete)* TLDR：不。 Hector Yee 有一个很好的总结：*与开放源代码变体相比，Google 基础结构要稳定得多，而且文档也要好得多。 他们作为一个整体工作在一起。 在 Google 框架中构建稳定，可大规模扩展的系统要比使用等效的开源工具容易得多。* 另一方面，采用定义的做事方式很容易对大公司施加的限制感到不满。 这两个观点都是正确的。 * [jQuery vs 闭包](http://news.ycombinator.com/item?id=2758317)上的 nostrademons：基本上每个 Google 产品都使用闭包。 *没有可比性-就网页浏览量，边缘情况和一般现实情况而言，Closure 比其他所有 JS 库都得到更广泛的使用。 我实际上认为他们填补了非常不同的领域。 JQuery 适用于主要是 HTML 但需要通过渐进增强而分层的其他交互功能的网站。 闭包适用于 JavaScript 应用，其中整个客户端基本上都是用 JavaScript 编写的。* * RyanDScott 在[上解释了为什么 Google 内部没有使用 GWT](http://news.ycombinator.com/item?id=2760822) ：*闭包只是 JavaScript。 无需等待 GWT 团队构建所需的功能，也无需自己构建这些功能。 以我的经验，当我需要使用 GWT 进行最前沿的开发时，我最终为 JavaScript 函数编写了一堆包装程序，这使我想知道为什么我不使用 JavaScript 编写所有内容。 （就像我说的那样，GWT 库非常引人注目，并且在计划大型项目时，Java 对于某些人通常感觉更舒服。）* ## Related Articles * [从 Google+实验中学习：Stowe Boyd 的操作系统，平台，应用](http://www.stoweboyd.com/post/8129714757/learning-from-the-google-experiment-operating-system)。 *但是，我们正在迈向一个世界，在这个世界上，Google +的大多数基本元素将成为下一代 Android 版本的一部分，并且感觉像 Google+上的应用的东西实际上将是在未来的社交网站上运行的应用 操作系统。* 整个“前 Googler 认为您可以做得更好”的事情是如此虚假。 我在其他地方对此进行了评论，但是粗略地浏览一下他的主要批评就可以清楚地看出他对这些技术只有肤浅的知识： “与 MessagePack，JSON 和 Hadoop 相比，协议缓冲区，BigTable 和 MapReduce 都是古老的，吱吱作响的恐龙。与快速而优雅的工具（如 jQuery 和 mongoDB）相比，GWT，Closure 和 MegaStore 之类的新项目速度慢，设计过度，Leviathans” 真？ 实际上，这几乎都不是真的。 协议缓冲区和消息包在大小和效率方面几乎相同，协议缓冲区的文档更好，周围有更强大的社区。 您不一定会知道，如果只是在 MessagePack 网站上做一个表象（无疑是作者所做的），但是如果您实际更深入地使用这些技术，他们的主张是完全虚假的。 JSON 与协议缓冲区？ 好的，比较奇怪，但是首先 Google 到处都使用 J​​SON-他们可能是世界上最大的 JSON 用户。 协议缓冲区也比 JSON 小得多并且快得多。 Hadoop 与 BigTable？ 真的，你要去那里吗？ Hadoop 的整个历史是试图在性能方面赶上 BigTable 并尽可能地复制 BigTable 功能以获得功能之一。 Hadoop 的发展速度很快，但是我所看到的一切都表明 BigTable 的发展速度仍然更快。 它会一直持续下去。 闭包的压缩比 JQuery 好得多。 最新版本的 JQuery 是否更快？ 可能，但这与新的快速，优雅的工具相比，这简直不是“ Leviathan”。 GWT 还执行*浏览器特定的构建*，这是 JQuery 无法触及的，并使它的 JavaScript 变得更小，更快。 MongoDB 当然很酷，但是您真的要把它与 BigTable 相提并论，这是唯一有意义的比较？ 真？ 这甚至不是一条值得走的路。 无论如何，仅仅因为有人在 Google 工作过并不意味着您应该坚持自己的每一个字。 这也不意味着他们对 Google 的每个项目都有深入的了解。 在那儿找到工作要容易得多。 还存在编写热门文章的问题。 这家伙的文章提出了一些疯狂的主张，旨在做到他们所做的一切：获取链接。 这是总的 BS，你们应该对 High Scalability 有更好的了解。 认真地说，你们这里有一些杀手 articles，但您不应该链接到这样的虚假信息。 请注意，我在这场战斗中没有狗。 我不在 Google 工作，但我直接使用了其中大多数技术，包括通过大量使用 App Engine 间接地使用了 BigTable。 亚当（Adam），很难想象有人在 Google 交付了一个重要的项目，但不值得他们对自己的经验发表意见。 我们必须对此表示不同意见，但是我非常感谢您和您对这两个堆栈的比较，非常有见地，谢谢。 真的很不错，感谢您发布！ 前端没有 GWT 吗？ 是的，我已经在自己的 Google+上工作了。 我不会邀请任何人！ 穆哈哈哈... 托德（Todd）：作为“最早”出现在前五名站点中的人和作为仍在其市场中处于领先地位的类别站点的唯一启动者，我建议您不要在您从中看到的“前-”观点中投入过多的股票 我认为这些“观点”没有任何值得注意的见解。 *创造*改变游戏规则的技术和从稀薄空气中获得的技术之间的区别很大，而仅仅是在非常引人注目的平台上展示和发布某些东西。 上面对“前 Google 员工”的反驳表明，事实胜过权威，而您现在可能已经发现，并不是每个“老朋友”都是天才 基于权威的论点，提议不听某人大规模交付了复杂且极富创新性的产品，因为它与公认的权威冲突，这是一种令人愉快的策略。 做得好。 对不起，托德，但由于您已经形成了意见而拒绝接受这样精心撰写的批评/评论，同样令人愉快（使用您的术语）。 从您对亚当评论的回应中，我认为您甚至都没有读过它。 我每天都使用 GWT，将 jQuery 与之比较是可笑的……只是举一个例子。 我了解猛烈抨击 Google 会产生网页点击量（IMO，这就是为什么这位前 Googler 的帖子得到博客作者如此广泛的报道），并且批判性地分析优势/劣势始终是一件好事，但请保持客观。 Sekhar，所以您认为我什至不应该链接到它？ 如果您注意到我在帖子的内容上什么也没说，只是质疑那些技术是否可以扩展。 批评甚至涉及到该职位。 那是你的错吗？