一般地，对于软件系统的需求而言，分为两类：功能性需求和非功能性需求。软件系统的架构设计既要满足软件的功能性需求，还要满足软件的非功能性需求。特别地， 系统架构对软件非功能性需求的支撑成为架构的质量属性。本文描述了软件的10个质量属性， 但不意味着每个质量属性都会在架构设计中呈现，可以挑选对产品最重要的质量属性，然后进行实现。
1 可伸缩性
随着用户或请求数量的增加，系统运行和操作的能力也随之增加。在云平台上，可伸缩性可以通过机器的水平或垂直缩放或者简单地附加 AutoScalingGroup 来实现。
流量模式: 了解系统的交通模式。尽可能多地产生机器是不划算的，即使它的利用率不高。
日行模式: 特定地区的交通在早上增加，晚上减少。
全局/区域模式: 区域大量使用应用程序。
突发流量: 许多用户都在请求资源，但是只有少数几台机器可以为突发的流量提供服务。这些可能发生在高峰期或人口密集地区。
自动缩放: 能够迅速产生一些机器，以处理流量的爆发，当需求正在减少时，优雅地收缩。
延迟: 能够尽快为请求提供服务。这还包括优化算法和在用户位置附近复制系统，以减少请求的往返。
2 可用性
它以正常运行时间的百分比来衡量，并定义了系统正常运行和正常工作的时间比例。可用性受到系统错误、基础设施问题、恶意攻击和系统负载的影响。
部署标记: 部署应用程序组件的多个独立副本，包括数据存储区
区域部署: 将后端服务部署到一组地理节点中，每个节点都可以服务任何区域中的任何客户端请求。
3 可扩展性
可扩展性度量扩展了系统的能力和实现扩展所需的工作。扩展可以通过添加新功能或修改现有功能来实现，该原则规定在不损害当前系统功能的情况下进行增强。
模块化/可重用性: 可重用性和可扩展性使得技术可以以更少的开发和维护时间转移到另一个项目，同时增强了可靠性和一致性。
可插拔性: 能够轻松地插入其他组件，比如微内核架构。
4 一致性
一致性保证每个读操作返回最近的写操作。这意味着在执行每个操作之后，所有节点的数据都是一致的，因此，，无论它们连接到哪个节点，所有客户端都可以同时看到相同的数据。一致性提高了数据的新鲜程度。
5 弹性
系统可以从容地处理意外故障和恶意故障并进行恢复，检测故障并快速有效地恢复对于保持弹性是必要的。
可恢复性: 准备的过程和功能能够在发生意外更改后将服务返回到初始运行状态。意外的更改包括应用程序的软删除或硬删除或错误配置。灾难恢复包括了旨在防止或尽量减少灾难性事件造成的数据丢失和业务中断的最佳实践，涵盖了从设备故障和局部停电到网络攻击、民事紧急情况、犯罪或军事攻击以及自然灾害。
设计模式:
隔离: 将应用程序的元素隔离到池中，以便在一个池失败时，其他元素继续运行。
断路器: 当连接到远程服务或资源时，处理可能需要花费不同时间来修复的故障。
选举: 通过选举一个实例作为负责管理其他实例的领导者，协调分布式应用程序中协作任务实例集合执行的操作。
6 易用性
可用性可以描述为一个系统的能力，为其用户提供一个条件，以执行任务的安全有效，同时拥有良好的用户体验。它是指特定的消费者能够使用软件在量化的环境中以有效、高效和满意的方式实现量化目标的程度。
易访问性: 让具有最广泛特征和功能的人可以使用该软件。这包括失聪、失明、色盲等用户。
易学性: 用户学习如何使用软件有多容易？
API 契约: 对于内部团队，理解 API 契约有助于轻松接入任何系统。
7 可观测性
可观测性是收集关于程序执行、模块内部状态及组件间通信的数据的能力。为了提高可观测性，可以使用各种测试跟踪技术和工具。
日志记录: 在每个请求中生成不同类型的日志: 事件日志、事务日志、消息日志和服务器日志。
警报和监控: 准备监控仪表板，创建 SLI (服务水平指示器)并设置关键警报。
L1/L2/L3: 为 L1/L2设置随叫随到的支持流程。L1支持包括与客户交互，L2支持 L1路由到它们的工单，并帮助进行故障排除。L3是支持的最后一环，通常包括一个解决技术问题的开发团队。
8 安全性
软件保护信息和数据，使人或其他产品或系统有相应的数据访问类型和授权水平。这一系列特征包括机密性(数据只能被授权访问) ，完整性(软件防止未经授权访问或修改软件或信息) ，不可否认性(能否证明已经发生的行为或事件) ，问责性(能否追踪用户的行为)和真实性(验证用户的身份)。
可审核性: 审核并跟踪系统活动，以便在发生安全性缺陷时，可以确定缺陷的机制和程度。远程存储审计跟踪(可以防止入侵者掩盖其踪迹。
合法性:
遵守: 遵守 GDPR、 《个保法》等关于数据保护的法律法规。
隐私: 对公司内部员工隐藏事务的能力(加密的事务，甚至 DBA 和网络架构师也看不到它们)。
身份验证: 确保用户身份的安全性要求。
授权: 确保用户只能访问应用程序中的某些功能(通过用例、子系统、网页、业务规则、字段级别等)。
9 持久性
持久性是软件可服务性的解决能力，能够较长时间地满足用户的需求。
复制: 涉及共享信息，以确保冗余资源之间的一致性，从而提高可靠性、容错性或可访问性。
容错性: 容错性是一种特性，它使系统能够在某些组件出现一个或多个故障时继续正常运行。
可归档性: 数据是否需要在一段时间后归档或删除？(例如，客户数据将在三个月后被删除，或被标记为过时，并存档在备用数据库中，以便将来访问。)
10 敏捷性
敏捷已经成为当今描述当代软件方法的流行语，相关的敏捷团队可能是一个能够适应变化的团队。
可维护性: 应用更改和增强系统有多容易？表示开发人员可以修改软件以改进、纠正或使其适应环境和需求变化的有效性和效率程度。
可测试性: 开发人员和其他人员测试软件的容易程度
易于开发: 开发人员在不引入缺陷或降低现有产品质量的情况下修改软件的程度
可部署性: 在提交部署之后到代码投入生产的时间。
可安装性: 易于在所有必要的平台上安装系统。
可升级性: 在服务器和客户端上从此应用程序/解决方案的以前版本轻松/快速升级到较新版本的能力。
可移植性: 系统是否需要在多个平台上运行？(例如，前端是否需要针对 Oracle 和 SAP 运行？）
可配置性: 最终用户可以轻松地更改软件配置的各个方面(通过可用的接口)。
兼容性: 产品、系统或组件在共享相同的硬件或软件环境时，与其他产品、设计或成员交换信息并执行所需功能的程度。
小结
了解了软件架构中的10个质量属性，我们可能需要考虑哪一个质量属性更是适合自己的产品或项目。那么，如何在项目中继续采用这些特性呢？
一旦了解了功能性需求，尝试找出系统中可能给这些功能增加障碍的瓶颈。如何找到瓶颈呢？可以试着回答几个这样的问题:
系统能否在100M以上用户规模的基础上运行？
系统能处理10,000个并发请求吗？
是否以安全的方式处理数据？
是否可以在不影响现有工作特性的情况下轻松地添加更多特性？
......
更多的思考，更多的工具，更多的设计原则， 可以参考《持续架构实践》一书。
下面是上周直播的有关本书的2个视频。
往期推荐
今天，聊聊ChatGPT
2年云原生落地实践在运维和开发侧踩过的6个坑
王者荣耀为什么不使用微服务架构？
36个顶级数据分析方法与模型！
我是怎么读代码的
腾讯会议后台研发效能提升之路
阿里专家：万字长文详解技术管理者如何画业务大图？
软件开发人员如何提高个人和团队工作效率
基于“贫血”模型的传统开发模式是否违背 OOP
主数据系统的设计与实现
