参考文献

  • <<数据密集型应用系统设计>>

基础

可靠性/可扩展性/可维护性

  • 可靠性(Reliability): 当出现意外情况,如硬件/软件故障/人为失误,系统应可以继续正常运转;虽然性能可能有所降低,但确保功能正确.
  • 可扩展性(Scalability): 随着规模的增长,例如数据量/流量/复杂性,系统应以合理的方式来匹配这种增长.
  • 可维护性(Maintainability): 随着时间的推移,许多新的人员参与到系统开发和运维,以维护现有功能或适配新场景等,系统都应高效运转.
    • 可运维性
      • 方便运营团队来保持系统平稳运行.
    • 简单性
      • 简单系统复杂性,使新工程师能后轻松理解系统.注意这与用户界面的简单性并不一样.
    • 可演化性
      • 后续工程师那个轻松对系统进行改进,并根据需求变化将其适配到非典型场景,也称为可延伸性,易修改性或者可塑性.

延迟/响应时间

  • 延迟(latency): 延迟是请求花费在处理上的时间.
  • 响应时间(response time): 通常响应时间是客户端看到的,除了处理请求时间(服务时间,service time)外,还包括来回网络延迟和各种排队延迟.

描述性能

我们经常考察的服务请求的平均响应时间,(严格来说,术语"平均值"并没有明确采用何种具体公式,但通常被理解为算术平均值:给定n个值,将所有值相加,并除以n).然而,如果想知道更典型的响应时间,平均值并不是合适的指标,因为它掩盖了一些信息,无法告诉有多少用户实际经历了多少延迟.

因此最好使用百分数(percentiles). 如果已经次搜集到了响应时间信息,将其从最快到最慢排序,中位数(median)就是列表中建的响应时间.列如,如果中位数响应时间为200ms,那意味着有一半请求不到200ms,而另一半请求则需要更长的时间.

中位数指标非常合适描述多少用户等待多长时间: 一半的用户请求的服务时间少于中位数响应时间,另一半则多余中位数的时间.因此中位数也称为50百分位数,缩写为p50.需要注意的是,中位数对应单个请求,这也就意味着如果用户发了多个请求(例如包含一个完整会话过程中,或者因为某页面包含了多个资源),那么他们中至少一个比中位数慢的概率远远大于50%.

为了弄清楚异常有多糟糕,需要关注更大的百分位数如常见的的第95,99和99.9(缩写为p95,p99和p99.9)值.

可运维性: 运维更轻松

  • 运营团队对保持软件系统顺利运行至关重要.一个优秀的运营团队通常知至少负责以下内容:
    • 监视系统的健康状况,并在服务出现异常状态时快速恢复服务.
    • 追踪问题的原因,例如系统故障或性能下降.
    • 保持软件平和平台至最新状态,例如安全补丁方面.
    • 了解不同系统如何相互影响,避免执行带有破坏性的操作.
    • 预测未来可能的问题,并在问题发生之前及时解决(如容量规划).
    • 建立用于部署,配置管理等良好的实践规范和工具包.
    • 执行复杂的维护任务,例如将应用程序从一个平台迁移到另外一个平台.
    • 当配置更改时,维护系统的安全稳健.
    • 执行流程来规范操作行为,并保持生产环境稳定.
    • 保持相关知识的传承(如对系统理解),例如发生团队人员离职或者新员工加入等.
  • 良好的可操作性意味着使日常工作变得简单,使运营团队能够专注于高附加值的任务.数据系统设计可以在这方面贡献很多,包括:
    • 提供对系统运行时行为和内部的可观测性,方便监控.
    • 支持自动化,与标准工具集成.
    • 避免绑定特定的机器,这样在整个系统不间断运行的同时,允许机器停机维护.
    • 提供良好的文档和易于理解的操作模式,诸如"如果我做的了X,会发生Y".
    • 提供良好的默认配置,且允许管理员在需要时方便修改默认值.
    • 尝试自我修复,在需要时让管理员手动控制系统状态.
    • 行为可预测,减少意外发生.