读书笔记-数据密集型应用系统设计
参考文献
- <<数据密集型应用系统设计>>
基础
可靠性/可扩展性/可维护性
- 可靠性(
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".
- 提供良好的默认配置,且允许管理员在需要时方便修改默认值.
- 尝试自我修复,在需要时让管理员手动控制系统状态.
- 行为可预测,减少意外发生.
本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 HoleLin's Blog!