转载

谷歌GAE运维揭秘：如何做到每天处理超过1000亿个请求

在这篇博客帖中，我们请到了Chris Jones（他做了三年半Google App Engine运维工程师，到目前为止已经当了9年的谷歌运维工程师），来探索更多关于在Google上运行产品系统的细节。Chris也是《Site Reliability Engineering: How Google Runs Production Systems》这本书的编辑之一，该书由一直处于互联网发展前沿的O’Reilly Media出版，现在已经可以买到。

Google App Engine每天都服务超过1000亿个请求。就像你听说的那样，是我们的运维工程师让这成为可能。这的确有点像是魔术，将计算机科学和工程原则运用到编程系统的设计和开发中——这个总体来说是十分庞大。

谷歌运维是一套工程方法，让我们或者任何人更好的运行产品系统。它将运维的推广到更大的IT社区。它用有趣的方式来大规模提高性能和可靠性，这对于任何公司来说都是有用的。做得好的话，SRE技术可以提高操作编程服务的效率。

Q：Chris，能告诉我们有多少SRE在操作App Engine吗，现在有多大规模呢？

Chris：我们每天有百万级以上的应用程序在处理1000亿以上的请求，支持的SRE大概几十个的样子。

Q：只有那么少的人，是如何做到这样的规模的呢？

Chris：SRE也是一个工程方法，它可以操作大规模分布式编程服务。但是让系统高度标准化也是有争议的。高度标准化意味着所有的系统工作都是相似的，这也就意味着对操作人员的需求越来越小了，因为操作的复杂性大大降低了。

自动化也十分重要：我们的启动进程是全自动的，所以我们可以很好地用计算机来对这些进程进行扩容，而不是雇更多的人。如果想要将人放到进程上，那会显得很无趣，很多余。你会发现错误飙升。计算机的对错误的反应次数远远比我们人要来得多，而且快。在我们还没有注意到错误的时候，计算机就已经在将流量引到另一个数据中心了，同时保证服务继续运行。让人做人擅长的事情，让计算机做计算机擅长的事情。

Q：在SRE模式后，还有什么其他的方法吗？

Chris：因为有很多SRE团队在处理Google的服务，所以我们可以在产品上扩展标准化原则：SRE－创建工具原本是用于部署新版本的Gmail 的，例如，可以被整理来覆盖更多的场景。这也就意味着每个团队都不需要再自己创建方法来部署更新。这就确保每个产品在工具提升之后，都会得到改进，这就使得整个系统更好的使用工具。

另外，软件工程和系统工程知识的结合，令解决方案囊括两者优点。谷歌的软件网络负载均衡器，Maglev，就是一个例子———而且它是Google云平台负载均衡器的底层技术。

Q：那么这些方法是如何影响App Engine和我们运行在AppEngine上的用户的呢？

Chris：我说个故事来阐述这个。在2013年的夏天，我们将所有App Engine的美国区域从国家的一边转移到另一边。这个举动招致没有停工期给我们的用户。

Q：怎么做到的呢？

Chris：我们先关闭一个App Engine集群，然后就如设计的那样，在上面运行的apps自动移动到了剩下的集群。我们早就事先在目标数据中心创建了美国区域的High Replication Database（ https://www.youtube.com/watch?v=xO015C3R6dw ）的复本，这样那些应用程序的数据（PB级别的数据!）就在该在的地方；对数据存储的修改是自动复制的，这样就可以实时更新。当在新的本地打开App Engine的时候，apps自动被分配到那个从他们备份集群中转移的集群，而且他们所有的数据是已经在适当的地方了。然后我们用剩下的集群来重复进程，直到我们完成之后。

事先准备，将大量的测试和应变计划结合，这就意味着当事情出错时候可以将冲击减少到最小。当然，我们将内部事后析误——SRE如何工作的另一个重要部分——放在一起来理解到底什么出错了，以及如何修复对长远比较好，没有指责。

Q：So cool！那么我们如何找关于SRE更多的消息？

Chris：如果你对SRE是如何在Google运行很感兴趣的话，那么就点击这个网站： https://landing.google.com/sre/ ，我们这周（四月7-8）也会在SREcon： https://landing.google.com/sre/ 就这个话题给出不同的演讲。

原文 http://dockone.io/article/1217

正文到此结束