Google SRE主管：使用开源软件打造类似Google的开发和生产环境

《Google SRE主管：使用开源软件打造类似Google的开发和生产环境》要点：
本文介绍了Google SRE主管：使用开源软件打造类似Google的开发和生产环境，希望对您有用。如果有疑问，可以联系我们。

作者简介：

Minghua Ye(Google ?SRE 主管)

2007加入 Google 公司,2009年开始,主要负责 Google 的云计算平台,特别是 Google App Engine.

前言

如果大家对 App Engine 还不熟悉的话,简单来说 App Engine 就是 Google 提供的 paas,一个开发、托管网络应用程序的平台,使用户的程序能在 Google 的数据中心运行.

作者在本文中分析他在 Google 的一些经验,鉴于作者的 App Engine 背景.本文很多话题里都涉及跟 App Engine 相关的应用.

1、云平台至关重要的可扩展性

当7年前,我刚刚开始在 App Engine 的 SRE 生涯的时候,App Engine 还是在 Google 内部一个很渺小的服务,活跃用户,流量都远远不能和 Google Search 这样的巨无霸相提并论.

而在短短的7年时间 App Engine 实现的指数型的增长,现如今已经成为了 Google 云平台的重要组成部分.

应用程序开发者在 App Engine 上部署了上千万的应用.在其中不乏一些很重要的客户和很有趣的用例.

上图里我提及到的这些应用开发者们都在它们的网站公开描述了它们在 AE 上的实现.大家如果有兴趣做深入的案例研究可以直接搜索相关的关键字.

值得一提的是威廉王子和凯瑟琳王妃在2011的大婚,皇室选择了 Google 的云计算平台作为婚礼网站和婚礼实时直播平台的提供者.而作为运维小组的 SRE 也得到了皇室的感谢.

在短短的几天之内,网站接受了 15m 的访问和超过 42000QPS 的峰值流量.他们之所以选择 AE,最重要的原因是看中了 AE 系统的自动可扩展性.

网站开发者仅仅部署了网站的源代码,而后台容量的自动扩展和流量的自动均衡都由 AE 系统自动完成,而不需要开发者或者 SRE 的任何干预.

另外一个很重要的客户是 Workivia,Workivia 向全球500强公司提供财务报表的提交服务.众所周知,财务报表的提交时限性很强,而且不容许有失败和错误出现.

这对云平台的稳定性和容错性就有更高的要求,它们选择AE原因也恰恰在于由 Google 提供的高可靠 SLA.

同时 AE 的自动扩展功能使他们能够在繁忙的税季有足够的后端冗余去处理用户请求,而在淡季又能够通过自动减少后端容量已到达节约开支的目的.

最后要提到的是 Spotiy,作为互联网音乐流媒体的主要提供者,它们主要看中的是 Google 云平台的一致性和宽容度,不论你是处理每秒7个事件还是70万个,服务都能保证一至的用户体验.

所以说可扩展性对于一个云平台来说是至关重要的.

2、可扩展系统的基石

Google App Engine 采用了和大多数其他 Google 内部服务一样的微服务架构.而不得不提到的是这些微服务的共同点和它们所依赖的通用内部平台.

• 分布式锁和存储服务

首先不得提到的则是 Google 内部自己实现的分布式锁和存储服务 chubby.

在 Google 内部基本上所有的服务都依赖于 chubby 所提供的一系列功能.chubby 本身并没有开源,但是 Google 将 chubby 的实现细节和 API 通过一篇研究论文发表了.

这篇研究论文也恰恰催生了一批开源的实现,而其中最有名的就是大家都知道的 Apache zookeeper.

而大家也能看到 chubby 所提供的功能在单机环境就类似于大家熟知的锁和寄存器,而 chubby 或者 zookeeper 恰恰是把这种基础的服务拓展到了分布式的环境,是的软件开发者能在分布式的环境中轻松的应用单机开发中常用的方法和理论.

• 服务的自动发现

当你有很多松耦合的微服务组建在运行的时候,如何能够自动发现并寻址到这些服务,就变的非常重要.服务的自动发现在 Google 也是通过 chubby 来实现的.

BNS 是在chubby上实现的地址协议,chubby 提供小文件读写的一致性,这样就能通过写入 BNS 地址和真实 IP：port 绑定,来实现服务发现.

当服务需要解析一个 BNS 地址的时候,他只要通过一致性的读取相应文件即可.etcd 和基于 etcd 的 skydns 则是服务发现在开源环境中的实现.

• 流量负载均衡

当你有很多松耦合的微服务组建在运行的时候,你同样面临的问题是如何能够实现流量负载均衡.

在 Google 内部负载均衡是通过 Google generic service loadbalancer 服务来实现的.你如果使用 Google 的云平台的话,Google 可以提供给你网络即3层,或者 HTTPS 即七层的自动负载均衡.

在 AWS 也有类似的 Elastic loadbalancer 实现.在很多情况下,用户还可以通过 HApxoy 或者 engineX 来实现一些简单的负载均衡.

• Protobuf

最后值得一提的是 Google 的 RPC 子系统和 Protobuf.Google 在近期开源了 gRPC 也就是 Google 内部使用的 RPC 子系统的开源实现.

gRPC 使用 http2 作为传输层,同时使用 Protobuf 作为接口描述语言和消息格式.

2.1 分布式锁和存储

（编辑：ASP站长网）