介绍 reliability, scalability, 和 maintainability 的含义，以及实现它们的手段。

这里将最常见的数据处理需求列出来了：

A data-intensive application is typically built from standard building blocks that provide commonly needed functionality. For example, many applications need to:

• Store data so that they, or another application, can find it again later (databases)
• Remember the result of an expensive operation, to speed up reads (caches)
• Allow users to search data by keyword or filter it in various ways (search indexes)
• Send a message to another process, to be handled asynchronously (stream processing)
• Periodically crunch a large amount of accumulated data (batch processing)

不同的数据系统（主要指软件层面，如 MySQL、ElasticSearch 等）会有自己的特性，来满足上述一些场景的需求。

Thinking About Data Systems

背景：

Data system 分类的 边界模糊：

• Redis 即可以做 cache，也有人使用它做消息队列
• Apache Kafka 即是消息队列，也提供了类似数据库的持久化

一个工具往往不能满足全部业务需求，比如下面是一个可能的业务架构图：

这个系统是由一些通用组件构建出来的特殊系统，需要考虑：

• 如何保证缓存数据的一致性？
• 如何保证出错时数据保持正确和完整？
• 当部分组件不工作、系统降级时，如何仍然保持系统整体性能？
• 负载增加时如何扩容？
• 服务提供的 API 应该是怎样的？

问题：

如何判断使用怎样的系统？各个系统在设计上有什么共通点？

解答：

不同系统间一般有 3 个共同要考虑的点：

• 可靠性（Reliability）：即使出现异常情况，软件也能正常运行
• 可伸缩性（Scalability）：可以应对负载的增加
• 可维护性（Maintainability）：系统可以容易地进行变更来使其顺利运行，比如可以容易地打补丁、发布修复 bug 后的应用等

这一章下面的内容在阐述这几点具体的含义。

Reliability

定义：

「可靠性」，

• 简单地说：continuing to work correctly, even when things go wrong.
• 复杂地说：
  • The application performs the function that the user expected.
  • It can tolerate the user making mistakes or using the software in unexpected ways.
  • Its performance is good enough for the required use case, under the expected load and data volume.
  • The system prevents any unauthorized access and abuse.

错误相关的概念：

• Faults: things go wrong
• Cope with (certain kinds of) faults: fault-tolerant or resilient.

Faults v.s. failure:

• Faults 一般指单个组件的功能没有满足要求
• Failure 一般是系统整体出现错误，无法满足要求。如果没有做好错误处理，fault 可能会演变为 failure

Netflix Chaos Monkey: 有意地破坏系统中一些组件，产生 fault，以演习和测试整个系统的可靠性。

并不是全部 fault 都是可以被 tolerant 的，比如有安全漏洞导致数据库信息被黑客盗取。

下面描述各种不同类型的 fault。

Hardware Faults

现状：

硬件错误是非常常见的：机房断电、运维插错电缆造成网络配置错误、内存或者硬盘坏掉。一个硬盘平均 10-50 年会挂掉，如果像数据中心那样多的硬盘，几乎每天都会有硬盘挂掉。

解决方法：

Add redundancy（增加冗余）：硬盘上 Raid，机房多路供电，上 UPS。

但是……

并不是任何一种应用都需要强调单机的可用性。比如一个互联网应用的逻辑层 server，往往会有数十台甚至上千台机器，依赖于前端的负载均衡和高可用机制，一台机器挂掉了也有其他机器继续服务，影响并不大。比较依赖于单机可用性的，可能是一些关键的数据库服务等。

Software Error

关联性：

硬件错误往往不是相关联的，比如一台机器硬盘挂了，并不代表其他机器也会同时挂掉。但是软件错误往往是「系统性的」，比如 Linux Kernel 的一个 bug 可能会影响非常多的服务；一个服务可能返回了错误的信息给到上游，导致上游也出现异常。

潜伏性：

软件中的 bug 经常在于代码对它的运行环境有一些预设的认识。一般情况下环境的情况符合这个认识，但是一旦不符合了，bug 就会引起错误。

解决办法：

编程时多思考；详尽的测试；进程隔离；出错时 crash 并重启；监控及分析线上系统等。

Human Errors

现状：

人不可靠。事实上互联网中的服务不可用，绝大多数是来自运维操作或者配置出问题。硬件故障引起的问题只占很小一部分。

解决办法：

• 设计一个不容易犯错的系统。比如 API、管理界面上，把容易出错的部分抽象或者屏蔽掉，只留下容易理解的、好用的接口供用户操作。
• 提供机制，使用户即使犯了错也不会引起问题。比如提供沙箱环境，让开发可以拿线上数据做分析，但是又不会影响到用户环境
• 做仔细的测试，覆盖系统的各个层级；做自动化测试
• 提供快速恢复的机制；比如发布配置或者发布程序的平台，提供快速回滚的机制
• 建立详细且清晰的监控机制，使得出错时能快速定位问题
• 通过管理和培训的手段来减少误操作的发生

How Important Is Reliability?

通常都非常非常重要。如果是做原型，可以为了开发速度适当牺牲可靠性。

Scalability

指如何去应对负载（load）增加。

Describing Load

<<.s "问题："" >>

如果无法清晰描述 负载（load），那么也无法知道什么是负载增加，以及如何应对。

解决过程中引入的概念：

负载，一般拆分成多个 负载因素（load parameters）来描述，根据你的系统架构而有无不同，比如：

• requests per second to a web server
• the ratio of reads to writes in a database
• the number of simultaneously active users in a chat room
• the hit rate on a cache

Twitter 例子：

Twitter 的场景是读多（300k rps）写少（4.6k rps）。一般有两种方案：

1. 发推时写帐号自身的存储，读 timeline 时从关注的全部帐号中拉取帖子并进行合并和排序
2. 发推时写帐号自身的存储，同时更新到关注者的缓存中；这样读 timeline 时不用去拉关注的帐号的内容进行合并

在读多写少的场景下，第二种方案的性能事实上比第一种好。但是 Twitter 有个特点时，部分名人有些非常多的关注量（上百万甚至千万），用第二种时会导致名人发帖时要写入的数据非常多，无法及时送达到全部关注者。最终 Twitter 结合了这两种方案来解决这个问题。

在这个场景中，Twitter 的 关键负载因素，是用户的粉丝数分布（以及他们发推的频率）。你的系统根据自身的特点，也可能有它独特的负载因素。

Describing Performance

从实际问题出发……

• 如果把一个负载因素增加（比如请求量增长一倍），保持系统资源不变（如 CPU、带宽、机器数等），你的系统的性能会受到怎样的影响？
• 接上，如果你希望系统性能不变，需要增加多少资源？

应该如何描述性能？

不同类型的系统，用来描述性能的指标不一样。比如 Hadoop 类批处理系统（batch processing system），一般以 吞吐量（throughput，即单位时间内处理的纪录数）来衡量。线上系统则一般以 响应时间（response time）来衡量。

不同请求的响应时间各不一样。一般观察响应时间的 分布情况 来做判断：

一般来说各请求的处理时间都应该是一致的，但是一些因素会引起的额外的延时，导致各请求响应时间不一致。比如进程切换、TCP 丢包重传、GC 引起进程中断等等。

从分布情况中，一般考虑这些点：

• 使用 percentiles 来衡量大部分请求的时延情况，比如 p95（即最快的 95% 的请求落在什么范围内），以及 p99、p999 等；这个方法能得出绝大部分用户的情况
• 不考虑 使用平均数（mean / average），因为对于延时变化很大的场景，它并不能体现什么

有时候 p999 会显著大于 p95。High percentiles of response time，被称为 tail latencies。有些场景需要着重考虑 tail latency。比如亚马逊中，处理得最慢的请求往往是下单量很大的客户，他们的数据多导致了处理过慢。到了 p9999 时，优化最慢的请求往往已经变得性价比不高，因此对于 tail latency 的处理应该有合理的评估。

非核心内容

service level objectives (SLOs) 和 service level agreements (SLAs)，往往是以 percentiles 的形式描述的。比如 p50 的响应时间是 200ms，p99 的响应时间在 1s 内。服务的当机时间少于 0.1% 等等。

Head-of-line blocking（队头阻塞），是指后台程序在按顺序处理请求时，有部分请求执行时间过长，导致其后的请求在队列中等待了太长时间，从而引起整个系统性能降低的问题。

如果场景是用户需要发多个并行请求（比如动态加载内容的网页），并在全部请求都返回后才能处理（例如渲染出整个网页），那么最慢的请求会最终影响性能。这叫 tail latency amplification，放大了 tail latency 带来的影响。

Note

Latency（延时）与 response time 并不一样。Response time 是指客户端观察到的延时，包含了网络传输、请求在队列中等待被处理的时间等。Latency 则仅包含请求被程序实际执行的时间。

Approaches for Coping with Load

应对负载增加的方法

常见的两种说法：

• Scaling up: 换更好的硬件，让单台机器更强（Stack Overflow 在很长一段时间是 这样做 的）
• Scaling out: 堆更多的机器，是现在互联网服务常见的模式

有些系统是弹性的（elastic），可以根据负载变化自动扩缩机器。缺点是系统变复杂、可能应对不了一些异常的流量增长等。

无状态服务容易做 scaling out。有状态服务难。以前的惯常做法是，对数据库使用 scaling up 模式。但是未来 分布式数据库应该是标配。

Scaling Architecture 的考虑点

没有一个适配任何场景的 scaling architecture。考虑点有：数据存储的大小，读写数据的量，数据的复杂度，响应时间要求等等。比如一个 100,000 RPS，每次请求处理 1kB 数据的系统，与每分钟 3 次请求，每次处理 2GB 数据的系统，他们处理的数据量是一样的，但是架构完全不一样。

非核心内容

对于创业团队，如果想法未被市场验证，应该优先开发速度而不是架构设计。因为设计出来的 scaling architecture 可能跟后面业务的模式不匹配，导致无用功。

Maintainability

可维护性中的「维护」，包含了修复 bug、维护系统正常运转、增加新功能等等。考虑 Operability、Simplicity 及 Evolvability。

Operability: Making Life Easy for Operations

主要讲运维应该做什么事情来维护系统顺利运转。如监控、问题定位、打安全补丁、容量预估、运维工具开发、文档维护等等。

Simplicity: Managing Complexity

复杂的软件系统出 bug 机率高、维护成本高。

复杂的功能可以通过 抽象，使得软件实现上简单直观。

Evolvability: Making Change Easy

应对需求变化、外界环境变化、商业模式变化等等情况，你的系统需要是可随时进化的。这往往构建在 simplicity 的基础上。但是作者说这个很重要，要单独列出来。