为了更好地让千万客户运用到平稳靠谱的服务项目，Google 建立了一支专业性的队伍承担运作这种后面服务项目，这种技术工程师有一个相互的名称：Site Reliability Engineer。掌握 Google SRE 的人常说的一句话是：和你们对比，绝大多数企业还处在刀耕火种时期，何时你们这种最佳实践可以协助协助别的的企业呢？杰出 Google SRE Chris Jones 等协同编写了《Google SRE: How Google runs production systems》（下称《Google SRE》），初次向外部破译了Google的工作环境。前 Google 杰出 SRE ，现 Coding.net CTO 孙宇聪 老先生出任了这书译员。
伴随着这部官方网书本的出版发行，Google 不遗余力的将自身十几年 SRE 的企业生产管理心得分享出去，业内能够 近距多方位地认识到 Google SRE 的主要工作内容及最佳实践，这对所有IT行业的危害将是极大和长远的。
这书內容包含：
怎样均衡易用性和成本费
怎样制订服务项目的 SLO
怎样降低 operational 的工作中
分布式架构的监管
自动化技术服务平台演变
SRE 在发布软件中的人物角色
这书首次系统化公布 Google SRE 之道，集 Google SRE 基础理论和实践活动之大德，可以说运维宝书。从 SRE 的角度看来 Google 工作环境会是如何？晓听文中溶解。1. 硬件
Google 绝大多数云计算服务器都储放在自行制定的数据中心中。这种数据中心有着自身制定的供配电系统、制冷机组、应用系统及其电子计算机硬件。和一般的服务器托管中心对比，每一个数据中心的电子计算机硬件大部分是一致的。
为了更好地更强地域分物理学服务器和手机软件服务器的定义，我们在本书上都运用了下列2种观点。
物理学服务器(Machine)： 代表实际的硬件(有时也代表一个 VM vm虚拟机)。
手机软件服务器(Server)： 代表一个对外开放供应业务的系统软件。
绝大多数状况下 Google 数据中心的硬件配备是统一的，可是还有不可抗力事件，比如有一些数据中心很有可能会 与此同时具有几类不一样迭代更新周期时间造成的硬件商品，大家偶尔也会改动某一目前数据中心的硬件配备。
硬件服务器上能够运作一切种类的手机软件服务器。Google并不会应用专业的硬件服务器运作专业手机软件的服务器。
比如，对 Google 而言，并不会有一个主要的硬件服务器运作大家的电子邮件系统，只是选用一套群集智能管理系统开展资源配置，它的名字为 Borg。
大家意识到 Google将手机软件服务器与硬件服务器区别得这般确立有一些与众不同。一般对一个软件业务流程而言，手机软件服务器和硬件服务器是紧密相连，紧密联系的。
可是对 Google而言，并不是这样。实际区别的缘故和关键点坚信阅读者读过接下来的章节目录以后便会有一定的掌握。
图 2-1 勾勒了一个非常典型的 Google 数据中心的网络拓扑结构 :
约 10 台硬件服务器构成了一个机柜(Rack)
多台机柜构成一个机柜排(Row)。
一排或三排机柜构成了一个群集(Cluster)
一般来说，一个数据中心(Datacenter)包括好几个群集 y 好几个紧邻的数据中心构成了一个产业园区(Campus)
<图2-1>
每一个数据中心内的物理学服务器都必须可以相互之间开展通信网络。为了更好地彻底解决这个问题，大家 用百台 Google自身制作的网络交换机用 Clos 接口方式相互连接建立了一个十分快的虚似交换机，这一网络交换机有上万个虚似端口号。
这一网络交换机的名字叫 Jupiter。在 Google 较大 的一个数据中心中，Jupiter 能够 给予 1.3 Pb/s的服务器交叉式网络带宽。
Google 数据中心是由一套全世界遮盖的主干网B4相互连接的。B4 是根据 SDN 互联网技术(应用 OpenFlow 接口协议)搭建的，能够 在一定范围内给予大量网络带宽，与此同时还可以运用动态性带宽管理提升数据连接，利润最大化均值网络带宽。
2. 管理方法物理学服务器的系统为了更好地管理方法和操纵硬件机器设备，大家研发了一套一样适用大规模的布署的数据管理手机软件。硬件常见故障是大家用系统软件管理方法的一项关键难题。
由于一个群集中包含许多硬件机器设备，每日硬件机器设备的毁坏量很高。均值在一年内，一个独立群集中会产生好几千起硬件服务器毁坏事情，几千元电脑硬盘也会毁坏。
当把那些数据乘于 Google 目前的群集总数时，这种数据就有些让人不敢相信了。因此 ，要想将硬件常见故障难题与具体业务流程客户防护起来。
实际业务流程精英团队运作手机软件服务器的过程中也并不愿每日解决硬件常见故障。每一个数据中心产业园区都配置专业的队伍承担维护保养硬件机器设备和数据中心基础设施建设。
2.1 管理方法物理学服务器Borg，如图所示 2-2 所显示，是一个分布式系统群集电脑操作系统(参照参考文献 [Ver15])。其与 Apache Mesos 相近， Borg 承担在群集方面管理方法目标的编辑工作中。
有一些用户很有可能掌握 Borg 的下一代，Kubernetes，开源系统容器化群集编辑系统软件，Google 开创于 2014 年。 请参考 Kubernetes - Production-Grade Container Orchestration 。
<图2-2>
Borg 承担运作客户上传的“每日任务”(Job)。该每日任务能够 是无尽运作的手机软件服务器，或是是大批量每日任务，比如 MapReduce。每一个每日任务能够 由一个或好几个案例 (Task)构成(有时乃至由好几千个案例构成)。
一般那样机构是因为提升信息冗余，并且大部分状况一个案例并无法达到全部群集的总流量要求。当 Borg 运行一个每日任务的情况下，它会为每一个案例分配一台物理学服务器，而且实行实际的程序流程运行它。
Borg 与此同时会持续监管这种案例，假如发觉某一案例发现异常，其会停止该案例，而且重新启动它，有时会在此外一台物理学服务器上重新启动。
由于案例与设备并沒有一对一的固定不动对应关系，我们不能简易用 IP 详细地址和端口号来代指某一个具体内容案例。为了更好地彻底解决这个问题，大家提高了一个新的抽象性层。
每每 Borg 运行某一个每日任务的情况下，Borg 给每一个主要的每日任务案例分派一个名称和一个序号，这一系统软件称作 Borg 名字分析系统软件(BNS)。当别的每日任务案例联接到某些每日任务案例时，他们应用 BNS 名字联接，BNS 系统软件承担将这一名字转化成实际的 IP 详细地址和端口号开展联接。
Borg 还承担将实际资源配置给每一个每日任务。每一个工作都必须在环境变量中申明它必须的实际資源 (比如: 3CPU 关键 ， 2GB 运行内存等)。 拥有如此的信息内容， Borg 能够 将所 有的每日任务案例有效分派在不一样的物理学服务器上，以提升每一个物理学服务器的使用率。与此同时 Borg 还 关心物理学服务器的常见故障域特性。
比如 :Borg 不容易将某一目标的所有案例都运作在某一个 机柜上，由于这样一来，机柜网络交换机将变成全部工作的服务器宕机源。
假如一个每日任务案例資源应用超过了它的调整范畴，Borg 会杀死这一案例，而且重新启动它。大家看到一个迟缓的持续重新启动的案例好些过一个始终不重新启动一直泄露資源的案例。
2.2 储存每日任务案例能够 运用当地电脑硬盘储存一些临时文件夹，可是大家几个群集等级的分布式存储可选择做为永久储存。乃至人们的临时文件夹储存也在向群集储存实体模型转移。这种储存 系统软件和开源系统的 Lustre，及其 Hadoop 系统文件(HDFS)相近。
这种分布式存储承担向消费者给予一套简易实用，而且靠谱的群集储存服务项目。见图 2-3，分布式存储由几层构造构成。
<图2-3>
底层由称之为 D 的业务给予(D 代表硬盘 Disk，可是 D 能够 一起应用硬盘和 SSD)。D 是一个文档服务器，基本上运作在全部群集的全部物理学服务器上。殊不知，客户实际浏览某一数据信息时并不一定记牢实际到哪一个 D 服务器上来获得，这就是下一层做的事儿。
D 服务项目的上一层称作 Colossus，Colossus 创建了一个遮盖全部群集的系统文件。 Colossus 系统文件给予传统式系统文件的实际操作插口，与此同时还适用拷贝与数据加密作用。 Colossus 是 GFS 的优化版本号。
搭建于 Colossus 以上，几个相近数据库查询的业务可选择 :
Bigtable是一个 NoSQL 数据库查询。它还可以解决达到多个 Petabytes 的数据库查询。Bigtable 是一个疏松储存的、分布式系统的、有先后顺序的、长久 化的多维投射表。应用 Row Key、Column Key，及其 Timestamp 做数据库索引。映 射表中的值是按初始字节数储存的。Bigtable 适用“最后一致”的跨数据中心拷贝实体模型。
Spanner(参照参考文献 [Cor12])是能够 给予一个 SQL 插口及其达到一致性规定的世界数据库查询。
此外几类数据库管理，比如 Blob Store 也可以用。每一种数据库查询都是有自身的优劣势。
2.3 互联网Google 的互联网硬件机器设备是由下列多种方法调节的。至始文上述，大家应用一个根据 OpenFlow 的软件定义互联网(SDN)，大家并没有挑选应用高級智能路由器联接，只是选用 了一般的非智能化互换部件融合集中(有备份数据的)的控制板接口方式。
该控制板承担测算互联网正中间的最好途径。因而我们可以将所有群集的繁杂路由器测算从实际互换硬件上分离出来起来，进而控制成本。
服务器带宽也须要被有效分派。如同 Borg 给每一个每日任务案例分派云计算服务器一样，网络带宽控制板(Bandwidth Enforcer，BwE)负责全部可以用网络带宽。
提升网络带宽的应用不仅是减少 成本费。运用去中心化的路由器测算，我们可以处理之前在分布式路由方式下解决不了的总流量转移难题。
有一些服务项目包含运转在不一样群集上的每日任务，这种群集一般是遍及全世界的。为了更好地减少分布式系统群集的服务项目延迟时间，大家期望可以将客户分派给间距近来的、有空闲容积的数据中心解决。
大家的全世界负载均衡系统软件(GSLB)在三个方面上承担负载均衡工作中 :
运用所在位置信息内容负载均衡 DNS 要求。
在客户服务方面开展繁杂平衡，比如 YouTube 和 Google Maps。
在远程控制启用(RPC)方面开展负载均衡。
每一个服务项目的管理人员在环境变量中给服务项目起一个名字，与此同时特定一系列的 BNS 详细地址，及其 每一个 BNS 详细地址可以用的容积(一般，容积的部门是QPS，每秒钟要求总数)。GSLB 会全自动 将客户总流量导向性到适宜的部位。
3. 别的系统别的运作在数据中心中的好多个部件也很重要。
3.1 锁服务项目Chubby群集锁服务项目给予一个与系统文件相近的 API 用于实际操作锁。 Chubby 能够 解决外地、跨主机房等级的锁要求。Chubby 应用 Paxos 协议书来获得分布式系统一 致性。
Chubby 是完成主案例大选(Master-Election)全过程的核心部件。比如，一个服务项目有 5 个 沉余案例在与此同时运作，可是只有一个案例能够 解决对外开放要求时，一般作法是根据 Chubby 开展全自动大选，挑选在其中一个案例变成 主案例。
Chubby 合适储放那类对一致性规定十分强的数据信息。比如 BNS 服务项目，就应用 Chubby 储放 BNS 途径与 IP:端口号的对应关系。
3.2 监管与报警设备监管与报警设备是安全可靠的运营服务项目中必不可少的一部分。因而，我们在数据中心中运转了好几个 Borgmon 监管程序流程案例。
Borgmon 按时从监管目标爬取监管指标值 (Metrics)。这种监管指标值能够被用于做马上警报，还可以储存起來供之后收看。
大家关键有下列多种方法应用视频监控系统 :
对真正难题开展警报。
比照服务项目升级前后左右情况转变:新的版本号是不是让手机软件服务器运作得更快了?
查验資源需求量随時间的变动状况，这一消息对有效制订資源方案很有效。
4. 手机软件基础设施建设Google 的最底层手机软件基础设施建设的制定目的是最有效地应用 Google 的硬件基础设施建设。大家的代码库很多使用了线程同步设计方案方法，一个每日任务案例能够 一起运用许多个 CPU。每一个手机软件服务器都是有一个自带的 HTTP 服务项目，给予一些调试信息和统计数据，供线上调节、监 控等应用。
全部的 Google 服务项目以前都应用远程控制启用(RPC)通讯，称作 Stubby。大家现在还发布了一个开源系统完成 ，gRPC。有的情况下，一个程序流程的內部调用函数也会用 RPC 完成，因 为将来有须要时，能够非常容易地将其重新构建为好几个部件并行处理的构架。GSLB 对 RPC 的负载均衡有优良的适用。
实际参照 http://gprpc.io。
一般而言，一个软件服务器从该服务器的前端(Frontend)接收 RPC 请求，同时将另外一些 RPC 发往该服务器的后端(Backend)。一般来说，前端被称为客户端(Client)， 后端被称为服务端(Server)。
Protocol Buffer 是 Google RPC 的传输数据格式，通常简写为 Protobuf，与 Apache Thrift 类似。Protobuf 相比 XML 有很多优势，更为简单易用，数据大小比 XML 格式要小 3~10 倍，序列化和反序列化速度快 100 倍，并且协议更加明确。
Protocol Buffer是编程语言中性的、运行平台中性的一种数据序列化机制。
5. 研发环境Google 非常注重研发效率，我们围绕着自己的基础设施创建了一整套研发环境。
除了一些开源项目之外(Android 和 Chrome 等)，其他 Google 软件工程师全部使用同一个共享软件仓库开发。这同时也对我们的日常工作流带来一些挑战:
如果一个工程师遇到了他工作的项目之外的一个基础组件的问题，他们可以直接 修改这个问题，向管理者提交一份改动申请(Change List， CL)，等待代码评审， 最后直接提交。
任何对代码的改动也需要代码评审。
在软件编译过程中，编译软件会向运行在数据中心的编译服务器发送请求。
Google 编译软件可以通过并行化机制，处理超大型的编译请求。这套技术架构体系同时也用来进行持续测试。每当一个 CL 被提交时，所有被这个 CL 直接或间接影响到的测试都会运行一次。
如果测试框架检测到一个 CL破坏了其他某个系统的正常工作，测试框架会向提交者发送通知。甚至有些项目组在实践自动部署机制:提交一个新版本，测试通过后， 将直接部署于生产环境。
6. 莎士比亚搜索 :一个示范服务为了更好地说明一个服务是怎么利用各种基础设施，以及在 Google 生产环境中部署的，我们在这里提供一个假想的莎士比亚搜索服务。假设这个服务的作用是在所有莎士比亚的文献中搜索给定词语。
整个系统可以分为两大部分 :
批处理部分。给全部莎士比亚文献创建索引，同时将索引写入一个 Bigtable 中。这项任务基本只需运行一次。(如果突然发现了新的莎士比亚文献，那就需要再运行一次。)
一个应用程序前端服务器(Frontend)用以接收处理用户请求。该服务器是一直在线的，因为全球范围的用户都需要使用我们的服务。
批处理部分可以用 MapReduce 框架完成，三个阶段的实现分别如下所示。
Mapping 阶段:该程序遍历所有的莎士比亚的文字，将其分成具体的单词。这项 任务可以利用多实例并行加速。
Shuffle 阶段:该程序将上一阶产生的所有单词和位置等进行排序。
Reduce 阶段:将上一阶段产生的单词或位置等按单词合并，产生一个新的单词或位置列表。
最后，程序将每一个的单词或位置列表写入到 Bigtable 中，Row Key 就是这个单词。
6.1 用户请求的处理过程图 2-4 显示了一个用户请求的处理全过程。首先，用户使用浏览器访问https://shakespeare.google.com。为了获得 IP 地址，用户设备需要请求 DNS 服务器 (1)。该 DNS 请求最后会到达 Google 的 DNS 服务器。Google DNS 服务器会请求 GSLB 系统。 GSLB通过全局流量负载信息，决定使用哪个 IP 地址回复用户。
<图2-4>
用户浏览器利用获得的 IP 地址连接到 HTTP 服务器，这个服务器(Google 前端服务器 GFE)负责终结 TCP 连接，并且反向代理请求到真正的服务器上(2)。GFE 从配置文 件中找到该请求对应的后端服务(配置文件中包括所有 Google 服务，例如 web search、 maps 以及本例中的 Shakespeare)。GFE 再次咨询 GSLB 系统，获得一个 GSLB 分配的 目前可用的 Shakespeare 服务器地址，向其发送一个 RPC 请求(3)。
Shakespeare 前端服务器分析接收到的请求，构建出一个具体查询的 Protobuf 请求。这时 Shakespeare 前端服务器需要联系后端服务器(Backend)来做具体查询。前端服务器也需要联系 GSLB 服务，获取目前可用的(同时符合负载均衡条件的)后端服务器的 BNS 地址(4)。Shakespeare 后端服务器随后请求 Bigtable 服务器来获得最终查询结果(5)。
最终结果被写入一个 Protobuf 结构中，返回给 Shakespeare 后端服务器，后端服务器将其回复给 Shakespeare 前端服务器，前端服务器最终根据这个数据结构构建 HTML 回复给最终用户。
上述这些连锁事件其实一共耗时几百毫秒。因为一个请求涉及很多组件，这些组件都必须相当可靠才行。例如，GSLB 服务如果出现问题，将会造成严重故障。但是 Google 依靠严格的测试和灰度发布流程，以及很多主动优雅降级的措施，使得我们可以为用户提供一个非常稳定的服务。
由于 Google 的可靠性举世闻名，人们经常通过访问 http://www.google.com 来验证他们的网络服务是否正常。
6.2 任务和数据的组织假设 :压力测试的结果显示，我们的服务器可以每秒处理大概 100 个请求(100 QPS)。通过对用户进行的调查显示，我们预计峰值流量会达到 3470 QPS，为了处理这些流量，我们至少需要 35 个任务实例。但是，由于以下几个考量，我们最终决定至少采用 37 个实例，也就是 N+2 模式 :
在更新过程中，有一个任务实例将会短暂不可用，只有 36 个实例可提供服务。
如果另外一个物理服务器同时也出现问题，那么另外一个任务实例也受到影响，只剩 35个实例可以对外服务，刚刚可以满足峰值要求。
我们假设同时出现两个任务实例不可用的情况的可能性很低，足以忽略不计。但是单点故障源，例如供电设施问题，或者机柜交换机问题，可能会影响这里的假设。
假设，对用户流量的进一步观察显示，我们的峰值流量其实是来自全球的。北美 1430 QPS，南美洲 290 QPS， 欧洲和非洲 1400 QPS， 亚洲及澳州共 350 QPS。
为了更好地服务用户，我们需要将服务分别部署在美国、南美洲、欧洲和亚洲。在南美洲，我们选择使用只部署 4 个实例(而不是 5 个)，将冗余度降低为 N+1。这样做的原因是我们选择在极端情况下牺牲一些用户体验，以便降低成本。
因为当容量不足时，GSLB 会将南美洲的用户流量导向其他可用的数据中心，可以节省大概 20% 的硬件资源。在有条件的地方，我们还会将任务实例分散在不同的集群中(Cluster)，以便更好地提升可靠度。
因为 Shakespeare 后端服务器需要连接 Bigtable 服务读取数据，我们同时也需要合理地 安排数据存储。亚洲的后端服务器尝试访问部署在美国的Bigtable 会面临延迟问题。所以我们在每个地理区域都存放了 Bigtable 的副本。
利用 Bigtable 的复制功能，我们可以同时达到两个目的 :
当 Bigtable 服务出现问题时，还可以利用副本提供服务。
任务实例可以利用本地 Bigtable 加速数据访问。
虽然 Bigtable 仅仅提供最终一致性保障(Eventual Consistency)，但是由于我们的数据更新并不频繁，所以对我们来说并不是问题。
本书《Google SRE》中文版已在 亚马逊 和 Coding 商城 预售。该节选译文版权归译者所有，商业转载请联系作者获得授权，非商业转载请注明出处。推荐阅读本书译者孙宇聪的其他文章：
- 来自 Google 的高可用架构理念与实践
- Coding 孙宇聪：《人，技术与流程》
- Docker 技术与 Coding.net 技术架构的变迁
来自 CODING 的技术，创业干货分享，更多精彩请关注 CODING - 知乎专栏