第一章 可靠性、可扩展性、可维护性

数据系统

首先讲述了大多数应用都是数据密集型而非 计算密集型，更多的问题来自于 数据量、数据变更速度，列举一些通用组件

• 数据库系统：存储数据；
• 缓存系统：提升读取速度；
• 搜索索引：按照关键字搜索，以及过滤；
• 批处理：定期处理大量的数据
• 流处理：向其他进程发送消息，进行异步处理

这些系统都面临着以下这些共同的问题

可靠性

是指系统在困境中也可以正常工作，讲包括故障和失效

故障

指系统的一部分状态偏离其标准

• 硬件故障：磁盘可以提供 RAID；双路电源；热插拔 CPU 等等可以解决
• 软件故障：系统错误，特定输入引起的 BUG，依赖的服务不可用，响应变慢或者响应错误，级联故障；针对这些错误，作者说仍然有很多小办法，例如仔细考虑系统的假设和交互， 彻底的测试，进程隔离，监控分析生产系统的行为；那么在系统 运行期间就可以不断自检，在出现偏差时报警
• 人为错误：作者说人是不可靠的，但是我们可以精心设计 抽象，制定合理的 API；提供沙箱环境模拟真实场景，使用自动化测试覆盖边缘 case，快速回滚机制，详细的配置和明确的监控。这些可以检查系统哪些地方是否违反了假设和约束。

失效

系统作为一个整体停止向用户提供服务

容错性

防止故障后导致系统失效。作者提到可以故意制造错误（Chaos Monkey）来不断检验系统的容错机制；对于安全问题最好是提前预防；其他的常见容错方式有，压测，限流，降级，熔断都可以看做容错的一部分

可靠性的重要性，电商网站意味着声誉和亏损，其他的工业例如核电站、空中管制意味着灾难和法律风险；我们都有过软件响应慢、数据丢失而气急败坏的情况。我们是清楚的知道不可靠的影响，所以当我们偷工减料的时候应当清楚自己在做什么

可扩展性

• 描述负载

  作者用了一个推特的发布推文的例子，一个大 V 在发布一篇推文后，其众多粉丝都可以在自己的时间线主页看见大 V 的推文，所以应该是在大 V 发布推文后，将大 V 的推文推送并合并到其每个粉丝自己的时间线主页，这样在读多写少的场景下，写入的时候多做一些事情，读取的时候就会更容易写。

• 描述性能

  性能指标就是我们常见的吞吐量、延迟和响应时间、百分位点。百分位点是一个很重要的指标，一般公司会要求 99.99%，针对 0.01%请求的优化成本通常都很高，但是作者又提醒到，通常响应最慢的客户往往是数据最多的用户，也可以说是最有价值的用户，就看在成本和收益之间怎么取舍。

  排队延时：通常是响应时间长的很大一部分。描述的是由于服务器每次只能并行处理少量请求，剩下的请求就会在队列中排队等待，那么只要最开始的请求处理的很慢（这被称为头部阻塞），即使后面的请求处理的很快，客户端看到的总体响应时间也会是缓慢的。

• 应对负载的方法

  纵向扩展（垂直扩展）：更好的机器

  横向扩展（水平扩展）：无状态的服务扩展很简单。

  还有系统的弹性扩展，在负载高时，增加一些机器，负载低时，减少机器，负载有时很难预测，手动扩展的意外更少。

  但是将带状态的数据系统变为分布式的系统则会带来许多额外的复杂性，后面的章节则会着重讨论这些分布式系统的原理和模式。

可维护性

作者说软件的大部分开销都是在持续的维护阶段，漏洞修复，排查故障，修复失效，适配新的平台，扩展新的场景，偿还技术债等等。维护一个遗留系统会让人很不爽。我们可以做的就是在设计之初就尽量考虑维护期的痛苦，避免自己的系统成为一个遗留系统。

但是真的深思熟虑过可维护性吗，不，大部分情况下没有，临时堆砌的功能，开发时间的紧迫，没有单测，没有集成，没有文档，匆忙上线，期望稍后修复上述问题，然后又是下一个需求，下一个循环…

作者整理了如下三个设计原则：

• 可操作性

  Make it easy for operations teams to keep the system running smoothly。

• 简单性

  Make it easy for new engineers to understand the system, by removing as much
  complexity as possible from the system. (Note this is not the same as simplicity
  of the user interface.)

• 可演化性

  Make it easy for engineers to make changes to the system in the future, adapting
  it for unanticipated use cases as requirements change. Also known as extensibil‐
  ity, modifiability, or plasticity.

作者还补充了许多细节关于这三个设计原则达成所需要的职责，这里就不再啰嗦。

虽然目前这些问题没有简单的解决方案，但是作为工程师仍然要常常思考operability，simplicity，evolvability。

注

Gitbook中文翻译版 ：https://vonng.gitbooks.io/ddia-cn/content/preface.html
Github：https://github.com/hyhlinux/DDIA
英文版：链接:https://pan.baidu.com/s/1WsSrshLDuSuwmG60kpqdEg 密码:ipul
有能力的还是买下书吧，也不贵。