成为架构师课程系列系统架构设计：非功能性目标的设计

Posted 2023-03-07 禅与计算机程序设计艺术

前言

为了提高综合客户满意度及不同质量属性的满意度，必须考虑计划和设计产品时的不同质量属性。

 -- Stephen H.Kan，《软件质量工程》

质量属性很难定义，但它们经常可以区分产品是只完成了其应该完成的任务呢，还是使客户感到满意。......优秀的软件产品反映了这些竞争性质量属性的优化平衡。

 -- Karl E.Wiegers, 《软件需求(第二版)》

软件行业发展到今天，依然比较年轻。一个有趣的印证就是我们经常拿自己的行业和其他行业类比 -- 今天类比建筑行业，明天类比汽车行业，后台类比拍电影。

我并不能确定把架构师和哪个职业相类比最适合，但或许，架构师最嫉妒的职业是拳击。人家的目标永远正确：打到对方。而架构师，却要面对纠结在一起的“需求”--需求不是一个攻击目标，而是一堆攻击目标，而是一堆可能不够明确、相互矛盾的目标。昨天、今天、甚至明天，都会有相同的故事在上演：笼统界定的“非功能目标”让软件工程师深感困惑......

这就是现状。

在这种状态之下，架构师不应“坐等”明确的需求，而是应该运用目标-场景-决策表等方法主动出击，设计成更有针对性的架构。

作为决策者，架构师的工作影响着项目的成败，乃至公司的发展。我们须谨记：千万不要做“四拍”型的决策者。

• 决策时拍脑袋--就这么定了

• 指挥时拍胸脯--保证没问题

• 失误时拍大腿--我怎么没想到

• 追查时拍屁股--老子不干了

架构设计实践中，面对非功能需求目标时是最容易犯“拍脑袋”这个经典错误的。接下来介绍非功能目标的设计思维及其实践要领。

故事：困扰已久的非功能问题

非功能需求的满足程度对软件项目的成功非常关键......非功能需求分为质量属性和约束两大类。质量属性是软件系统的整体质量品质--所谓整体品质，就是往往和大多数功能都有关，而不是仅仅表现在某个功能“内部”。志宇约束性需求，它们是架构设计中必须遵循的限制，并有可能“衍生”出质量属性需求和功能需求。-- 温昱，《软件架构设计》

那么非功能需求方面常见的问题是什么呢？......很多《需求规格说明书》中，会通过一个名为“设计原则”的小节来说明非功能需求，列出诸如高可靠性、高可用性、高扩展性等要求。但是很多开发人员根本不去看它，因为这样的定性描述是没有判断标准的，因此这种信息传递是无效的。-- 徐峰， 《软件需求最佳实践》

软件架构设计为什么这么难？因为架构设计并不是简单的处理“纯粹的技术问题”，而是要面对“技术与业务的关系问题”。最终，要求架构师不仅懂业务，而且能理顺复杂的技术和业务之间的关系。

从面向业务的需求，到最终的面向技术的软件系统，要跨很大的鸿沟。软件架构设计就是要完成从面向业务到面向技术的转换，在鸿沟上架起一座桥梁。软件架构师根据各种需求进行架构设计，最终的软件架构包含了结构、协作、技术等方面的重要决策，为系统化的开发活动建立了基础。

接下来，请大家思考如下几个问题：

• 架构师是否应该懂需求？

• 功能需求、非功能需求都要懂吗？

• 生搬硬套需求标准是“懂需求”的应有表现吗？

• 应对如何传达非功能目标的具体需求？

探究：架构师必须懂需求

其实，除非特别简单的系统，否则架构师不能“吃透”需求，必然造成最终的系统无法很好的满足需求。但业界普遍存在的现实是：许多架构师的需求功底太差，输在架构设计的“起跑线”上。当然，架构师也是一大堆“苦衷”：

架构师不能“吃透”需求，的确出人意料。但是既然大部分企业为架构师安排了“技术晋升路线”，既然许多架构师也把自己当“纯粹的技术人员”，既然架构师必须研究“时髦技术”否则就被程序员看不起，既然设计模式和UML还在“排队”，需求吗就算了，那么架构师不能“吃透”需求，也就在情理之中了。

调侃归调侃（其实不无道理），但笔者一致认为：精通需求，是对架构师最基本的要求之一，不了解需求是现在许多架构师职业发展道路上的瓶颈。

值得强调的是，需求分析师和架构师这两个角色要掌握的需求知识并不完全一样。经典的观点是认为架构师应掌握的需求知识是需求分析师的一个子集，其实不然：

• 例如，之前所讲的“不同需求影响架构的不同原理”，需求分析师可以不去研究。

• 再例如，《软件工程的事实与缪误》中指出：“ 从需求转入设计时，因为制定方案过程的复杂性，会激增出大量的衍生需求（针对一种特定设计方案的需求）。设计需求是原始需求的50倍之多。”

总之，架构师必须懂需求。虽然无须研究诸如需求捕获等技术，但需求类型、需求影响架构的原理、质量属性间的互相影响关系都是必须精通的。

非功能目标的设计环节简介

在我们当中，有不少人一厢情愿的任务：只要所开发的系统完成了用户期待的功能，项目就算成功了，但这不并不符合实际，忽视包括质量属性需求在内的非功能需求是很要命的。

为什么不少软件产品推出不久就要重新设计（美其名曰“架构重构”）？往往不是因为系统“不能用”，而是由于系统架构“太拙劣”--从难以维护、运行速度太慢 、稳定性差，甚至宕机频繁，到无法进行功能扩展、易遭受安全攻击等，不一而足。由此看来，软件的质量属性需求是不容忽视的，否则在大量的成本投入之后，很可能落得“失败”或“赔钱”的结果。

然而，软件的质量属性需求很“飘”，常常令架构师难以把握。如果缺乏足够的方法指导，即使勉强制定了设计决策也会觉得缺乏信心。

所以，解决问题的要害在于：如何使很“飘”的非功能目标“明确定义下来”。分析如下：

• 需求决定架构，架构设计的成果已属于解决方案的范畴

• 架构设计的过程是从“需求域”向“设计域”过度的过程

• 目标很飘，就意味着根据诸如“高性能”等非功能需求直接作出“设计决策”跨度过大了

• 需要一种“过度技术”来承上启下，它能笼统的非功能目标明确化，它能帮助架构师做出更有针对性的设计决策

它就是场景技术。

一句话，非功能目标的设计是以场景技术为核心手段、以目标-场景-决策表为思维工具，致力于支撑非功能目标的理性设计过程。

实际意义

作为架构师，有了非功能目标设计环节相关方法的指导，将获得如下几点优势：

• 设计更有针对性

设计贵在务实，贵在有针对性。试想，如果世界上没有“高性能”这个高度简练、高度抽象的词，用户会怎么描述描述他的非功能要求？他一定会说一大堆“如果......则需要......”式的场景出来！

所以，将一个目标明确为N个场景，是一种回归本源的做法，可以使架构师的设计更加有针对性、更加有效。

• 可操作性强

懂得了以场景为核心的非功能目标设计思维，架构师就知道“力往哪儿使”了。他们通过研究开发、维护、使用、变更等环境可能遇到的具体情况，不断发现场景，评估场景，做出决策......这是一个可操作性很强的思维实践过程。

其实所谓方法，就是帮着你将经验更系统的、更充分的使用起来的思维框架。所以，对有经验的架构师而言，他们的思维更有序、经验的应用更有理有据、面对更大的系统时信息更足。

当前，很大程度上，确定支持非功能目标的设计决策的过程是“只可意会”的。例如阅读《架构设计文档》时很难搞清楚“为什么”，这给架构新手的成长造成了莫大的障碍。而现在，非功能目标的设计思维明确化了、可视化了、可操作化了，有利于架构新手学习、理解和掌握。

• 避免过度设计

单凭经验为高质量属性而设计很容易造成过度设计，即引入的很多抽象和机制是不必要的，平白增加了设计复杂性。以“目标-场景-决策”表为工作的非功能目标设计方法将场景视为“一等公民”，使架构师很容易对非功能场景进行评估，通过权衡场景发生的几率、支持场景带来的价值、遗漏场景的代价等因素，来理性决定是否应支持该场景。

• 便于系统升级时参考

当系统架构不能适应新要求时，往往要对架构进行重构，此时软件架构师常犯的毛病是过于强调系统架构的缺点，而将过去的架构设计全盘否定，这样可能造成设计出的新架构的解决了新问题的同时也失去了已有的优点。而如果将“目标-场景-决策”表文档化，则有利于避免上述问题。

实践要领

场景思维

非功能需求支持是否到位，关键是靠场景思维的应用。归纳了场景思维在非功能目标设计中的重要性。

纵穿环节

有著名厂商任务，架构设计的“第几步”应该是非功能考虑，这种观点是危险的。

非功能需求不可能是“速决战”，它必然是“持久战”，连编码都会影响到性能动能非功能属性，更何况概念架构设计和细化架构设计呢？所以架构师必须注意，非功能目标的考虑是纵穿架构师设计始终的环节。

附录： 架构设计原则

【更多阅读】
【编程实践】Linux Shell 编程：使用 循环和递归 实现斐波那契数列代码

【编程实践】Linux / UNIX Shell编程极简教程

【编程语言】Scala 函数式编程

【编程实践】SQLite 极简教程

【编程实践】Google Guava 极简教程

【编程语言】AWK 极简教程

Bito AI：免费使用 ChatGPT 编写代码/修复错误/创建测试用例Use ChatGPT to 10x dev work

写代码犹如写文章: “大师级程序员把系统当故事来讲，而不是当做程序来写” |  如何架构设计复杂业务系统? 如何写复杂业务代码？

【工作10年+的大厂资深架构师万字长文总结 精华收藏！】怎样设计高可用、高性能系统？关于高可用高性能系统架构和设计理论和经验总结
【企业架构设计实战】0 企业数字化转型和升级：架构设计方法与实践  
【企业架构设计实战】1 企业架构方法论
【企业架构设计实战】2 业务架构设计
【企业架构设计实战】3 怎样进行系统逻辑架构？
【企业架构设计实战】4 应用架构设计
【企业架构设计实战】5 大数据架构设计
【企业架构设计实战】6 数据架构

企业数字化转型和升级：架构设计方法与实践
【成为架构师课程系列】怎样进行系统逻辑架构？
【成为架构师课程系列】怎样进行系统详细架构设计？
【企业架构设计实战】企业架构方法论
【企业架构设计实战】业务架构设计【企业架构设计实战】应用架构设计【企业架构设计实战】大数据架构设计【软件架构思想系列】分层架构【软件架构思想系列】模块化与抽象软件架构设计的核心：抽象与模型、“战略编程”企业级大数据架构设计最佳实践编程语言：类型系统的本质程序员架构修炼之道：软件架构设计的37个一般性原则程序员架构修炼之道：如何设计“易理解”的系统架构？“封号斗罗” 程序员修炼之道：通向务实的最高境界程序员架构修炼之道：架构设计中的人文主义哲学
Gartner  2023  年顶级战略技术趋势【软件架构思想系列】从伟人《矛盾论》中悟到的软件架构思想真谛：“对象”即事物，“函数”即运动变化【模型↔关系思考法】如何在一个全新的、陌生的领域快速成为专家？模仿 + 一万小时定律 + 创新
Redis 作者 Antirez 讲如何实现分布式锁？Redis 实现分布式锁天然的缺陷分析&Redis分布式锁的正确使用姿势！
红黑树、B树、B+树各自适用的场景
你真的懂树吗？二叉树、AVL平衡二叉树、伸展树、B-树和B+树原理和实现代码详解
【动态图文详解-史上最易懂的红黑树讲解】手写红黑树（Red Black Tree）
我的年度用户体验趋势报告——由 ChatGPT AI 撰写
我面试了 ChatGPT 的 PM （产品经理）岗位，它几乎得到了这份工作！！！
大数据存储引擎 NoSQL极简教程 An Introduction to Big Data: NoSQL《人月神话》（The Mythical Man-Month）看清问题的本质：如果我们想解决问题，就必须试图先去理解它【架构师必知必会】常见的NoSQL数据库种类以及使用场景新时期我国信息技术产业的发展【技术论文，纪念长者，2008】B-树（B-Tree）与二叉搜索树（BST）：讲讲数据库和文件系统背后的原理（读写比较大块数据的存储系统数据结构与算法原理）HBase 架构详解及数据读写流程【架构师必知必会系列】系统架构设计需要知道的5大精要（5 System Design fundamentals）《人月神话》8 胸有成竹（Chaptor 8.Calling the Shot -The Mythical Man-Month）《人月神话》7（The Mythical Man-Month）为什么巴比伦塔会失败？《人月神话》（The Mythical Man-Month）6贯彻执行（Passing the Word）《人月神话》（The Mythical Man-Month）5画蛇添足（The Second-System Effect）《人月神话》（The Mythical Man-Month）4概念一致性：专制、民主和系统设计(System Design）《人月神话》（The Mythical Man-Month）3 外科手术队伍（The Surgical Team）《人月神话》（The Mythical Man-Month）2人和月可以互换吗？人月神话存在吗？在平时的工作中如何体现你的技术深度？Redis 作者 Antirez 讲如何实现分布式锁？Redis 实现分布式锁天然的缺陷分析&Redis分布式锁的正确使用姿势！程序员职业生涯系列：关于技术能力的思考与总结十年技术进阶路:让我明白了三件要事。关于如何做好技术 Team Leader？如何提升管理业务技术水平?（10000字长文）当你工作几年就会明白，以下几个任何一个都可以超过90%程序员编程语言：类型系统的本质软件架构设计的核心：抽象与模型、“战略编程”【图文详解】深入理解 Hbase 架构  Deep Into HBase ArchitectureHBase 架构详解及读写流程原理剖析HDFS 底层交互原理，看这篇就够了！mysql 体系架构简介一文看懂MySQL的异步复制、全同步复制与半同步复制【史上最全】MySQL各种锁详解：一文搞懂MySQL的各种锁腾讯/阿里/字节/快手/美团/百度/京东/网易互联网大厂面试题库Redis 面试题 50 问，史上最全。一道有难度的经典大厂面试题：如何快速判断某 URL 是否在 20 亿的网址 URL 集合中？【BAT 面试题宝库附详尽答案解析】图解分布式一致性协议 Paxos 算法Java并发多线程高频面试题编程实践系列: 字节跳动面试题腾讯/阿里/字节/快手/美团/百度/京东/网易互联网大厂面试题库
[精华集锦] 20+ 互联网大厂Java面试题全面整理总结

【BAT 面试题宝库附详尽答案解析】分布式事务实现原理……