需求分析引言：架构漫谈（二）非功能性需求

上一篇文章，简要介绍了架构的概念和架构设计流程，并简单介绍了需求分析的内容，
并在最后指出：需求分析的产出物，要包括非功能性需求，常见的非功能性需求如下：

• 完成任务的速度
• 结果的精度
• 操作的安全性
• 产品的容量
• 允许的值的范围
• 吞吐量，例如tps
• 资源使用的效率
• 可靠性
• 容错能力和健壮性
• 伸缩性
• 可扩展性

红色部分是常见项目的重点关注点（注：根据项目背景不同而不同，比如安全产品最重要的是安全性）。
对一个项目而言，更高的非功能性要求，代表着更高的系统复杂度、更高的成本投入（时间成本、人力成本、硬件及维护成本），需要根据公司/项目/人力/环境等背景因素综合评估。

非功能性需求

需求分析后输出的非功能性需求，必须可量化，基本要求：

• 非功能性需求必须无二义性，可理解，可测试。
• 标准先行，否则设计、实现或测试将没有依据。
• 所有需求都可测量，测量的尺度是用于测试产品符合程度的单位。

作为架构设计人员，对非功能性需求，要关注的最重要的点：不能度量的需求不是真需求

• 度量的定义如下：
  • 指在软件开发过程中，通过数据收集和数据分析，来评估软件质量和性能的过程。
    这个过程可以帮助开发团队了解软件的现状，开发的进展，发现潜在的问题和风险，并对软件进行定量的评估，及制定改进措施。

无效的非功能性需求举例：

• 必须支持高并发：系统希望能随1000用户并发，还是10000用户并发？
• 接口响应要尽可能快：可接受的响应时间100毫秒？200毫秒？还是1秒？有5%的用户超过1秒能不能接受？

下面逐一介绍一下这些非功能性需求的概念，以及部分度量指标，在做架构设计应该评估和采集这些指标，以评估当前系统情况，及未来的优化方向。

1、完成任务的速度

• 解释：
  即性能/效率，通常是指软件的“时间/空间”效率，而不仅是指软件的运行速度。
• 度量指标：
  • 响应时间(平均时间/最大时间/95分位时间)
  • CPU使用率
  • 缓存命中率
  • IO次数/IO时长（磁盘IO/网络IO）
  • 最大连接数/并发数
• 示例：
  用户单次操作的最大响应时间不得高于2秒；
  产品必须每10秒读取一次传感器的值；
  系统应该在0.25秒内识别出一架飞机是敌人还是友军；
  云端配置更新后，产品必须在1分钟内更新到最新配置并完成刷新。
• 数据举例：
  一个2.5GHz的CPU，每个CPU时钟周期是0.4纳秒，
  假设每个CPU时钟周期为1秒，常见的计算机耗时及相对1秒时钟周期耗时的对比数据如下：
  
  对比的结果还是挺触目惊心的吧，哈哈。
• 内存是千兆网速的200倍，所以能用内存缓存时，就不要考虑Redis了；
• 上下文切换也很耗费CPU性能，所以IO不多的任务，就不要考虑多线程了；
• 尽快更换SSD硬盘吧；
• 做了跨数据中心高可用时，尽量保证每个中心都有整套服务，确保同一个数据中心内互访。

2、结果的精度

• 解释：
  通常指软件输出的结果（例如计算结果、测量结果、数据分析结果等）的精度要求。
• 度量指标：
  其衡量标准是输出值与真实值之间的误差大小。
• 说明：
  结果的精度在多数系统内一般不会特别体现出来，但是在一些行业内，精度是特别重要的指标：
  • 银行系统：虽然银行给用户的利息是精确到分，但是内部的计算，必须至少精确到厘，甚至更高的精度，才能保证数据汇总正确；
  • 自动驾驶系统：自动驾驶系统对精度的重要性显然是极高的，障碍物与车的距离判断准确与否，避免重影等非障碍物误判等。
    通常精度用范围区间指示，如 ±1厘米
• 注：
  所有涉及金额的存储和计算，都建议采用整数存储，例如普通人民币计算，写入DB时，用分为单位写入；
  上面说到的利率计算，可以用厘为单位写入DB及内存计算，以避免二进制问题带来的小数精度问题。

3、操作的安全性

• 解释：
  指保护系统免受意外访问、破坏和误用的能力。包括：认证和授权、访问控制、数据保护、通信安全、安全日志、定期审计等。
  主要通过方案评审和测试用例进行确认，如：
  密码复杂度、两步验证的算法安全性、角色权限和访问控制策略等、数据加密保护方案评估、备份频率和完整性、灾备方案、通信加密强度、审计日志的完整性和保密性、安全审计的频率和深度
• 备注：
  • 加密的强度应当充分考虑，例如常规的MD5加盐已经不够安全了，比较好的作法是：MD5( MD5(明文+用户特定盐值1) + 用户特定盐值2）
  • 涉及金额的数据写入DB时，应当增加一个校验字段，根据该行的所有字段进行Hash加盐后计算获得，
    使用时，需要校验该字段，如果不匹配应当禁止该笔交易，避免内部员工篡改数据；
  • 安全性要求高的系统，应部署独立的加解密服务，传入用户ID + 源数据，该服务根据用户ID获取特定密钥加密，返回加密后的数据；
  • 所有敏感数据查看/操作，均应二次验证身份；所有数据导出，均应脱敏处理；
  • 高安全性要求的产品线，应当跟其它产品线网络隔离，避免通过其它产品漏洞，从内网攻击本产品。

4、产品的容量

• 解释：
  通常是指软件在一定时间内的数据容量要求。
• 度量指标：
  根据软件要求输出，如已注册用户数；已存储文件大小
• 示例：
  一个月内系统能支持到1万注册用户，一年内能支撑达到10万注册用户；
  一个月内S3存储能支持10万文件/100GB，一年内能支撑达到10亿文件/5PB。

5、允许的值的范围

• 解释：
  软件系统在使用过程中，对一些输入数据的范围限制。
• 示例：
  用户姓名的最大长度
  交易金额的最小值和最大值，比如餐厅的菜品单价不允许超过1万元

6、吞吐量

• 解释：
  通常是指软件在单位时间内传输数据的数量。
• 度量指标：
  • TPS：Transactions Per Second（每秒传输的事物处理个数）
  • QPS：Queries Per Second（每秒查询次数）
    可以理解为服务器收到一次请求，就增加一次QPS。
    假设打开网站首页，向服务器发起了3个请求：首页、登录状态、新闻列表，
    此时TPS加1，QPS加3
  • RT：Response Time（每次请求的响应时间）
  • 并发数：系统同时处理的请求数
    比如某个服务收到了100个请求，都还在处理中没有响应，则此时并发就是100
    很多文章说 并发数 = QPS * 平均响应时间，这其实是不准确的，这是2个不同的性能指标，
    确实：并发越高，可能会导致响应时间变长，QPS也确实会相应变小，
    但是这些性能指标，都跟服务器状态、网络状态、磁盘等的影响，并不能直接互相转换。
• 示例：
  支付系统TPS达到4000以上
  商城系统TPS达到2000以上, QPS达到10000以上
  营销系统并发数达到10000以上
  订单系统API的RT在100ms以内

7、资源使用的效率

• 解释：
  通常指定特定硬件组件上的使用量、占用率、释放情况，如需要4核以上CPU、16G以上内存；需要千兆带宽。
• 度量指标：
  • CPU占用时长
  • 内存使用量
  • 磁盘占用空间
  • IO均值、峰值、总传输数据量等
  • TPS单位时间内能处理完
• 说明：
  通过良好的架构设计、较优的算法实现可以优化资源使用效率。
  特殊场景无法横向扩容机器时，可以通过简单的单机硬件配置提升来优化。

8、可靠性

• 解释：
  指的是产品在规定的时间内，在规定的条件下，完成预定功能的能力。
• 度量指标：
  • MTBF——全称是Mean Time Between Failure，即平均故障间隔时间。
  • MTTR——全称是Mean Time To Repair，即平均故障恢复时间。
  • MTTF——全称是Mean Time To Failure，即平均无故障时间。
  • 可用性Availability=UpTime/(UpTime+DownTime)=MTBF / (MTBF + MTTR)
• 示例：
  服务平均无故障时间占比应该高于99.9%， 5分钟内请求错误率高于1%即判定为故障。
• 注：
  • 有些文章说MTBF = MTTF + MTTR，
    我的理解，MTBF是平均故障间隔时间，指系统正常运行的平均时间，不应该包含MTTR。
  • MTTF是指系统平均能够正常运行多长时间，才发生一次故障。系统的可靠性越高，平均无故障时间越长。
    后续我再会专题写一篇文章，介绍可靠性和可用性。

9、容错能力和健壮性

• 解释：
  指系统在面对错误和异常情况时的处理能力和稳定性。
• 度量指标：
  通常通过开发规范约束、代码检测质量、设计评审来衡量；
  以及系统崩溃次数、错误日志统计等数据评估
• 示例：
  用户输入任意数据，系统均能正常处理或提示错误，不会崩溃或产生错误响应，生成错误数据。
  系统出现崩溃时，能记录异常信息，以供问题排查，并能有效响应用户（服务降级）

10、伸缩性

• 解释：
  不改变系统的情况下，通过简单升降配置/增减服务器来调整系统处理业务的能力。
• 度量指标：
  • 响应时间：用户数增长/请求数增加，响应时间是否随之增加
  • 错误响应数：用户数增长/请求数增加，错误响应是否随之增加，如超时，网络错误，限流错误等
• 示例：
  在访问量平滑增长的情况下，能自动扩容达到服务可用性不受影响；
  在访问量下降的情况下，能自动缩容以降低成本，且服务可用性不受影响；

11、可扩展性

• 解释：
  新增产品或需求时，实现对现有产品无影响，透明上线新产品的能力。
• 示例：
  系统支持蓝绿发布、滚动发布、灰度发布。

参考知识

对于非功能性需求，已经有不少的业界标准可供学习和参考，提供了更多的非功能性需求和说明，如：

• Jim McCall 软件质量模型（1977 年）

• Barry W. Boehm 软件质量模型（1978 年）

• FURPS/FURPS+ 软件质量模型

• R. Geoff Dromey 软件质量模型

• ISO/IEC 9126 软件质量模型（1993 年）

• ISO/IEC 25010 软件质量模型（2011 年）

下面介绍2个目前比较常用的软件质量模型，建议认真阅读理解一下：

软件质量模型 ISO/IEC 25010

由ISO(国际标准化组织) 和 IEC(国际电工委员会) 联合制订的软件质量标准，替代 ISO/IEC 9126标准；
详细介绍参考： https://iso25000.com/index.php/en/iso-25000-standards/iso-25010

软件质量模型 FURPS/+

FURPS 模型最早是由惠普公司的罗伯特·格雷迪（Robert Grady）及卡斯威尔（Caswell）提出，后来由 Rational Software 进行扩展至 FURPS+。
详细介绍可以参考：https://sceweb.uhcl.edu/helm/RationalUnifiedProcess/process/workflow/requirem/co_req.htm

结语

上面简单介绍了一些非功能性需求和相关指标，后面两篇文章，会对软件系统比较关注的可用性 和 性能优化进行介绍。