持续交付发布可靠软件的系统方法（部署流水线）第九章：非功能需求的
2018-11-25 本文已影响60人
潘晓华Michael
性能、吞吐量、容量概念
性能：对处理单一事务所花时间的一种度量，既可以单独衡量，也可以在一定的负载下衡量。
吞吐量：系统在一定时间内处理事务的数量，通常它受限于系统中的某个瓶颈
容量：一定的负载下，当每个单独请求的响应时间维持在可接受范围内时，系统所能承担的最大吞吐量。
非功能性：有效性、容量、安全性、可维护性等。
非功能需求管理
将非功能需求与功能需求一样对待。
- 创建一些具体任务来管理非功能需求
- 有必要的话，向功能需求中加入非功能需求的验收条件
如何为容量编程
- 为何要做容量测试
高德纳著名格言：
在97%的时间里，我们都应该忘记那种小的效率提升：过早优化是所有罪恶之根。然而，我们也不能让另外非常关键的3%的机会与我们擦肩而过。一个优秀程序员不会因为这个原则而对其置之不理，他们非常聪明，只会在识别出那段关键代码后，才会非常细心地去查看。
在找到解决方案之前，必须先找出问题的根源。容量测试会告诉我们是否存在问题，以便我们可以修复它。不要枉自猜测，而要先进行度量。 - 解决容量问题
现代软件系统中，最昂贵的是网络通信或磁盘存储，在性能和应用程序的稳定性方面，跨进程或网络边界的通信是昂贵的，所以这类通信应该尽量最小化。
让业务干系人决定系统的容量特性极其重要，以免方案过度设计 。
为解决容量问题，可采取的策略：
- 为应用程序决定一种架构。通常要特别注意进程、网络边界和I/O。
- 了解并使用正确的模式，避免使用那些影响系统容量和稳定性的反模式。
- 确保团队在已经明确的应用架构下进行开发，不要为容量做无谓的优化。在没有明确测试结果表明有容量问题时，坚决不能在代码可读性上让步。
- 注意在数据结构和算法方面的选择，确保它们的属性与应用程序相吻合。
- 处理线程时要特别注意。
- 创建一些自动化测试来断言所期望的容量级别。当这些测试失败时，用它们作为向导来修复这些问题。
- 使用调测工具主要关注测试中发现的问题，并修复它。
- 只要有可能，就使用真实的容量数据来做度量。
容量度量
- 扩展性测试：随着服务器数、服务等的增加，单个请求的响应时间和并发用户数的支持会如何变化。
- 持久性测试：长时间运行应用程序，是否有性能上的变化。
- 吞吐量测试：系统每秒能处理多少事务、消息或页面点击。
- 负载测试：当系统负载增加到类似生产环境大小时，系统的容量如何。
容量度量测试遵行有两种策略
- 把目标设定为得到稳定、可重现的结果。专为容量测试准备一个环境。
- 一旦某个测试通过了最低验收标准，就把验收标准提高一点，调整该测试的成功门槛
- 每个测试都必须体现一个具体的场景，并且只有达到某个标准门槛时，才能认为该测试通过
容量测试环境
- 容量测试环境与生产环境一致。
- 如果无法提供与生产环境相似的环境，可以把容量测试作为金丝雀发布策略的一部分来执行。更频繁的发布可以减小影响应用程序容量的修改所带来的风险
- 容量测试环境尽可能与生产环境相似。这样虽然无法满足容量目标，但是可以把那些严重的问题突显出来
- 不要依据硬件的某种特定参数对程序的扩展性作出线性推论
- 复制应用程序一小部分的服务器进行容量测试，是一个既可以降低环境成本又能提供适当准确度量的策略
自动化容量测试
- 一般我们都是把容量测试当作一项独立的工作，但是当容量非常重要时，那么就暂且忽视这些时间成本 。这时需要在部署流水线中加入容量测试阶段。
- 创建一个自动化容量测试套件，且每次对应用程序进行修改后，通过了提交测试和验收测试就应该执行容量测试。
- 容量测试要达到如下6个目标
- 测试具体的现实场景
- 预先设定成功的门槛
- 尽可能让测试运行时间短一些
- 在变更面前要更健壮一些
- 组合成大规模的复杂场景
- 可重复的，并且既能串行执行，也能并行执行
容量测试系统的附加价值
容量测试系统是一个试验场所，可以根据需要有效地控制时间，设计和执行所有的试验场景来帮助诊断问题、预测问题并找到触发问题办法。
- 重现生产环境中发现的复杂缺陷
- 探测并调试内存泄漏
- 持久性测试
- 评估垃圾回收的影响
- 垃圾回收的调优
- 应用程序参数的调优
- 第三方应用程序配置的调优，如操作系统
- 模拟非正常、最糟糕的情况
- 评估一些复杂问题的不同解决方案
- 模拟集成失败的情况
- 度量应用程序在不同硬件配置下的可扩展性
- 与外部系统进行交互的负载测试
- 复杂部署的回滚演练
- 有选择地使系统部分或全部瘫痪，从而评估服务优雅降级
- 在短期可用的生产硬件上执行真实世界的容量基准，以便计算出长期且低配的容量测试环境中更准确的扩展因素。
