数据中心即计算机（一、二章节）

介绍

本文是The Datacenter as a Computer第一、二章节译文。

第 1 章 引言

ARPANET 诞生至今已接近 50 年，而 万维网（World Wide Web） 也已有将近 30 年 的历史。然而，源自这两个重要里程碑的互联网技术，至今仍在持续改变着各行各业和文化形态，并且丝毫没有放缓的迹象。诸如 基于 Web 的电子邮件、搜索、社交网络、在线地图 以及 视频流媒体 等流行互联网服务的广泛使用，再加上全球范围内 高速网络连接 的不断普及，加速了向 服务器端 或 “云”计算 转变的趋势。随着这些趋势被主流企业级工作负载所接纳，云计算市场预计在未来几年内将接近 五千亿美元 的规模。

在过去几十年中，计算与存储逐渐从类似 PC 的客户端转移到更小、通常是 移动 的设备，并与大型互联网服务相结合。早期的互联网服务主要以信息展示为主，而如今，许多 Web 应用已经开始提供原本驻留在客户端的服务，包括 电子邮件、照片与视频存储 以及 办公应用。同时，传统的企业级工作负载也在不断向云计算迁移。这种转变不仅源于对用户体验提升的需求，例如 易于管理（无需配置或备份）和 随时随地访问，也来自于其为供应商带来的诸多优势。具体而言，软件即服务（SaaS） 使得应用开发更加迅速，因为软件厂商可以更轻松地进行修改和改进。相比为数以百万计、具有各种不同硬件和软件配置的客户端发布更新，厂商只需在其数据中心内部协调改进和修复，并且可以将硬件部署限制在少量经过充分测试的配置上。

类似地，服务器端计算 还允许更快地引入新的硬件创新，例如可以通过定义良好的接口和 API 进行封装的 加速器。此外，数据中心的经济性使得许多应用服务能够以较低的 单用户成本 运行。例如，服务器可以在数千名活跃用户（以及更多不活跃用户）之间共享，从而实现更高的资源利用率。同样地，在共享服务中，计算和存储本身也可能更加廉价（例如，一封被多名用户接收的电子邮件附件只需存储一次，或者一段视频只需转换一次客户端格式即可向多个设备进行流式传输）。最后，与桌面或笔记本计算环境相比，数据中心中的服务器和存储系统更易于管理，因为它们由一个 集中且专业的实体 统一控制。尤其是在 安全性 方面，云计算具有显著优势。

某些工作负载对计算能力的需求极高，与客户端计算相比，它们更适合运行在 大规模计算基础设施 上。搜索服务（包括 Web 搜索、图像搜索等）是这一类工作负载的典型代表，而诸如 语言翻译（更广泛地说，机器学习）等应用，也由于依赖 超大规模模型，在大型共享计算平台上能够更加高效地运行。

这些向服务器端计算和广泛互联网服务发展的趋势，催生了一类全新的计算系统。在本书第一版中，我们将其命名为 仓库级计算机（warehouse-scale computers，WSCs）。这一名称旨在强调此类系统最显著的特征：其 软件基础设施、数据存储库 以及 硬件平台 的 巨大规模。

这种视角不同于传统计算问题的看法，后者通常隐含地假设 一个程序运行在一台单独的机器上。在仓库级计算中，程序本身就是一种 互联网服务，它可能由数十个甚至更多相互协作的独立程序组成，以实现诸如 电子邮件、搜索 或 地图 等复杂的终端用户服务。这些程序可能由不同的工程团队实现和维护，甚至跨越组织、地理位置以及公司边界（例如 Mashup 应用的情况）。

支撑如此大规模服务所需的计算平台，与 披萨盒式服务器，甚至是以往几十年中占据主导地位的 冰箱大小的高端多处理器系统，都几乎没有相似之处。这类平台的硬件由成千上万个独立的计算节点组成，并配备相应的 网络与存储子系统、电力分配与调节设备 以及 复杂的冷却系统。实际上，这些系统的外壳就是一座建筑物，而且通常与一座大型仓库并无二致。

仓库级计算机

如果规模是这些系统唯一的区分特征，我们或许可以简单地将它们称为数据中心。数据中心是将多台服务器和通信设备集中放置在同一建筑中的设施，其原因在于它们具有共同的环境需求和物理安全需求，并且便于维护。从这个意义上讲，WSC 是一种数据中心。然而，传统数据中心通常承载大量相对较小或中等规模的应用，每个应用运行在专用的硬件基础设施之上，并且与同一设施中的其他系统解耦并相互隔离。这类数据中心往往为多个组织单元，甚至不同公司托管硬件和软件。同一数据中心内的不同计算系统在硬件、软件或维护基础设施方面通常几乎没有共同点，并且彼此之间往往完全不进行通信。

目前，WSC 为 Google、Amazon、Facebook、Microsoft、Alibaba、Tencent、Baidu 等公司所提供的服务提供支撑。它们与传统数据中心有显著差异：归属于单一组织，使用相对同质化的硬件和系统软件平台，并共享统一的系统管理层。与传统数据中心中大量使用第三方软件不同，WSC 中的应用、中间件以及系统软件往往由内部自行开发。更为重要的是，WSC 运行的是数量较少但规模极其庞大的应用（或互联网服务），而统一的资源管理基础设施使得部署具有高度的灵活性。对同质性、单一组织控制以及对成本效率的高度关注，促使系统设计者在构建和运行这些系统时采取全新的方法。

尽管最初是为在线、数据密集型的 Web 工作负载而设计的，WSC 现如今也为诸如 Amazon、Google 和 Microsoft 提供的公有云提供支撑。这类公有云确实运行着大量小型应用，类似于常规数据中心。然而，从服务提供者的角度来看，这些应用本质上都是相同的虚拟机（VMs），并且它们会访问用于块存储、数据库存储、负载均衡等的大型公共服务，这与 WSC 模型非常契合。随着时间的推移，WSC 也逐渐适配并吸收了行业标准以及更加通用的设计理念，使得同一套基础设施几乎无需偏离，就可以同时支持大型的内部在线服务和大规模的公有云产品，在许多情况下甚至提供相同的开发者体验。

互联网服务必须实现高可用性，通常目标是至少达到 99.99% 的运行时间（即“四个九”，约等于每年停机一小时）。在庞大的硬件和系统软件集合上实现无故障运行是极其困难的，而服务器数量的巨大规模又进一步加剧了这一挑战。尽管理论上有可能防止由 10,000 台服务器 组成的系统中发生硬件故障，但其成本必然高得惊人。因此，WSC 的工作负载必须在设计之初就能够优雅地容忍大量组件故障，并且对服务级别性能和可用性几乎不产生影响。

规模化下的成本效率

构建并运营一个大型计算平台成本高昂，而其所提供服务的质量往往依赖于 总体计算与存储能力，这进一步推高了成本，并迫使设计者将注意力集中在 成本效率 上。例如，在 信息检索系统（如 Web 搜索）中，计算需求的增长主要由以下三个因素驱动：

• 服务受欢迎程度的提升 会直接转化为更高的请求负载。
• 问题规模持续扩大 —— Web 每天以数百万页面的速度增长，这增加了构建和提供 Web 索引的成本。
• 即使吞吐量和数据存储规模能够保持不变，市场竞争的本质 仍会不断推动创新，以提升检索结果的质量以及索引更新的频率。尽管某些质量提升可以仅通过更智能的算法实现，但最显著的改进通常需要为 每一次请求 投入额外的计算资源。例如，在一个同时考虑查询词 同义词 或 语义关系 的搜索系统中，结果检索的成本会显著增加：要么搜索需要检索匹配更复杂查询（包含同义词）的文档，要么必须在索引数据结构中为每个词复制其同义词。

这种对计算能力 永无止境 的需求，使得 成本效率 成为 仓库级计算机（WSCs） 设计中的首要衡量指标。成本效率必须被 广义地定义，以涵盖所有重要的成本组成部分，包括 托管设施 的资本与运营开支（其中包括 电力供应 和 能源成本）、硬件、软件、管理人员 以及 维护与修理。第 6 章将对这些问题进行更为深入的讨论。

不只是服务器的集合

我们的核心观点是：为当今许多成功的互联网服务提供动力的数据中心，已经不再只是一些 杂乱无章地共址 并通过网络连接在一起的机器集合。这些系统上运行的软件（如 Gmail 或 Web 搜索服务）的执行规模远远超出单台机器或单个机架：它们至少运行在 由数百到数千台独立服务器组成的集群 之上。因此，机器本身——即 计算机——实际上就是这样一个大型集群或服务器聚合体，必须被视为一个 单一的计算单元。

设计 WSCs 所面临的技术挑战，其重要性丝毫不亚于任何其他类型机器所需的 计算机体系结构 专业知识。首先，它们是一类 全新的大规模机器，由一组 快速演进的新型工作负载 所驱动。仅其规模之大，就使得高效实验或仿真变得极为困难；因此，系统设计者必须开发 新的技术 来指导设计决策。此外，在 WSCs 的设计中，故障行为、安全性 以及 功率与能耗 的影响更为显著，甚至可能超过其他较小规模计算平台。最后，WSCs 相较于由单台服务器或小规模服务器组构成的系统，还引入了一层 额外的复杂性；这种复杂性对 程序员生产力 提出了更高的挑战，其难度甚至超过了对组成 WSC 的 单个多核系统 进行编程。

这种额外复杂性间接源于 虚拟化 以及 应用领域规模的扩大，并体现为：更加 深层且不均匀的存储层次结构（第 4 章）、更高的 故障率（第 7 章）、更大的 性能波动性（第 2 章），以及对 微秒级延迟容忍度 的更高要求（第 8 章）。

本书的目标在于：介绍这一 全新的设计空间，描述 WSCs 的部分需求与特性，强调该领域所特有的一些重要挑战，并分享我们在 Google 内部 设计、编程与运营 这些系统的实践经验。我们不仅是 WSCs 的设计者，同时也是该平台的 用户与程序员，这使我们获得了一个难得的机会，能够在产品生命周期的各个阶段评估设计决策。我们希望，能够成功地传达我们对这一领域的热情，并使其成为一个 值得通用研究与技术社区关注的、令人兴奋的新目标。

单个数据中心 vs. 多个数据中心

在本书中，我们将被体系结构化的计算机定义为 一个数据中心，尽管许多互联网服务实际使用的是 地理位置相距甚远的多个数据中心。多个数据中心有时被用作 同一服务的完整副本，其复制机制主要用于 降低用户访问延迟 并 提升服务吞吐量。在这种情况下，单个用户请求会在 一个数据中心内部 被完整处理，因此我们对“机器”的定义是合适的。

而在某些情况下，用户查询需要跨 多个数据中心 进行计算，此时我们以单个数据中心为核心的关注点就不那么显而易见了。典型示例包括处理 非易失性用户数据更新 的服务，这类服务需要维护 多份副本 以实现 灾难容错。对于此类计算，由 一组数据中心 构成的系统可能才是更合适的抽象。同样地，视频流媒体 工作负载也能显著受益于跨多个数据中心和边缘节点的 内容分发网络（CDN）。

然而，我们选择将 多数据中心场景 视为更类似于一个 计算机网络。这样做一方面是为了 限制本书的讨论范围，但更主要的原因在于：数据中心内部通信 与 数据中心之间通信 在连接质量上存在着 巨大的差距，这使得程序员倾向于将这些系统视为 彼此独立的计算资源。随着此类应用的软件开发环境不断演进，或者如果未来这种连接差距显著缩小，我们可能需要重新调整对 机器边界 的选择。

为什么 WSC 可能与你息息相关

在本书第一版（约十年前）中，我们曾讨论 WSCs 可能被视为一个 小众领域，因为其 庞大的规模和高昂的成本 使得除少数大型互联网公司外，几乎无人能够负担。当时我们就认为事实并非如此，并指出：大型互联网服务所面临的问题 很快会对更广泛的群体产生意义，因为许多组织将能够以 更低的成本 负担得起 规模相当的计算机。

此后，我们的直觉得到了验证。如今，低端服务器级计算平台 所具备的优越经济性，使得 由数千节点组成的集群 已经进入了相当广泛的企业和研究机构的可承受范围。再加上 单芯片处理器核心数量持续增长 的趋势，今天的 单个服务器机架 所拥有的 硬件线程数，已经超过了十年前许多数据中心的规模。例如，一个包含 40 台服务器的机架，每台服务器配备 4 个 16 核、双线程 CPU，其总硬件线程数就超过 4,000！这样的系统在 规模、体系结构组织 以及 故障行为 上，与十年前的 WSCs 十分相似。 ¹ 在这些更加高度集成的未来系统中，硬件故障来源的相对统计数据可能会发生显著变化；但围绕着组件可靠性下降的硅工艺趋势，以及软件驱动故障可能持续产生的高影响，表明此类系统的程序员仍需面对一个充满故障的平台。

然而，也许更重要的是，基础设施即服务（IaaS） 云计算产品的 爆炸式增长与普及，已经使 WSCs 对 任何拥有信用卡的人 都触手可及。我们相信，构建这些系统的经验，对于理解 下一代云计算平台 的设计问题与编程挑战具有重要价值。

WSC 的体系结构概览

WSC 的硬件实现因部署而异。即使在 Google 这样的单一组织内部，不同年份部署的系统也会使用不同的基础构件，以反映产业所提供的硬件改进。然而，这些系统的 体系结构组织 相对稳定。因此，从高层次描述这一通用架构是有益的，因为它为后续讨论奠定了背景。

服务器

WSC 的硬件基础构件是 低端服务器，通常采用 1U 或 刀片机箱 形式，安装在机架中，并通过 本地以太网交换机 互连。这些 机架级交换机 可使用 40 Gbps 或 100 Gbps 链路，并通过多条上行连接连接到 集群级（或 数据中心级）以太网交换机。第二级交换域的规模可能覆盖 超过 10,000 台 独立服务器。

在 刀片机箱 的情况下，还存在一个额外的 第一级网络聚合：多个计算刀片通过 PCIe 等 I/O 总线 连接到少量网络刀片。图 1.1(a) 展示了一个 Google 服务器 的基础构件。近年来，WSC 还引入了额外的计算硬件构件，包括 GPU 和 定制加速器（例如 图 1.1(b) 所示的 TPU 板卡）。与服务器类似，这些组件通过 定制或行业标准的互连 在 机架（或 多机架 pod）层级进行连接，并最终接入数据中心网络。图 1.1(c) 展示了用于构建存储系统的 存储托盘。图 1.2 展示了这些构件如何被组装成 服务器机架与机架行，既适用于 通用服务器，也适用于 加速器。

² 由于既不满足于英制单位，也不满足于公制单位，机架设计人员使用 “机架单位（rack units）” 来衡量服务器高度。1U = 1.75 英寸（44.45 mm）；一个典型机架高度为 42U。

图 1.1： WSC 的示例硬件构件。从左到右：(a) 服务器主板，(b) 加速器板卡（Google 的 张量处理单元，TPU），(c) 磁盘托盘。

图 1.2： 互连机架与机架行中组装的硬件构件。

存储

磁盘 与 Flash SSD 是当今 WSC 存储系统的基础构件。为了向大量应用提供 持久化存储，这些设备被连接到数据中心网络，并由复杂的 分布式系统 进行管理。WSC 系统设计者需要根据需求做出多项权衡。例如：磁盘和 SSD 是应当 直接连接到计算服务器（直接附加存储，DAS），还是作为 网络附加存储（NAS）进行解耦？虽然 DAS 可以降低硬件成本并提升网络利用率（网络端口在计算与存储任务之间 动态共享），但 NAS 往往能够 简化部署，并通过避免计算作业的性能干扰来提供更高的 QoS。

此外，WSC（包括 Google 的系统）通常部署 桌面级磁盘（或其近似版本——近线磁盘），而非 企业级磁盘，以降低成本。总体而言，WSC 中的存储设备应追求在多项关键指标上的 全局最优 聚合视图，包括 带宽、IOPS、容量、尾延迟 以及 TCO。

分布式存储系统 不仅管理存储设备，还为应用开发者提供 非结构化 与 结构化 的 API。Google 文件系统（GFS），以及后来的 Colossus 和其云端版本 GCS，是 非结构化 WSC 存储系统 的示例，它们使用 高空间效率的 Reed–Solomon 编码 与 快速重构 来实现高可用性。BigTable 和 Amazon Dynamo 则是 结构化 WSC 存储 的示例，提供类似数据库的功能，但一致性模型较弱。为简化开发者的工作，新一代结构化存储系统（如 Spanner）提供了 类 SQL 接口 和 强一致性模型。

WSC 中 分布式存储 的特性也促成了 存储与网络技术 的相互作用。数据中心网络的快速演进与性能提升，造成了 网络与磁盘性能之间的巨大差距，以至于 WSC 的设计可以被大幅简化，而 不再需要考虑磁盘局部性。另一方面，诸如 Flash SSD 以及新兴的 非易失性内存（NVM） 等 低延迟设备，又为 WSC 设计带来了新的挑战。

WSC 设计者需要构建 平衡的系统，在 内存与存储技术层次结构 上进行整体权衡，综合考虑 集群级 的 总容量、带宽 与 延迟。第 3 章将更详细地讨论 系统平衡 问题。

网络互连架构

为 WSC 选择网络互连架构，需要在 速度、规模与成本 之间进行权衡。截至 2018 年，在单个机架内，以 40–100 Gbps 以太网 的全速互连服务器并不困难，常见的交换机可提供 48 个端口。因此，机架内部服务器之间的带宽通常是 均匀的。然而，用于连接 WSC 集群 的 高端口数网络交换机 具有完全不同的价格结构，其 单位端口成本 往往比普通机架级交换机 高出 10 倍以上。经验法则是：双向带宽提升 10 倍的交换机，其成本往往增加约 100 倍。

由于这种显著的成本不连续性，WSC 的网络互连架构通常采用两级层次结构。每个机架中的 商用交换机 仅通过少量 上行链路，向更昂贵的 集群级交换机 提供其一部分双向带宽，用于 跨机架通信。例如，一个 48 端口 的机架级交换机可以连接 40 台服务器 和 8 条上行链路，形成 5:1 的超额订阅比（每台服务器约 8–20 Gbps 的上行带宽）。在这种网络中，程序员必须意识到 集群级带宽资源相对稀缺，并尽量利用 机架级网络局部性，这增加了软件开发的复杂性，并可能影响资源利用率。

另一种方案是通过 投入更多成本 来消除部分集群级网络瓶颈。例如，InfiniBand 互连通常可扩展到 数千端口，但其 单位端口成本 明显高于商用以太网。同样，一些网络厂商也开始提供 更大规模的以太网互连架构，但每台服务器的成本依然更高。究竟应在 网络 上投入多少资金，而不是用于 额外的服务器或存储，这是一个 与应用相关 的问题，并不存在唯一正确答案。不过，在本书中，我们将假设：机架内互连的成本低于机架间互连。

建筑与基础设施

到目前为止，我们已经讨论了 WSC 的 计算、存储与网络 构件，它们类似于 PC 中的 CPU、内存、磁盘和网卡（NIC）。但要构成一台完整的计算机，还需要 电源、风扇、主板、机箱 等其他组件。类似地，WSC 还需要考虑与 供电、散热以及建筑基础设施 相关的其他重要组成部分。

WSC 的建筑物（及园区） 承载了前述的计算、网络和存储基础设施，而 建筑设计决策 会对 WSC 的可用性与正常运行时间 产生显著影响。（第 4 章将讨论数据中心建设行业中使用的 分级标准。）

同样，WSC 采用了复杂的 电力传输设计。在其运行规模下，WSC 的 功耗 往往超过 数千个普通家庭 的用电量。因此，它们采用一种 整体化且分层的供电架构：电力从公共电网进入，经由 变电站、配电单元、母线槽，最终到达服务器主板上的 电源轨与电压调节器；同时，在拓扑结构的不同层级提供相应的 备份与冗余，例如 UPS、发电机 和 备用电池。

WSC 还会产生大量 热量。与供电系统类似，它们采用 端到端的复杂散热方案，包含 分层的热交换回路：从数据中心地板上由 风机盘管 冷却的循环空气，到 换热器 和 冷水机组，直至与外部环境交互的 冷却塔。

建筑设计、输入能量的传输 以及 废热的移除，共同构成了与 供电功率成正比 的数据中心成本的重要组成部分，并且还会影响 计算设备的设计与性能（例如 加速器的液冷方案），以及工作负载所感知到的 可用性服务等级目标（SLO）。因此，这些因素与 单个计算、存储和网络构件 的设计同样重要，均需要进行优化。

图 1.3： 美国爱荷华州 Council Bluffs 的电力分配设施。

图 1.4： 美国乔治亚州 Douglas County 的数据中心冷却系统。

图 1.5： 美国北卡罗来纳州 Lenoir 的冷却塔与储水罐。

图 1.6： 美国爱荷华州 Council Bluffs 的 Google 数据中心航拍图。

图 1.7： 约 2018 年 7 月的 Google Cloud Platform 区域及可用区数量分布图。（该图按季度更新。）

功耗使用

在 WSC 的设计中，能源与功耗 是至关重要的考量因素，因为正如第 5 章将更详细讨论的那样，能源相关成本 已成为此类系统 总体拥有成本（TCO） 的重要组成部分。图 1.8 通过对 Google 于 2017 年 部署的一代 WSC 的 峰值功耗 按主要硬件组件进行分解，展示了现代 IT 设备中能耗的使用情况。

尽管该分布会因具体工作负载的系统配置而显著变化，但图中显示 CPU 是 WSC 中最大的能耗来源。有趣的是，本书第一版曾显示 内存系统 的相对能耗几乎与 CPU 持平；而自那之后，这一趋势发生了逆转，原因主要包括以下几个方面： 第一，更先进的 热管理技术 使 CPU 能够更接近其 最大功耗包络 运行，从而提高了每个 CPU 插槽的能耗； 第二，内存技术从 高功耗的 FBDIMM 转向 DDR3 与 DDR4，其能耗管理更加高效； 第三，DRAM 电压 从 1.8 V 降低到 1.2 V； 最后，当今系统中 每 GB DRAM 对应的 CPU 性能更高，这可能源于主存技术扩展路线所面临的更大挑战。

尽管 带宽需求的持续增长 仍可能逆转这些趋势，但目前 内存功耗 仍显著低于 CPU 功耗。此外，供电与散热开销 在总能耗中所占比例相对较小，这反映了多代以来在该领域的改进，其中许多改进是 专门为 WSC 设计 的。第 5 章将进一步讨论 WSC 的能效问题；关于 功耗随负载变化 的分析，可参见 图 5.6。

图 1.8： 现代数据中心中，各硬件子系统 峰值功耗 的近似分布（基于 2017 年末 一代服务器）。该图假设采用 双路 x86 服务器、每台服务器 12 条 DIMM，且 平均利用率为 80%。

故障与维修的处理

WSC 的巨大规模 要求互联网服务软件能够容忍 相对较高的组件故障率。例如，磁盘驱动器 的 年化故障率 可能高于 4%。不同部署环境中，服务器级重启 的年平均次数介于 1.2 次到 16 次 之间。在如此高的组件故障率下，一个运行在 成千上万台机器 之上的应用，可能需要 以小时为单位 对故障情况做出响应。我们将在 第 2 章（应用领域）和 第 7 章（故障统计）中对这一主题进行更深入的讨论。

全书概览

在本书的其余部分中，我们将进一步阐述上述问题。

第 2 章 从运行在 WSC 上的应用概览入手，这些应用定义了后续所有系统设计决策与权衡。我们讨论了 Web 搜索、视频流媒体 等关键应用，并覆盖了 系统基础设施栈，包括 平台级软件、集群级基础设施 以及 监控与管理软件。

第 3 章 介绍关键的 硬件构件。我们讨论 WSC 硬件 的高层设计考量，重点关注 服务器与加速器构件、存储架构 以及 数据中心网络设计；同时探讨 计算、存储与网络 之间的相互作用，以及 系统平衡 的重要性。

第 4 章 关注更高一层的系统设计，重点讨论 数据中心供电、散热基础设施 与 建筑设计。我们概述了 WSC 设计 中涉及的 机械与电气工程 基础，并通过案例研究深入分析 Google 在部分数据中心中如何设计 供电与散热系统。

第 5 章 讨论 能源与功耗效率 这一广泛主题。我们分析 一致性衡量能效 的挑战、数据中心层面的 PUE 指标，以及 功率超额订阅 的设计与收益；同时探讨 计算能效 面临的挑战，重点关注 能量按需比例计算 与 通过专用化提升能效。

第 6 章 讨论如何对 WSC 数据中心 的 总体拥有成本（TCO） 进行建模，涵盖 资本性支出 与 运营成本，并通过 传统计算机 与 WSC 的案例研究，分析 利用率 与 专用化 之间的权衡。

第 7 章 讨论 正常运行时间 与 可用性，包括用于展示 故障分类 的数据，以及 应对故障 和 优化维修 的方法。

第 8 章 以对 历史趋势 的讨论和 未来展望 作为结尾。随着 摩尔定律 的放缓，我们正进入一个令人振奋的 系统设计新时代；在这一时代中，WSC 数据中心 与 云计算 将处于核心位置，我们也将讨论未来面临的 挑战与机遇。

第 2 章 工作负载与软件基础设施

仓库级数据中心系统栈

运行在 仓库级计算机（WSCs） 上的应用，主导了许多系统设计中的权衡决策。本章概述了 大型互联网服务中运行的软件 的一些显著特征，以及构建 完整计算平台 所需的系统软件与工具。以下术语用于描述典型 WSC 部署中的不同软件层次：

• 平台级软件：存在于所有单个服务器上的通用 固件、内核、操作系统发行版 与 库，用于抽象单机硬件，并提供基础的 机器抽象层。
• 集群级基础设施：用于 资源管理 并在 集群层面 提供服务的一组 分布式系统软件。从本质上看，这些服务构成了 数据中心的操作系统。示例包括 分布式文件系统、调度器、远程过程调用（RPC）库，以及用于简化数据中心规模资源使用的 编程模型，如 MapReduce、Dryad、Hadoop、Sawzall、BigTable、Dynamo、Dremel、Spanner 和 Chubby。
• 应用级软件：实现特定服务的软件。通常将其进一步划分为 在线服务 与 离线计算 是有益的，因为二者的需求往往不同。在线服务的示例包括 Google Search、Gmail 和 Google Maps。离线计算通常用于 大规模数据分析，或作为生成在线服务所需数据的 处理流水线 的一部分，例如 构建 Web 索引，或 处理卫星图像 以生成在线地图服务所需的瓦片数据。
• 监控与开发软件：用于 跟踪系统健康状况与可用性 的软件，包括 监控应用性能、识别系统瓶颈 以及 衡量集群健康度。

图 2.1 总结了 WSC 中整体软件栈的这些层次。

图 2.1： Google 在仓库级计算机中的软件栈概览。

平台级软件

运行在 WSC 服务器节点 上的基础软件系统镜像，与常规企业级服务器平台并无太大差异，因此我们不会在该软件栈层次上展开过多讨论。

由于 WSC 服务器硬件配置的高度同质性，其 固件、设备驱动 或 操作系统模块 可以比通用企业服务器得到更大程度的简化。因为设备组合更少，固件与驱动的开发和测试 可以被显著精简。此外，WSC 服务器部署在一个 相对已知的环境 中，这为 性能优化 提供了机会。例如，WSC 服务器的大多数网络连接都指向 同一建筑物内的其他机器，其 分组丢失率 低于长距离互联网连接。因此，可以针对更高的通信效率，对 传输或消息参数（如 超时时间、窗口大小 等）进行调优。

虚拟化 最初在企业中因 服务器整合 而流行，如今在 WSC 中同样被广泛采用，尤其是在 基础设施即服务（IaaS） 云计算产品中。虚拟机（VM） 提供了一种 简洁且可移植的接口，用于管理 安全隔离 与 性能隔离，并允许多个 来宾操作系统 在有限额外复杂度下共存。VM 的传统劣势在于 性能开销，尤其是对 I/O 密集型工作负载。不过在许多场景中，这些开销正在降低，而 VM 模型的优势 已经超过其成本。VM 封装的简洁性也使得 实时迁移 更易实现（即在不关闭 VM 实例的情况下，将其迁移到另一台服务器），从而允许在 不影响用户计算 的前提下，对 硬件或软件基础设施 进行升级或维护。

容器（Containers） 是另一种流行的抽象方式，用于在 单一操作系统实例 上对多个工作负载进行隔离。由于每个容器 共享宿主机的 OS 内核 以及相关的 二进制文件和库，相比 VM 更加 轻量、体积更小，且 启动速度更快。

集群级基础设施软件

正如 操作系统层 对单台计算机的 资源管理与基础服务 至关重要一样，一个由 成千上万台计算机、网络与存储 构成的系统，也需要一层在 更大规模 上提供类似功能的软件。我们将这一层称为 集群级基础设施。该层由 三大类基础设施软件 组成。

资源管理

这也许是 集群级基础设施层 中 最不可或缺 的组成部分。它负责将 用户任务 映射到 硬件资源，实施 优先级 与 配额，并提供基本的 任务管理服务。在最简单的形式下，它只是一个接口，用于将 一组机器 以 手动（且静态） 的方式分配给某个用户或作业。更有用的版本则会提供 更高层次的抽象，自动化资源分配，并允许以 更细粒度 的方式共享资源。此类系统的用户可以在 相对较高的层次 描述其作业需求（例如 CPU 性能、内存容量 和 网络带宽），而 调度器 会将这些需求转换为合适的资源分配方案。

Kubernetes（www.kubernetes.io）是一种流行的 开源程序，用于承担这一角色，为 基于容器的工作负载 编排上述功能。基于 Google 集群管理系统 Borg 的思想，Kubernetes 提供了一系列 API 与控制器，允许用户以 开放容器倡议（OCI） 的通用格式（源自 Docker 容器）来描述任务。它支持多种 工作负载模式，从 横向扩展的无状态应用，到 数据库 等 关键的有状态应用。用户只需定义工作负载的 资源需求，Kubernetes 便会找到 最合适的机器 来运行它们。

在进行调度决策时，集群调度器 越来越需要同时考虑 功率限制 与 能耗优化，不仅用于应对 紧急情况（例如 冷却设备故障），也用于 最大化已配置数据中心电力预算的利用率。第 5 章将对这一主题进行更详细的讨论。此外，集群调度在做出决策时，还必须考虑 相关故障域 与 容错性，这一点将在 第 7 章 中进一步讨论。

集群基础设施

几乎每一个 大规模分布式应用 都需要一小组 基础功能，例如 可靠的分布式存储、远程过程调用（RPC）、消息传递 以及 集群级同步。在大型集群中，以 高性能 和 高可用性 正确实现这些功能极其复杂。为每个应用重复实现这类 棘手代码 并不可取，更明智的做法是创建 可复用的模块或服务。Colossus（GFS 的继任者）、Dynamo 和 Chubby，都是在 Google 和 Amazon 为大型集群开发的 可靠存储与锁服务 的示例。

在 小规模部署 中可以通过人工流程完成的许多任务，在 大规模系统 中则需要大量基础设施才能高效运行。例如：软件镜像分发 与 配置管理、服务性能与质量监控，以及在 紧急情况下 为运维人员进行 告警分流。微软的 Autopilot 系统为 Windows Live 数据中心中的部分此类功能提供了一个设计示例。

对 硬件设备整体健康状况 的监控同样需要 精细的监测、自动化诊断 以及 维修流程的自动化。Google 的 System Health Infrastructure 是实现高效健康管理所需软件基础设施的一个例子。最后，在如此规模的系统中进行 性能调试与优化 也需要 专用解决方案。由加州大学伯克利分校开发的 X-Trace 系统，是一种面向 大型分布式系统性能调试 的监控基础设施示例。

应用框架

前述的整个基础设施虽然 简化了硬件资源的部署与高效使用，但从根本上讲，并未向 普通程序员 隐藏 大规模系统 这一计算目标所固有的复杂性。从程序员的视角来看，硬件集群具有 深而复杂的内存/存储层次结构、异构组件、易发生故障的部件、来自同一系统中其他程序的 变化且可能具有对抗性的负载，以及 资源稀缺性（如 DRAM 和 数据中心级网络带宽）。

在大型服务中，某些 高层操作 或 问题子集 出现得足够频繁，因此值得构建 有针对性的编程框架，以简化新产品的开发。Flume、MapReduce、Spanner、BigTable 和 Dynamo 都是 基础设施软件 的典型示例，它们通过 自动处理数据分区、分发与容错，在各自领域中显著提升了 程序员生产力。

这些软件在 云环境 中的对应实现（如 Google Kubernetes Engine（GKE）、CloudSQL、AppEngine 等）将在本节后续关于 云计算 的讨论中进一步介绍。

应用级软件

工作负载多样性

Web 搜索 是最早获得广泛流行的大规模互联网服务之一。随着 20 世纪 90 年代中期 Web 内容数量的爆炸式增长，对如此海量信息进行组织已远远超出了 人工维护目录服务 所能完成的范围。然而，随着家庭和企业的 网络连接能力 持续提升，通过互联网提供 新型服务（有时甚至取代传统上位于客户端的计算能力）变得越来越具有吸引力。基于 Web 的地图服务 和 电子邮件服务 是这一趋势的早期例子。

服务种类的不断扩展，带来了 应用级需求的显著多样性。例如，搜索工作负载可能并不需要支持 高性能的原子更新，并且对 硬件故障 具有较强的容忍度（因为在 Web 搜索中，每一次结果都绝对精确并非至关重要）。而 广告点击跟踪 这类应用则完全不同：广告点击属于 小额金融交易，需要具备 事务型数据库管理系统 所期望的多种保证。图 2.2 展示了 Google 数据中心 中不同工作负载的 计算周期累积分布：前 50 个最主要的工作负载仅占 约 60% 的 WSC 总计算周期，其余部分由 长尾工作负载 构成。

一旦考虑到多种服务的多样化需求，数据中心显然必须被视为一个 通用计算系统。尽管 专用硬件解决方案 可能非常适合服务中的某些局部环节（我们将在第 3 章讨论 加速器），但需求的广泛性使得 通用系统设计 成为关键。另一个反对硬件高度专用化的因素是 工作负载演进速度：产品需求变化迅速，优秀的程序员可以通过经验不断改写 基础算法与数据结构，其速度远快于硬件本身的演进。因此，存在一种显著风险：当某种 专用硬件方案 真正实现时，它可能已经不再适合最初为之设计的问题领域，除非该领域存在 高度重视软硬件协同设计 的情况。尽管如此，在某些场景下，专用化 确实带来了显著收益，我们将在后文进一步讨论。

下面我们将介绍 Web 搜索、视频服务、机器学习 以及 基于引用的相似性计算 等工作负载。我们的目标并不是对互联网服务工作负载进行详尽描述——尤其考虑到这一市场的 高度动态性，这些描述在出版时可能已过时——而是在 高层次 上介绍一些典型工作负载，用以展示若干重要特征，以及 在线服务 与 批处理（离线）系统 之间的关键差异。

图 2.2： WSC 中工作负载的多样性。

Web 搜索

这是一个典型的 “大海捞针” 问题。尽管很难准确确定任意时刻 Web 的规模，但可以肯定的是，它由 数万亿个独立文档 组成，并且仍在持续增长。假设 Web 包含 1000 亿 个文档，平均每个文档在压缩后的大小为 4 KB，那么整个“草堆”的规模约为 400 TB。Web 搜索所使用的数据库，是通过对这一文档集合进行 倒排 构建而成的索引，其逻辑结构如 图 2.3 所示。

一个 词典（lexicon）结构 会为存储库中的每个词分配一个 ID。该 termID 对应一个 倒排列表（posting list），其中包含出现该词的所有文档，以及一些上下文信息，如 词在文档中的位置 和其他属性（例如该词是否出现在文档标题中）。

最终生成的 倒排索引 的大小取决于具体实现，但通常与原始文档存储库处于 同一数量级。一个典型的搜索查询由一系列词项组成，系统的任务是找出 同时包含所有词项 的文档（即 AND 查询），并判断哪些文档 最有可能满足用户需求。查询还可以包含 OR 操作符（表示可选项）或 短语操作符（限制词项必须按特定顺序出现）。为简化说明，下面的示例仅关注最常见的 AND 查询。

图 2.3： Web 索引的逻辑视图。

考虑一个查询，例如 new york restaurants。搜索算法必须遍历每个词项（new、york、restaurants）对应的倒排列表，直到找到 同时出现在三个列表中 的文档。随后，系统会根据多种参数对这些文档进行 排序，例如 文档整体重要性（在 Google 中，这包括 PageRank 分数以及词项出现次数、位置等属性），并将 排名最高 的结果返回给用户。

鉴于索引的巨大规模，该搜索算法通常需要在 数千台机器 上运行。这是通过将索引 切分（分片，sharding） 为负载均衡的子文件，并分布到多台机器上实现的。索引分区可以按 文档 或 词项 进行。用户查询首先由 前端 Web 服务器 接收，然后分发到索引集群中的所有相关机器。出于 吞吐量 或 容错 的需要，索引子文件可能会在多台机器上存放副本，此时一次查询只需涉及其中的 一部分机器。索引服务机器计算 本地结果 并进行 初步排序，随后将最优结果发送给前端系统（或中间服务器），由其从整个集群的结果中选出最终结果。此时，系统仅确定了 doc_ID 列表。接下来还需要 第二阶段，用于计算 文档标题、URL 以及 与查询相关的文档摘要，为用户提供上下文信息。该阶段通过将 doc_ID 列表 发送到存有文档副本的服务器来完成。与索引一样，如此规模的文档存储也必须进行 分片 并分布在大量服务器上。

上述操作的 用户可感知延迟 必须控制在 不到一秒 的范围内，因此该体系结构对 降低延迟 极为重视。同时，高吞吐量 也是关键性能指标，因为一个流行的服务可能需要支持 每秒数千次查询。索引会频繁更新，但在 单次查询的时间尺度 内，它可以被视为 只读结构。此外，由于不同机器上的索引查找除了最终的 结果合并 之外几乎无需相互通信，这一计算过程能够被 高效地并行化。再者，不同 Web 搜索查询之间在逻辑上 相互独立，这也为进一步并行提供了空间。

如果索引按 doc_ID 进行分片，该工作负载在 平均带宽 意义下对网络的需求相对较小，因为机器之间交换的数据量通常不超过查询本身的大小（约 数百字节），但它确实表现出一定的 突发性。本质上，前端服务器在将单个查询分发给大量服务器时，起到了 流量放大器 的作用，这会在 请求路径，以及可能的 响应路径 上形成流量突发。因此，即使整体网络利用率较低，也需要 精细的网络流量管理 来最小化拥塞。

图 2.4： 某数据中心中搜索服务在 24 小时 周期内的每日流量波动示例。

最后，由于 Web 搜索是一种 在线服务，它会受到 用户日常活动规律 的影响。图 2.4 展示了这种效应：在 高峰使用时段，流量可能是 低谷时段的两倍以上。这种 显著的流量波动 对系统运维提出了挑战，因为服务容量必须按照 显著高于平均值 的流量强度来进行配置。

视频服务

IP 视频流量 在 2016 年 占全球互联网流量的 73%，并预计到 2021 年 将增长到 83%。其中，直播视频 将增长 15 倍，点播视频（VOD） 将增长 2 倍。在 2015 年 7 月，用户每分钟向 YouTube 上传 400 小时 的视频；到 2017 年 2 月，用户每天观看的 YouTube 视频总时长已达到 10 亿小时。视频转码（将一种格式的视频解码后再编码为另一种格式）是任何视频共享基础设施中的关键组成部分：视频上传时采用了各种各样的 格式、编码器、分辨率、帧率、色彩空间 等组合。这些视频必须被转换为 客户端设备可播放 的一小部分 编码器、分辨率与格式，并根据 可用网络带宽 进行适配，以优化用户体验。

视频服务主要包含 三大成本组成： 第一，由于视频转码产生的 计算成本； 第二，视频目录（包括原始视频与转码版本）的 存储成本； 第三，向终端用户发送转码视频所需的 网络出口成本。 视频压缩编码 的改进能够降低存储与出口成本，但往往以 更高的计算成本 为代价。YouTube 的视频处理流水线会根据 视频的受欢迎程度分布 在这三者之间进行权衡，仅对 高度热门的视频 投入额外的压缩计算成本。下面我们将描述 点播视频 的处理方式；其他视频服务场景（如 即时转码 或 直播视频流）在高层次上是相似的，但由于所优化的 目标函数 不同，其体系结构也有所差异。

每个上传到 YouTube 的视频，都会首先从其 原始上传格式 转码为一个 临时的高质量通用中间格式，以便在流水线的其余阶段进行统一处理。随后，视频被 切分为多个片段，并转码为 多种输出分辨率与编码格式，以便在用户请求视频时，根据 可用网络带宽 和 播放设备能力，选择最合适的视频片段版本进行流式传输。视频片段被分布到多台机器上，从而 并行化 每个视频片段向多种格式的转码过程，并同时优化 吞吐量 与 延迟。最后，如果某个视频被识别为 高度热门，它还会经历 第二次转码，在这一阶段投入额外的计算资源，以在 相同的感知质量 下生成 体积更小 的视频版本。这样，用户可以在 相同网络带宽 下获得 更高分辨率 的视频，而增加的计算成本可以通过 大量播放带来的出口带宽节省 得到摊销。

图 2.5： YouTube 视频处理流水线。视频会根据其受欢迎程度被多次转码。VOD 表示 点播视频（video on demand）。

当视频片段在数据中心中被转码为 可直接播放的格式 后，它们会通过 边缘网络（Edge network） 进行分发。边缘节点会缓存 最近被观看的视频，以降低延迟并放大出口带宽。当用户请求的视频在边缘缓存中不可用时，请求会被转发到 最近的数据中心 或 对等的边缘节点，并从视频目录中上传所需内容。

学术文章相似性

响应用户请求的服务 为互联网服务的运行提供了大量 大规模计算 的示例。这些计算通常是 数据并行型工作负载，用于准备或封装 在线服务后续使用的数据。例如，计算 PageRank 或从 Web 存储库中生成 倒排索引文件 就属于这一类。

在本节中，我们使用一个不同的示例：在 学术论文与期刊 的存储库中查找 相似文章。这一功能对提供科学文献访问的互联网服务（如 Google Scholar）非常有用。文章相似性关系 作为 基于关键词搜索 的补充，为查找相关信息提供了另一种方式：当用户找到一篇感兴趣的文章后，可以请求系统显示与该文章 高度相关 的其他文章。

相似性分数可以通过多种方式计算，实际中通常会 组合多种方法。在学术文章领域，各种形式的 引文分析 已被证明能够提供高质量的相似性度量。这里我们考虑其中一种分析方法，称为 共被引（co-citation）。其基本思想是：凡是 同时引用文章 A 和文章 B 的论文，都会被视为对 A 与 B 相似性的 一次投票。在对所有文章完成该统计并进行适当归一化之后，我们就能得到 所有文章对之间的共被引相似性数值，并构建一个数据结构，使得对每篇文章都能返回一个 按相似性分数排序 的相关文章列表。该数据结构会 周期性更新，每次更新后的结果都会成为在线服务的 服务状态 的一部分。

计算过程从一个 引文图 开始，该图将 每篇文章的标识符 映射到其 所引用的文章集合。输入数据被划分为 数百个大小近似相等的文件（例如，对文章标识符取指纹、再对文件数量取模，用余数作为文件 ID），以支持 高效的并行执行。我们使用一系列 MapReduce 作业，将引文图转换为 所有文章的共被引相似性向量。在第一个 Map 阶段，对每个引文列表 (A1, A2, A3, …, An) 生成 所有可能的文章对，并将它们送入 Reduce 阶段，由后者统计 每一对文章出现的次数。该步骤生成一个结构，用于将 所有共被引的文章对 与其 共被引计数 关联起来。需要注意的是，这并不会导致 二次规模爆炸，因为大多数文档对的共被引计数为零，因此会被省略。第二轮 MapReduce 会将 同一文章 的所有条目分组，对其分数进行 归一化，并生成一个 按相似性分数递减排序 的相关文章列表。

这一 两阶段的数据并行程序 在 数百台服务器 上执行，每个阶段的计算相对轻量，但在 Map 与 Reduce 工作节点之间会产生 大量全互连通信。然而，与 Web 搜索不同的是，这里的网络流量是 流式 的，因此对现有 拥塞控制算法 更为友好。同时，与 Web 搜索相反，单个任务的延迟 并不关键，整体并行效率 才是该工作负载最重要的性能指标。

机器学习

深度神经网络（DNN） 带来了突破性进展，例如自 2011 年 起，将一次图像识别竞赛的错误率从 26% 降至 3.5%，以及在围棋比赛中击败人类冠军。在 Google，DNN 被应用于 语音、视觉、语言、翻译、搜索排序 等众多领域。图 2.6 展示了 Google 机器学习规模的增长趋势。

神经网络（NN） 旨在实现类似大脑的功能，其基础是一个简单的 人工神经元：对输入的 加权和 施加一个 非线性函数（例如 max(0, value)）。这些人工神经元被组织成 多层结构，前一层的输出作为后一层的输入。DNN 中的 “深度” 指的是 层数超过少量层；随着云端 大规模数据集 的出现，通过增加 层数与层规模 来捕获更高层次的模式或概念，从而构建更精确的模型成为可能。

DNN 包含两个阶段：训练（training / learning） 与 推理（inference / prediction），分别对应 模型的开发 与 模型的使用。DNN 工作负载还可进一步划分为多种类型：卷积型、序列型、基于嵌入、多层感知机 以及 强化学习。

训练 的目标是确定 DNN 的 权重或参数，通过反复调整，直到模型产生期望结果。几乎所有训练都在 浮点数 下进行。在训练过程中，多个 学习器 处理训练数据集的不同子集，并通过 参数服务器 或 学习器之间的归约 来协调参数。学习器通常会对输入数据集进行 多轮（epoch） 处理。训练可以是 异步 的——每个学习器独立与参数服务器通信；也可以是 同步 的——学习器在每一步后 同步更新参数。最新研究表明，同步训练能提供 更好的模型质量，但其性能受限于 最慢的学习器。

推理 使用训练阶段生成的 DNN 模型对数据进行预测。DNN 推理通常 面向用户，并且具有 严格的延迟约束。推理可采用 浮点计算（单精度、半精度）或 量化计算（8 位、16 位）。为了在不损失质量的前提下进行推理，需要对 浮点训练得到的模型 进行 精细量化。更低精度的推理能够带来 更低的延迟 与 更高的能效。

当前流行的 三类神经网络 包括：

1. 多层感知机（MLP）：每一新层由前一层 所有输出 的 加权和 经过 非线性函数 形成（全连接）。
2. 卷积神经网络（CNN）：每一后续层对前一层 空间上相邻的输出子集 进行加权求和并施加非线性函数，同时 复用权重。
3. 循环神经网络（RNN）：每一后续层是对 当前输出 与 先前状态 的加权和施加非线性函数。最流行的 RNN 是 LSTM（长短期记忆），其核心在于 决定遗忘什么、保留什么作为状态 传递到下一层，且 权重在时间步之间复用。

表 2.1 描述了 六个生产级应用（每类 NN 各两个示例）以及 ResNet50 基准。其中一个 MLP 是 RankBrain 的较新版本；一个 LSTM 来自 GNM Translate 的子集；一个 CNN 是 Inception；另一个 CNN 是 DeepMind AlphaGo。

图 2.6： Google 机器学习规模的增长情况。

表 2.1： 六个生产应用与 ResNet 基准。第四列为 训练收敛所需的总操作数（非执行速率）。

神经网络类型	参数量（MiB）	训练示例数（至收敛）	收敛所需 ExaOps	训练每示例操作数	推理每示例操作数
MLP0	225	1 万亿	353	353 Mops	118 Mops
MLP1	40	6500 亿	86	133 Mops	44 Mops
LSTM0	498	14 亿	42	29 Gops	9.8 Gops
LSTM1	800	6.56 亿	82	126 Gops	42 Gops
CNN0	87	16.4 亿	70	44 Gops	15 Gops
CNN1	104	2.04 亿	7	34 Gops	11 Gops
ResNet	98	1.14 亿	< 3	23 Gops	8 Gops

监控基础设施

集群级基础设施软件层 的一个重要组成部分，关注于各种形式的 系统内省。由于 工作负载 与 硬件基础设施 的规模和复杂性，使得 监控框架 成为任何此类部署中的 基础性组件，因此我们在此对其进行更为详细的介绍。

服务级仪表板

系统运维人员必须持续跟踪互联网服务在多大程度上满足其 服务级指标（SLIs）。监控信息必须 足够新鲜，以便运维人员（或自动化系统）能够 迅速采取纠正措施，避免发生严重中断——响应时间应以 秒 为单位，而非 分钟。幸运的是，最关键的信息通常仅限于 少数几个信号，这些信号可以从 前端服务器 收集，例如 用户请求的延迟 与 吞吐量统计。

在最简单的形式下，这类监控系统可以只是一个 脚本，每隔几秒轮询所有前端服务器，获取相应信号并将其显示在 仪表板 上。Stackdriver Monitoring 是一个 公开可用 的工具，其基础设施与 Google 的内部监控系统相同。

对于 大规模服务 而言，通常需要 更复杂且可扩展 的监控支持，因为前端服务器数量可能非常庞大，而且需要收集更多信号来刻画服务的 健康状况。例如，不仅需要采集信号本身，还可能需要采集其 随时间变化的导数。系统还可能需要监控 业务相关参数，而不仅仅是延迟和吞吐量。监控系统通常支持一种 简单语言，使运维人员能够基于被监控的基础信号，定义 派生参数。最后，系统会根据监控值和阈值，向 值班运维人员 生成 自动告警。

对告警（或报警）系统进行 精细调优 是一项具有挑战性的任务：如果 误报过多，运维人员可能会忽略真正的重要告警；而如果告警只在 极端情况下 才触发，则可能在运维人员注意到问题时已经 为时过晚，难以及时、平滑地解决潜在问题。

性能调试工具

尽管 服务级仪表板 能帮助运维人员迅速识别 服务层面的问题，但它们通常缺乏足够的细节信息，无法解释 为什么服务变慢 或 为何未达到性能要求。运维人员和服务设计者都需要工具，来帮助他们理解 多个程序之间的复杂交互——这些程序可能运行在 数百台服务器 上——从而确定 性能异常的根本原因 并识别 系统瓶颈。与服务级仪表板不同，性能调试工具 通常不需要为 在线运行 提供实时信息。可以将其视为 数据中心版的 CPU profiler，用于确定程序中 哪些函数调用 占据了大部分执行时间。

为满足这一需求，人们提出了多种 分布式系统追踪工具。这类工具试图确定在 某个发起者（如用户请求）触发下，分布式系统中完成了哪些工作，并描述各个组件之间的 因果关系 或 时间关系。这些工具通常分为两大类：黑盒监控系统 与 应用/中间件插桩系统。

黑盒监控工具 的代表包括 WAP5 和 Sherlock。它们通过 观察系统组件之间的网络流量，并利用 统计推断方法 来推断因果关系。由于除网络接口外，将所有系统组件都视为 黑盒，这种方法的优势在于 无需了解或修改应用程序或软件基础设施。然而，这种方式不可避免地牺牲了 信息精度，因为所有关系都必须通过统计方式推断。虽然可以通过收集和分析更多消息数据来提升准确性，但代价是 更高的监控开销。

基于插桩的追踪方案（如 Pip、Magpie 和 X-Trace）则利用显式修改 应用程序或中间件库 的能力，在 跨机器 和 机器内部模块边界 传递追踪信息。被标注的模块通常还会将追踪信息记录到 本地磁盘，供后续由外部性能分析程序收集。这类系统由于 无需推断，因此可以非常精确，但其代价是 分布式系统中的所有组件 都必须进行插桩，才能获得完整的数据。

Google 开发的 Dapper 系统，是一种 基于标注的追踪工具，通过仅对少数 所有应用普遍链接的关键模块（如 消息传递、控制流 和 线程库）进行插桩，从而在很大程度上对 应用级软件保持透明。Stackdriver Trace 是 Dapper 系统的一个 公开实现。XRay 是 LLVM 编译器的一项功能，通过 编译器插桩 在每个函数入口和出口添加追踪点，在启用时可提供 极其精细的延迟信息，而在未启用时仅带来 极低的开销。对于 更深层次的内省，Stackdriver Debugger 允许用户在 无需重新编译或重新部署 的情况下，动态地为程序添加日志。

基于 硬件性能计数器采样 的 CPU profiler 在帮助程序员理解 微体系结构层面的性能现象 方面取得了巨大成功。Google-Wide Profiling（GWP） 会随机选择一部分机器，收集 整机 与 进程级 的短时性能剖析数据，并结合 Google 所有二进制文件的 符号信息仓库，生成 集群范围 的性能视图。GWP 能够回答诸如：在 Google 范围内执行最频繁的过程是什么？ 或 哪些程序是内存使用最多的？ 等问题。公开可用 的 Stackdriver Profiler 产品正是受 GWP 启发而设计的。

平台级健康监控

分布式系统追踪工具 和 服务级仪表板 同时衡量应用的 健康状况 与 性能。这些工具可以推断某个 硬件组件 可能出现异常，但这种判断仍然是 间接的。此外，由于 集群级基础设施 与 应用级软件 都被设计为能够 容忍硬件组件故障，在这些层面进行的监控可能会 漏掉大量潜在的底层硬件问题，使其逐渐积累，直到 软件层面的容错机制 无法继续缓解为止。届时，服务中断可能会 非常严重。因此，需要能够 持续且直接 监控计算平台健康状况的工具，以理解并分析 硬件与系统软件故障。第 7 章将更详细地讨论其中一些工具，以及它们在 Google 基础设施 中的应用。

站点可靠性工程

虽然前文主要讨论的是 基础设施软件，但大多数 WSC 部署还支持一项重要职能，称为 站点可靠性工程（Site Reliability Engineering，SRE）。这与传统系统管理不同，其特点在于：软件工程师 负责系统集群的 日常运维任务。SRE 工程师会设计 监控与基础设施软件，使系统能够 自动适应负载变化 与 常见故障，从而尽量 不需要人工介入，并使频繁发生的事件能够 自愈。一本由多位 Google SRE 工程师撰写的优秀著作，总结了在大规模 WSC 部署中 SRE 所采用的更多原则。

WSC 软件权衡

数据中心 vs. 桌面系统

互联网服务中的软件开发，在许多方面都不同于传统的 桌面/服务器模型。

• 充足的并行性：典型的互联网服务表现出大量并行性，来源于 数据级并行 与 请求级并行。通常，难点并不在于发现并行性，而在于 管理并高效利用 应用中显式存在的并行性。数据级并行源自 规模庞大且相对独立的数据记录集，例如 数十亿网页 或 数十亿条日志 的处理。这些超大规模数据集往往要求每个并行（子）任务执行 大量计算，从而有助于 隐藏或容忍通信与同步开销。类似地，请求级并行来自于 热门互联网服务每秒接收的数百或数千个请求。这些请求很少涉及 读写共享数据 或 跨请求同步。例如，搜索请求在本质上是 相互独立 的，并且主要操作 只读数据库；因此，计算既可以在 单个请求内部 划分，也可以在 不同请求之间 划分。同样地，尽管 Web 邮件事务确实会修改用户数据，但 不同用户的请求 在本质上是相互独立的，从而形成了 天然的数据分区与并发单元。只要更新速率较低，即使是 高度互联的数据系统（如社交网络后端），也能从 高请求并行性 中获益。

• 工作负载快速演进：互联网服务的用户通过 相对稳定且定义良好的高层 API（如简单的 URL）与服务交互，从而与其实现细节隔离，这使得 快速部署新软件 变得更加容易。Google 关键服务组件的发布周期通常只有 数周，而桌面软件产品往往需要 数月甚至数年。例如，Google 的 前端 Web 服务器二进制文件 采用 每周发布 的节奏，由 数百名开发者 提交的 近千项独立代码更改 组成——而 Google 搜索服务的核心实现，几乎每 2–3 年 就会被 从头重写。这种环境极大地激励了 快速产品创新，但也使系统设计者 难以从已有应用中提取有价值的基准测试。此外，由于互联网服务仍是一个 相对较新的领域，新产品和新服务不断涌现，其 用户成功程度 会直接影响数据中心中的 工作负载构成。例如，YouTube 等视频服务在相对较短时间内迅速发展，其需求特性与数据中心中既有的大型计算周期消费者 截然不同，从而可能影响 WSC 的 最优设计点。这种激进的软件部署环境还带来一个积极的副作用：硬件架构师 不必始终为 不可变的代码 提供良好性能；相反，他们可以考虑 通过大规模软件重写 来充分利用 新的硬件能力或设备。

• 平台同质性：与桌面系统相比，数据中心通常是一个 更加同质 的软件开发目标平台。大型互联网服务运营往往在任一时间只部署 少量硬件与系统软件配置。显著的异构性主要来自于 逐步引入更具成本效益的新组件 的动机。同一平台代际内部的同质性，有助于 简化集群级调度与负载均衡，并降低 平台软件（如内核和驱动）的维护负担。同样地，同质性还能带来 更高效的供应链 与 更高效的维修流程，因为自动化和人工维修都能从 更少类型系统的丰富经验 中受益。相比之下，桌面系统软件几乎无法对其部署的 硬件或软件平台 做出假设，由于需要支持 成千上万甚至数百万种配置，其复杂性与性能特性往往因此受损。

• 非无故障运行环境：由于互联网服务应用运行在 由数千台机器组成的集群 上，而这些机器的可靠性并不显著高于 PC 级硬件，单个组件故障率的 乘法效应 意味着 每隔几小时甚至更短时间 就会发生某种故障。正因如此，虽然桌面级软件可以合理地假设 硬件在数月甚至数年内无故障运行，但这一假设对 数据中心级服务 并不成立：互联网服务必须运行在一个 故障是日常常态 的环境中。理想情况下，集群级系统软件 应提供一层抽象，将大部分复杂性 隐藏在应用级软件之下，尽管这一目标对所有类型的应用来说都 并不容易实现。

尽管 丰富的线程级并行性 和 更同质的计算平台 相比桌面系统降低了互联网服务的软件开发复杂度，但 系统规模、在硬件故障下运行的需求 以及 工作负载快速演进，却在相反方向上增加了复杂性。

性能与可用性的工具箱

在 基础设施层 与 应用层 中，一些基本的编程概念由于在实现 高性能 或 高可用性 的大规模部署中具有广泛适用性，因此会反复出现。下表（表 2.2）描述了其中一些最常见的概念。Hamilton、Brewer 和 Vogels 的相关文章，对不同组织如何思考 超大规模互联网服务部署 这一通用问题提供了有价值的进一步阅读材料。

表 2.2：性能与可用性权衡中的关键概念

技术	主要优势	描述
复制（Replication）	性能与可用性	数据复制可以同时提升 吞吐量 和 可用性。当被复制的数据 不经常修改 时尤为有效，因为复制会使更新过程更加复杂。
Reed–Solomon 编码	可用性与空间节省	当主要目标是 可用性 而非 吞吐量 时，纠错编码可以在 更低空间开销 的情况下实现数据丢失恢复，相比直接复制更加高效。
分片（Sharding / Partitioning）	性能与可用性	分片将数据集拆分为更小的片段（shards），并分布到大量机器上。对数据集的操作会被分发到部分或全部分片，由调用方合并结果。分片策略可根据 空间限制 与 性能需求 变化。使用 非常小的分片（或 微分片）对 负载均衡 与 恢复 尤其有利。
负载均衡（Load-balancing）	性能	在大规模服务中，服务级性能往往取决于 数百或数千台服务器中最慢的响应者，因此 降低响应时间方差 至关重要。 在分片服务中，可通过 调整分片策略 来均衡每台服务器的工作量；该策略可能需要基于 请求混合 或 服务器相对性能。即使在同质机器上，若服务器同时运行多个应用，负载均衡客户端仍可能观察到 性能差异。 在复制服务中，负载均衡代理可以 动态选择 将新请求分派到哪些服务器。由于不同请求的工作量并非恒定或可预测，实现 完美负载均衡 仍然困难。 微分片 通过提供更小的工作单元，使 动态负载均衡 更容易，并可用于缓解热点。
健康检查与看门狗定时器	可用性	在大规模系统中，故障常表现为 服务器变慢或无响应。在这种环境下，任何操作都不能假设服务器一定能向前推进。必须 快速判断 服务器是否过慢或不可达，并将新请求 绕开。RPC 需要设置 合理的超时 来中止长时间运行的请求；基础设施软件还可能需要 持续检查连接级响应性 并在必要时采取行动。
完整性校验	可用性	除了无响应外，故障有时还表现为 数据损坏。尽管较少见，但确实会发生，而且常以 底层硬件或软件校验未能捕获 的方式出现（例如，某些网络 CRC 校验的错误覆盖不足）。通过 改变底层编码 或 添加更强的冗余完整性校验，额外的软件检查可以缓解这些问题。
应用特定压缩	性能	在现代数据中心中，存储 往往占据设备成本的重要部分。对于 吞吐量要求极高 的服务，将尽可能多的 工作集 放入 DRAM 至关重要；因此，压缩技术非常重要，因为 解压速度 比 磁盘寻道 快几个数量级。尽管通用压缩算法已相当出色，但 了解数据编码与取值分布 的 应用级压缩 往往能实现 更高压缩比 或 更快解压速度。
最终一致性（Eventual consistency）	性能与可用性	使用传统数据库管理系统的保证来保持 多副本强一致，往往会 显著增加复杂性、降低性能 并 削弱可用性。幸运的是，许多应用对一致性的要求更为宽松，只要系统 最终收敛到一致状态，即可在 有限时间内容忍不一致视图。
集中式控制	性能	理论上，具有 单一主节点 的分布式系统，其整体可用性受限于主节点的可用性。然而，集中式控制 实现更简单，且通常能提供 更快速的控制响应。在 Google，我们倾向于在大量基础设施软件（如 MapReduce 和 GFS）中采用集中式控制模型，并通过 主节点故障切换协议 来解决主节点可用性问题。
金丝雀（Canaries）	可用性	一种虽罕见但现实的灾难性故障场景是：单个请求 被分发到 大量服务器，触发 程序崩溃型缺陷，导致 系统级宕机。Google 常用的一种技术是，先将请求发送到 一台（或少数几台）服务器，仅在该 金丝雀请求 成功完成后，才将请求提交给系统其余部分。
冗余执行与尾延迟容忍（Tail-tolerance）	性能	在 超大规模系统 中，并行任务的完成时间可能被 极少数子任务的慢执行 所拖累；系统规模越大，这种情况越可能发生。有时，对子任务进行 少量冗余执行，就能带来 显著的整体加速效果。

购买 vs. 自建

传统的 IT 基础设施大量使用 第三方软件组件，例如 数据库 和 系统管理软件，并将重点放在开发 为特定业务直接创造价值 的软件上，例如构建在 应用服务器 和 数据库引擎 之上的业务逻辑。而像 Google 这样的大规模互联网服务提供商通常采取不同的方法：不仅 应用特定逻辑，而且 大量集群级基础设施软件 都由内部自行开发。平台级软件 确实会使用第三方组件，但这些通常是 开源软件，可以根据需要在内部进行修改。因此，整个软件栈中有更大一部分 处于服务开发者的控制之下。

这种方式增加了 软件开发与维护 的工作量，但在 灵活性 与 成本效率 方面带来了重要收益。当需要修复 关键功能缺陷 或 性能缺陷 时，灵活性尤为重要，因为它允许在各个层次上 快速完成缺陷修复。这也简化了复杂系统问题的处理，因为它为问题的解决提供了 多种选择。例如，一个不理想的 网络行为 可能在 应用层 难以解决，但在 RPC 库层 却相对简单，反之亦然。

从历史上看，在本书第一版撰写之时，支持 自建而非购买 的一个主要原因是：所需的仓库级软件基础设施在商业上尚不可得。此外，如果第三方软件供应商 自身并未维护大规模集群，就很难对其软件进行充分的 测试与调优。最后，内部开发的软件 往往可以更加 简洁且高效，因为它只需满足 少数服务 的需求，从而能够在该领域内进行高度优化。例如，BigTable 省略了传统 SQL 数据库的一些核心特性，以换取其目标用例所需的 更高吞吐量与可扩展性；GFS 同样没有提供 完全符合 POSIX 的文件系统接口，原因亦是如此。如今，这类 可扩展软件开发模型 已更加普遍。大多数主要云服务提供商都有 内部开发的等价软件系统，而相应的 开源版本 也被广泛采用（如 Kubernetes、Hadoop、OpenStack、Mesos）。

尾延迟容忍

在本章前文中，我们介绍了多种 大规模软件系统 中常用的技术，用以实现 高性能 与 高可用性。然而，随着系统规模不断扩大，以支持更强大的 在线 Web 服务，我们发现这些技术本身 不足以 在服务整体层面提供 可接受的尾延迟。（尾延迟 指的是 最慢请求 的延迟，即 延迟分布的尾部。）

研究指出，在足够大的系统规模下，试图 消除所有单个系统组件的性能波动来源，其不切实际程度不亚于在一个 大型容错系统 中试图让所有组件 完全无故障运行。

考虑一个假想系统：每台服务器的 典型响应时间 为 10 ms，但其 99 分位延迟 为 1 s。也就是说，如果一个用户请求只由一台服务器处理，那么 每 100 个请求中就有 1 个 会变慢（耗时 1 s）。图 2.7 展示了在这种假设下，随着 集群规模 增加，哪怕 极小比例 的高延迟异常，也会对 服务级延迟 产生显著影响。

如果一个用户请求需要 并行收集 100 台服务器 的响应，那么 63% 的用户请求将耗时 超过 1 s（图中以 “x” 标示）。即便在 单台服务器层面，只有 1/10,000 的请求会出现 超过 1 s 的延迟，一个包含 2,000 台服务器 的服务，也会看到 将近五分之一 的用户请求耗时超过 1 s（图中以 “o” 标示）。

图 2.7： 随着系统规模与服务器级高延迟异常频率变化，服务级响应时间超过 1 s 的概率。

相关研究展示了一些 编程技术，能够在容忍此类 延迟波动 的同时，仍然在服务层面提供 较低的尾延迟。这些技术通常利用 已为容错而配置的资源复制，从而只为现有系统带来 很小的额外开销。可以预见，随着未来十年中 更加强大的在线 Web 服务 不断出现，尾延迟容忍技术 将变得 愈发重要。

工程师应当了解的延迟数字

本节受到 Jeff Dean 总结的 工程师应当了解的关键延迟数字 的启发。这些 粗略的操作延迟 有助于工程师在 一阶近似 下，对 吞吐量、延迟与容量 进行推理。我们在此对这些数字进行了更新，以反映 WSC 中 技术与硬件 的变化。

表 2.3：每位 WSC 工程师都应了解的延迟数字

操作	时间
L1 缓存访问	1.5 ns
L2 缓存访问	5 ns
分支预测失败	6 ns
无竞争互斥锁加锁/解锁	20 ns
L3 缓存访问	25 ns
主存访问	100 ns
使用 Snappy 解压 1 KB 数据	500 ns
“远端内存” / 高速 NVM 访问	1,000 ns（1 μs）
使用 Snappy 压缩 1 KB 数据	2,000 ns（2 μs）
从内存顺序读取 1 MB	12,000 ns（12 μs）
SSD 随机读取	100,000 ns（100 μs）
从 SSD 顺序读取 1 MB	500,000 ns（500 μs）
通过 10 Gbps 网络顺序读取 1 MB	1,000,000 ns（1 ms）
从磁盘顺序读取 1 MB	10,000,000 ns（10 ms）
磁盘寻道	10,000,000 ns（10 ms）
数据包往返 加州 → 荷兰 → 加州	150,000,000 ns（150 ms）

云计算

近年来，云计算 已成为一种重要模型，用于以 构建在 WSC 之上 的方式取代传统的企业计算系统。高速互联网 的普及，使得许多应用能够从传统的 本地部署计算机与桌面系统 迁移到云端，在 商业提供商的数据中心 中远程运行。云计算带来了 效率、灵活性与成本节约。其 成本效率 主要通过在同一物理主机上 共置多个虚拟机（VM） 来提高资源利用率实现。

从高层次看，虚拟机 与其他在线 Web 服务类似，都是构建在 集群级软件 之上，以利用 整个仓库级数据中心软件栈。尽管 基于 VM 的工作负载模型 是将本地计算迁移到 WSC 的最直接方式，但它也带来了一些额外挑战：I/O 虚拟化开销、可用性模型 以及 资源隔离。下面将对此进行进一步讨论。

图 2.8： Google Cloud Platform 工作负载的 基于虚拟机的软件栈概览。

• I/O 虚拟化：虚拟机无法直接访问 本地硬盘 或 网络 等硬件资源。所有 I/O 请求都会通过 抽象层（如 virtio）在来宾操作系统中发出，由 虚拟机监控器（VMM） 将其转换为相应操作。例如，存储请求会被重定向到 网络持久化磁盘 或 本地 SSD，网络请求则通过 虚拟化网络 进行封装。尽管 I/O 虚拟化通常会引入一定的 性能开销，但 虚拟化技术 与 硬件支持 的持续改进，已显著降低了这些开销。

• 可用性模型：大规模分布式服务通常通过在 单个数据中心内运行多个实例，并在 数据中心层面 维持 N + 1 冗余，以尽量减少 计划性维护事件 的影响。然而，许多企业应用 用户规模较小，且使用 较旧的软件栈（如 关系型数据库），往往难以进行 水平扩展。因此，云服务提供商使用 实时迁移（live migration） 技术，通过在计划维护（包括 系统更新 与 配置变更）期间，将正在运行的 VM 迁移到其他主机 来保障高可用性。

• 资源隔离：如前所述，单个组件的延迟波动 在服务层面会因 干扰效应 被放大。资源服务质量（QoS） 已被证明是缓解此类干扰影响的有效技术。在云计算环境中，恶意 VM 可能利用 多租户特性 对共享资源造成严重争用，从而实施 拒绝服务（DoS） 或 侧信道攻击。因此，在 安全保证 与 资源共享 之间取得平衡尤为重要。

公有云服务的 WSC 与内部工作负载

Google 在将 基于 VM 的公有云 作为企业产品（即 Google Cloud Platform）推出之前，已设计 WSC 近十年。在那段时间里，Google 的计算需求主要由 搜索与广告工作负载 主导，因此在设计 WSC 及其 软件栈 时，自然会优先考虑这些特定工作负载的需求。软硬件工程师利用这一 相对狭窄的需求集合，在整个技术栈上进行 纵向优化，并构建了一套 高度定制的内部解决方案，使得内部开发环境与早期公有云平台 逐渐分化。

随着 内部工作负载组合的不断扩展，Google 的内部设计也必须适应 更通用的使用场景；因此，在大多数应用领域中，内部工作负载需求 与 公有云需求 之间的差距已显著缩小。尽管仍存在一些差异，但如今 内部与外部开发者 体验到的 底层平台 已高度相似，这使得 内部创新 能够比十年前 更快地 引入给外部用户。一个典型例子是 TPU 近期向 Google Cloud Platform 客户开放（第 3 章将进一步讨论）。

云原生软件

云服务的迅速普及，催生了对 充分利用云能力的软件 的全新关注。伴随着 容器 成为工作负载的主要载体，“云原生（Cloud Native）” 理念强调 私有数据中心中难以实现 的云特性，例如 高度动态的运行环境、API 驱动的自助式运维 以及 即时、按需分配的资源。云具备一种 弹性，是物理 WSC 难以匹敌的。这些特性使开发者能够构建 强调可扩展性与自动化 的软件，同时 最小化运维复杂性与人为负担。

正如 容器 与 编排器 推动了这一转变，其他技术也常常被同时采用。微服务 将大型、往往是 单体式 的应用拆分为 更小、功能单一 的服务，它们通过 明确的 API 协作，但可以 独立管理、版本化、测试与扩展。服务网格 使应用运维人员能够将 应用本身的管理 与 其周边网络管理 解耦。服务发现系统 则允许应用与微服务在 高度动态的环境 中 实时发现彼此。

仓库级规模的信息安全

云用户 依赖 WSC 提供商 作为用户或客户数据的 负责任管理者。因此，大多数提供商都会在 分层且复杂的安全态势 上投入大量资源。现实情况是，在如此规模下 安全问题不可避免，这要求采取一种 整体性方法，同时覆盖 预防、检测与修复。许多商业软件或硬件厂商提供针对 特定安全问题 的单点解决方案，但几乎没有能够覆盖 WSC 端到端安全 的完整方案。其 范围之广 与 规模之大 相匹配，严肃的 WSC 基础设施需要 严肃的信息安全专业能力。

在 硬件层面，首先要关注 物理数据中心 的安全。WSC 提供商会采用 生物识别、金属探测、摄像系统、车辆阻挡 以及 基于激光的入侵检测系统 等技术，并严格限制 允许进入数据中心机房的人员数量。同时，还会投入精力核查 硬件来源（provenance） 以及其 设计基础。一些 WSC 提供商还会在 加密机器身份 与 初始固件引导安全 上采用 定制化方案，例如 Google 的 Titan、Microsoft 的 Cerberus 和 Amazon 的 Nitro。

部署在该基础设施之上的服务会对 服务间通信 进行 加密；建立 服务身份、完整性与隔离 机制；在身份原语之上实现 访问控制；并最终对 终端用户或客户数据的访问 进行 严格控制与审计。即便硬件是正确且按预期运行的，问题仍可能出现。近年来的处理器漏洞事件凸显了 纵深防御（defense-in-depth） 的必要性，以及 评估风险并开发、部署缓解措施 的专业能力。WSC 提供商会使用 协同化管理系统，以 快速且受控 的方式部署 CPU 微码、系统软件更新 或其他补丁；部分提供商还支持 客户 VM 的实时迁移，以便在 不打断工作负载 的情况下升级底层机器。

一些 单点挑战（例如 终端用户身份认证）本身就会引发一整套 安全与隐私 难题。在 密码复用 与 不良密码实践 普遍存在的情况下实现大规模身份认证，并防止 登录或账户恢复滥用，往往需要 专门的专家团队。

静态数据（data at rest） 必须始终 加密，通常通过 以服务为中心 与 以设备为中心 的系统共同实现，并使用 相互独立的密钥与管理域。存储服务还面临一种 认知张力：既要满足 高持久性，又要能够 真正且可信地声明数据已被删除或销毁。在许多场景下，这些服务还会对 网络基础设施 提出更高要求，常常需要 额外的计算资源 来确保 网络流量得到充分加密。

内部网络安全 需要与 保护互联网规模通信 的基础设施并行管理。导致 工作负载迁移 的同样可靠性约束，也要求 网络安全协议 能够适配 工作负载与其底层机器解耦 的模型。一个例子是 Google 的应用层传输安全（ALTS）。SSL/TLS 的日益普及，以及对 持续存在的 DoS 风险 的应对需求，也要求在 加密计算 与 流量管理 上进行 专门的规划与工程投入。

要充分发挥 基础设施安全最佳实践 的效益，还需要 运营安全 方面的投入：入侵检测、内部人员风险、员工设备与凭证安全，以及诸如 安全软件开发规范 的建立与遵循，都需要 不小的投入。

随着 信息安全 真正成为 WSC 基础设施中的 一等公民，一些 历史行业惯例 正在被重新审视。例如，将关键基础设施委托给 不透明或黑盒 的第三方组件，对 WSC 来说可能极具挑战。在 彼此可能不互信的工作负载 之间，将机器恢复到已知可信状态——一直到固件层——正逐渐成为 必备能力。