在1.7软件架构里，我们看到一个物联网的网关软件架构例子，未考虑到质量属性时候比较简单，软件每一处都是完成必要的物联网设备连接功能。考虑到高可用，高性能以及可修改等特性，架构做了调整，从分层架构变成消息驱动架构，引入Kafka消息中间件同其他系统交互，内部也引入了多个线程池解耦各种业务处理。同时还引入了脚本引擎，热部署方案等等。

一般来说，一个系统的质量属性要求往往决定了系统的架构以及实现成本。比如要求查询性能从1秒提高到100毫秒，可能意味着架构模式，部署方式，购买基础设施变化，意味着依赖的数据库做了调整，比如数据库模型变化和索引调整，或者引入NOSQL。 质量属性变化对架构的要求是质的变化，成本是非线性增长的。这不同于系统的功能变化，比如从1个功能增加到10个功能，这个需求引来的是线性变化，风险和成本是可控的。

这种质量变化引起架构变化，导致成本非线性增长，不仅仅在软件行业，在其他行业都是类似的。

以战斗机设计举例子来说，其质量要求是更快， 比如从1马赫到2马赫，并不意味着设计更大的发动机便能线性实现飞机更快的速度，实际上改进措施有飞机整体外形的变化，架构上叠加发动机个数而不是增加发动机功率（马斯克重型火箭采用类似架构）。至于更加隐身的质量目标，像歼20是第5代战斗机，隐身面积是0.001平米，如果想达到0.0001平米，即歼36的飞机隐身目标，飞机架构为此做了很大的改变！不是简单的研发更好的隐身涂层，现在的方案是去掉垂尾，更加扁平化，使用新的机身材料来实现全向隐身。

以体育运动为例子，奥运会的口号之一是“更快、更高、更强”，如何做到更快呢，如何让跨栏成绩提高200毫秒，，刘翔把跨栏从传统的8步上栏改成7步上栏（现在已经普遍采用7步上栏），取得了突破的好成绩。这种上栏方法，我训练体系方方面面发生了很大变化。

以个人的学习为例子，想解题更快更正确，花时间训练是个办法，会随着努力有线性的回报。 但总会遇到瓶颈，比如针对那种压轴题或者竞赛题解答，需要新的训练方法和训练思路，优秀学生的天赋，实际上是有更好的的解题思路（架构）

因此，在架构软件系统时候，软件架构师应该首要关注其质量属性，需要意识到质量属性与架构密切相关。尤其是高可用，高性能，可恢复，可修改等常见属性。忽略质量属性建设的软件系统是不合格的系统， 在1.7架构师职责一节，我提到了“故事一”是忽略质量属性导致的问题。据我所知，这个问题因为解决需要较大的成本，至今未解决，如果在系统创建初就意识到有这个质量需求，就很好解决了。

对于架构师来说，关于质量属性有俩个实际问题需要解决

1. 如何获得系统的质量属性？
2. 如何根据质量属性去设计或者调整软件架构

下表总结了获得质量属性的途径

来源	质量属性要求举例子
企业战略	如增加多少用户，增加多少加盟店等等。如降本增效情况下，在硬件资源不增加或者减少情况下，承载更多业务量。
业务需求	业务需求书里的非功能需求项。需要注意，很多业务架构不太重视非功能需求，软件架构师可以主动协助完善
招标书	通常甲方招标书上列出了系统性能，安全，故障可恢复等质量属性要求
系统的特性	金融，电信要求系统高可靠,高性能，安全，故障可恢复。电商要求高可用，高性能，故障可恢复
服务调用者	服务调用者希望TP95提高30ms，或者每日超过1秒调用不超过100条
服务提供者	服务提供者希望减少调用次数，或者请求调用量平滑。比如服务提供者希望调用者不要定时到早上6点调用，会有大量高并发操作，而希望分布到6点左右
特定节日	如电商大促，逢年过节的12306. 质量属性要求不同于平时
日常运维反馈	通过系统可观系统，指标数据显示需要提升的指标数据，如服务高可用性提升，服务接口性能提升。通过系统的各种告警，找到需要提升的系统质量
每次项目故障后的复盘	当系统出现故障后，复盘过程中总结出是否需要提升的质量属性
基于风险驱动的设计	当软件架构师深情的望着软件架构，应用架构和部署架构图时候，他应该是个悲观者，列出架构中的各种风险和解决办法。从而提升系统质量，比如，如果云厂商的Redis升配时间超过预期，会发生什么，应该怎么处理；如果上游系统出现故障会怎么办，如果迟迟不能恢复该怎么解决。
指标数据日报&周报	可观测性系统会定期把每日&每周系统的各项指标发给团队，团队依据此得到需要改善的质量属性

系统的质量属性实现并不是一蹴而就。同业务需求一样，需要依据优先级和实现风险 迭代完成，如下是一个服务系统的质量属性表（参考软件架构一节）

需求和背景	所属质量属性	优先级	风险	实现方案	观测指标
单节点1万设备接入网络时间提高到10秒全部要接入	性能	低	高	1 SSL使用OpenSSL2 设备接入后，减少上报内容	可观测系统能统计单位时间设备接入的数率。
Jedis升级到3.9，以避免重试写失败	高可用	低	低	升级3.9，客户端默认的重试间隔指数退避，能在链接恢复情况下重连成功	可观测性系统中，失败访问redis次数降低。
接入网关的SSL证书可以动态更新，而不需要手工COPY新证书并重启系统	高可用	低	低	1）SSL证书维护在专门的服务2） 接入网关定期更新证书	1 系统重启次数Event减少2 设备掉线率降低3 重启后导致CPU峰值次数减少
接入网关的任务处理类可以修改实现而不需要重启系统	可修改性	高	高	使用ClassLoader方案，加载修改的Task类	1 系统重启次数Event减少2 设备掉线率降低3 重启后导致CPU峰值次数减少

需要注意的是，质量需求并不是业务需求的一部分，这些质量需求如果不完成，可能最后逐渐变成技术债务。通常做法是混合业务需求和质量需求，与业务，测试和运维达成共识，迭代开发完成。

有了质量需求后，如何实现质量需求，主要有俩个办法

• 选择软件架构风格，软件架构风格包含了质量属性，如消息驱动架构，可以提高性能，高可用，可修改特性。而管道和过滤器模式，则提高了灵活性。微服务架构则提供更多的质量属性，是现代系统一种理想的架构。在软件架构一节中，就使用了消息驱动架构风格代替分层架构提高了网关系统的质量属性。
• 选择质量属性对应的战术方法，比如当想提高系高可用时候，会有一系列战术方法，下图是高可用战术列表。本书第三章将介绍高可用，高性能，可修改这三种常用的质量属性的实现战术办法。第四章后将介绍Java实现细节。

再次强调，软件架构师，应该是软件架构和质量双驱动构建系统。如果阅读完本书，你能记得这一点，并从本书的架构模式列表或者质量战术列表中选择若果战术来提高系统的质量，本书就没有白阅读。