DDIA 第一章 可靠性，可伸缩性和可维护性

DDIA 第一章 可靠性，可伸缩性和可维护性

现今很多应用程序都是 数据密集型（data-intensive） 的，而非 计算密集型（compute-intensive） 的。因此 CPU 很少成为这类应用的瓶颈，更大的问题通常来自数据量、数据复杂性、以及数据的变更速度。
数据库、消息队列、缓存等工具分属于几个差异显著的类别，为什么要把这些东西放在 数据系统（data system） 的总称之下混为一谈呢？
● 数据存储可以被当成消息队列用（Redis），消息队列则带有类似数据库的持久保证（Apache Kafka）。
● 越来越多的应用程序有着各种严格而广泛的要求，单个工具不足以满足所有的数据处理和存储需求。取而代之的是，总体工作被拆分成一系列能被单个工具高效完成的任务，并通过应用代码将它们缝合起来。

可靠性

应该设计容错机制以防因 故障 而导致 失效。

硬件故障

第一反应通常都是增加单个硬件的冗余度，磁盘可以组建 RAID，服务器可能有双路电源和热插拔 CPU，数据中心可能有电池和柴油发电机作为后备电源，某个组件挂掉时冗余组件可以立刻接管。

软件错误

比如：
● 接受特定的错误输入，便导致所有应用服务器实例崩溃的 BUG。例如 2012 年 6 月 30 日的闰秒，由于 Linux 内核中的一个错误【9】，许多应用同时挂掉了。
● 失控进程会用尽一些共享资源，包括 CPU 时间、内存、磁盘空间或网络带宽。
● 系统依赖的服务变慢，没有响应，或者开始返回错误的响应。
● 级联故障，一个组件中的小故障触发另一个组件中的故障，进而触发更多的故障【10】
办法：
仔细考虑系统中的假设和交互；彻底的测试；进程隔离；允许进程崩溃并重启；测量、监控并分析生产环境中的系统行为。

人为错误

一项关于大型互联网服务的研究发现，运维配置错误是导致服务中断的首要原因，而硬件故障（服务器或网络）仅导致了 10-25% 的服务中断。
● 以最小化犯错机会的方式设计系统。例如，精心设计的抽象、API 和管理后台使做对事情更容易。
● 将人们最容易犯错的地方与可能导致失效的地方 解耦（decouple）。特别是提供一个功能齐全的非生产环境 沙箱（sandbox），使人们可以在不影响真实用户的情况下，使用真实数据安全地探索和实验。
● 在各个层次进行彻底的测试，从单元测试、全系统集成测试到手动测试。
● 允许从人为错误中简单快速地恢复，以最大限度地减少失效情况带来的影响。 例如，快速回滚配置变更，分批发布新代码（以便任何意外错误只影响一小部分用户），并提供数据重算工具（以备旧的计算出错）。
● 配置详细和明确的监控，比如性能指标和错误率。当出现问题时，指标数据对于问题诊断是非常宝贵的。

可伸缩性

可伸缩性（Scalability） 是用来描述系统应对负载增长能力的术语。
以推特为例：
两个功能：
发布推文，用户可以向其粉丝发布新消息。
主页时间线，用户可以查阅他们关注的人发布的推文。
两种实现方式：
● 发布推文时，只需将新推文插入全局推文集合即可。当一个用户请求自己的主页时间线时，首先查找他关注的所有人，查询这些被关注用户发布的推文并按时间顺序合并。
● 为每个用户的主页时间线维护一个缓存，就像每个用户的推文收件箱（图 1-3）。 当一个用户发布推文时，查找所有关注该用户的人，并将新的推文插入到每个主页时间线缓存中。 因此读取主页时间线的请求开销很小，因为结果已经提前计算好了。缺点：发推需要大量额外工作。一些用户有超过 3000 万的粉丝，这意味着一条推文就可能会导致主页时间线缓存的 3000 万次写入。
在推特的例子中，每个用户粉丝数的分布（可能按这些用户的发推频率来加权）是探讨可伸缩性的一个关键负载参数。
推特现在已经稳健地实现了方法 2，推特逐步转向了两种方法的混合。大多数用户发的推文会被扇出写入其粉丝主页时间线缓存中。但是少数拥有海量粉丝的用户（即名流）会被排除在外。

应对负载的方法：

纵向伸缩（scaling up，也称为垂直伸缩，即 vertical scaling，转向更强大的机器）和 横向伸缩（scaling out，也称为水平伸缩，即 horizontal scaling，将负载分布到多台小机器上）。
可维护性
在设计之初就尽量考虑尽可能减少维护期间的痛苦，从而避免自己的软件系统变成遗留系统。为此，我们将特别关注软件系统的三个设计原则：
● 可操作性
● 简单性
● 可演化性

可操作性

运维团队对于保持软件系统顺利运行至关重要。一个优秀运维团队的典型职责如下（或者更多）【29】：
● 监控系统的运行状况，并在服务状态不佳时快速恢复服务。
● 跟踪问题的原因，例如系统故障或性能下降。
● 及时更新软件和平台，比如安全补丁。
● 了解系统间的相互作用，以便在异常变更造成损失前进行规避。
● 预测未来的问题，并在问题出现之前加以解决（例如，容量规划）。
● 建立部署、配置、管理方面的良好实践，编写相应工具。
● 执行复杂的维护任务，例如将应用程序从一个平台迁移到另一个平台。
● 当配置变更时，维持系统的安全性。
● 定义工作流程，使运维操作可预测，并保持生产环境稳定。
● 铁打的营盘流水的兵，维持组织对系统的了解。
良好的可操作性意味着更轻松的日常工作，进而运维团队能专注于高价值的事情。数据系统可以通过各种方式使日常任务更轻松：
● 通过良好的监控，提供对系统内部状态和运行时行为的 可见性（visibility）。
● 为自动化提供良好支持，将系统与标准化工具相集成。
● 避免依赖单台机器（在整个系统继续不间断运行的情况下允许机器停机维护）。
● 提供良好的文档和易于理解的操作模型（“如果做 X，会发生 Y”）。
● 提供良好的默认行为，但需要时也允许管理员自由覆盖默认值。
● 有条件时进行自我修复，但需要时也允许管理员手动控制系统状态。
● 行为可预测，最大限度减少意外。

简单性

用于消除 额外复杂度 的最好工具之一是 抽象（abstraction）。

可演化性

应用处于常态的变化中，例如：你了解了新的事实、出现意想不到的应用场景、业务优先级发生变化、用户要求新功能、新平台取代旧平台、法律或监管要求发生变化、系统增长迫使架构变化等。