从大的方面来讲，软件系统的需求分为功能性需求和非功能性需求。功能性需求一般由业务分解而来，是直接面向用户的需求，也是直接体现用户价值的需求。非功能性需求一般多是由功能性需求的内在要求衍生而来，其价值更多的体现在对功能性需求的支撑上。通常，也将这两者称为软件系统的功能属性和质量属性。

虽然功能属性很重要，但是架构设计中，研究更多的是非功能属性，也就是质量属性。因为这些属性决定着架构是否满足要求从而可支撑用户的需求；是否足够健壮从而可长期运行；是否足够灵活从而可应对未来的变化等等。要做到这一点，就需要对质量属性进行提取，以便针对性的做出决策。下面我们从理论上先看看常见的质量属性有哪些。

1 非功能性需求的相关概念

软件开发中，很多东西都比较难以量化，特别是开发周期问题。因为软件开发是一个相对主观，且跟程序员水平关系比较大的工作，这就导致了人月神话的故事。但是，质量属性却是系统的一个相对可测量或者可测试的属性，可用来描述系统满足利益相关者需求的程度。

首先是性能。性能是指系统的响应能力，即经过多长时间对某个事件做出响应，或者在某段时间内能够处理的事件个数。通常用单位时间内执行事件任务个数来定量表示。

其次是可靠性。可靠性用来表示提供无故障连续服务的能力，表示系统在故障、错误等情况下维持系统功能特性的能力。通常用MTTF和MTBS来衡量。

再者，可用性，也就是正常运行时间比例，通常用两次故障之间的时间长度来衡量。

还有安全性，是系统抵御外部攻击，防止非授权用户访问的能力。包括身份认证、机密性、完整性、不可否认性、可控性等

可修改性，指系统能够以较高性价比进行变更的能力，包括可维护性，可移植性，可扩展性及结构重组。

功能性，是系统完成期望的工作的能力。

可变形，是指架构经过扩充或变更而成为新架构的能力。跟可修改性不同的是，这里是成为新架构。

互操作性，与其他系统或组件交互的能力。

其他还有文化与政治需求，全球化，本地化，多语言等要求。

2 实际系统中如何保障上述非功能性需求

现代软件系统经历了多种模型的演化，每一次的改进都体现了关注点分离，内聚与耦合的强化处理。无论是分层的架构，抽象的手法，还是分而治之的设计等。这些方法的运用，导致软件开发的方法也发生了相应的变化。早期，程序是一个从零到一的产物，这个过程程序员是它的上帝，对它的一切都进行管理。后来，出现操作系统，部分通用需求就沉淀到操作系统中，这样，程序员不再操心程序的加载、调度问题，而只需要关注功能的实现。再之后，随着软件功能的复杂化，在应用软件内部也产生了一些革新的方法论，包括从单体到分层，从分层到服务化，从服务化到微服务，甚至到现在的更大的统一和抽象：云计算。云计算引入了云操作系统，在其上产生了云原生应用，无服务器应用，函数即服务（FaaS）等等。

站在更高的角度来看这一切的演变，我们会发现，底层的基座一直在加固、加厚，为的就是上层应用开发的便捷。就好比一句hello world的打印，在上层来看非常简单，但是底层要做的工作一样都少不了。冰山在膨胀，只是这些变化大部分都在水面之下，很多开发者感知不到而已。

在今天，各种框架和库的推出速度不减反增，不是因为我们的功能需求增加了，而是更多的非功能需求可以更好更快的实现了。得益于底层基座的不断完善和强化，在已有工作的基础上产生更加强大的基座，是这些库和框架发芽生根的原始动力，现有的成果也提供了更加丰富的土壤，因而加速了这一过程。有时候我们会发现，某一个功能框架的应用，需要依赖数十个其他功能框架，就是这一特征典型的表现。

高可靠、高并发、高可用、高安全、高吞吐、高性能、高扩展等等特性，在以前都是需要程序员自己手把手的搭建和解决的，现在可能只需做一个选择题，考虑重点是用哪一家的框架和库，变成这类问题了。从而，实现关注点或者重心始终聚焦于业务和功能实现上，聚焦于价值最大化上。

举个简单例子，今天搭建一个个人服务器，比十年前不知道简单多少倍。之前需要一个团队干的事情，今天可能一个简单培训后的初级程序员就可以做了，而且还不需要太多时间，这就是生产工具促进生产力在程序开发世界的体现。

说这些，并不是鼓励大家不用关注软件的质量属性，相反，要想成为合格的架构师，不想成为眼高手低的纸上谈兵者，还是需要对系统的基本原理有深刻的理解。想象一下，如何成为基础底座的开发者，你就知道自己需要掌握什么了。为了对质量属性有更好的理解，下面仍然结合前述某电力系统项目，谈谈在保证软件架构质量属性方面所采取的应对策略。

性能方面：这一方面的要求对企业架构的方案选型、设计有直接的影响。首先，需要了解业务的特点，其对性能的需求，深刻把握这一点，才能在基础技术选型上开好头起好步。我们以上述某电力系统为例来说明这一点。通常信息系统类的业务功能，对系统没有特殊要求。比如，CPU满足一定性能，内存足够可能就可以了。点击一个按钮，至于是0.1秒响应还是0.2秒响应，在用户的感官上是没有太大区别的，因为这超过了人类感知的分辨率。但是，像前述某电力系统项目，其中有两个业务特点，就对系统提出了特殊的要求：一个是业务中包含了强实时性要求的采集业务，一个是业务中包含了有一定实时性要求的音视频业务。这两类业务又对硬件和软件提出了相应的要求。像实时数据的采集，这是实时性要求最高的一类业务，这类业务在硬件层面的高要求需要FPGA类硬件可编程芯片支撑才可以实现。特别是并行化要求比较严格的一些算法处理，关联数据的采集必须并行进行。采集的数据一部分本地运算处理，一部分远传。在本地运算处理端，需要实时操作系统，在远传端，需要光纤配合特殊的协议，从而保证在故障发生时，能够在极短的时间内处理，避免故障传导蔓延到更大的范围，造成不可避免的经济损失。这些需求，对硬件的选择，操作系统的选择，业务功能开发方式都提出了不同的要求。另外，音视频业务虽然没有实时数据采集这样高的实时性要求，使用Linux系统就可以满足，但是编解码过程仍然会消耗大量的CPU算力。为此，配备硬件编解码器都是业界常用的方案。综合上述需求，我们在设备端采用了多CPU加FPGA的架构方案。数据采集使用带ARM内核的FPGA芯片ZYNQ实现，音视频编解码采用NVR产品类常见的带多通道硬件编解码CPU实现。这样，关键业务需求在技术层面就得到了保证，避免开发进入后期出现性能瓶颈，影响项目的开展。当然，理论选择通过了，还需要做一个验证方案，对选型进行压力测试，保证可选即可行。

上面主要提到了硬件层面的应对方案。其实，软件方面的选择也很重要，且跟硬件相比，软件对开发周期和成本的影响更大。系统是否成熟，开发人员是否熟悉该系统，是否有成熟靠谱的框架都是至关重要的信息。好在整个项目不是从零开发，之前已经有了一套经过产品化验证的视频转发框架，可以满足多视频流业务对性能的要求。在数据采集方面，开发平台内置提供了经过验证的freeRTOS实时操作系统，且提供了SDK开发环境，这些都简化了功能开发的流程，使得开发人员可以将精力集中到业务功能上，且进一步的保证了可靠性。所以，无论是选用业界成熟的框架还是自己设计解决，非功能属性都是为业务的稳定开展服务的。

关于可靠性就更不用说了，是系统架构设计过程中重点关注的内容，往往也是用户比较关注的内容。关于这一点，前面已经有所提及。总的来讲，上述系统为了保障音视频业务的流畅性，设计了支持多网络、异构网络捆绑传输的网络库。通过该方法，多个通道的冗余特性被充分发挥了出来，提高了网络带宽，增加了网络的可靠性。其他方面，像终端设备的软硬件看门狗设计、常见的磁盘阵列、负载均衡、关键节点的备份设计等这些比较常用的手段，也是需要在架构阶段考虑到并纳入整体方案的。不过在这个过程中需要注意一点，过犹不及。不可因为某些特性的支持，导致整个架构过于复杂，出现反噬效应，反而导致不可靠。比较好的经验是平衡架构复杂性和其他功能特性，在保证基础功能特性满足的前提下，尽可能构建较为简洁且易理解的架构，在整个系统运转起来后，可进一步查漏补缺。如果需要对架构的某些方面进行修改，也不会存在大的问题。这些动作可纳入架构演化历程中，通过重构手段来完成。不要幻想架构设计好后是一成不变的。把握这一点，反而能够在开发过程中积累经验，增强信心，减少未知，最终做到从容应对。

安全性方面，在上述系统中也是非常关键的一个要素。因为是涉及电力系统的项目，安全性要求是比较高的。部分功能需要在内部网络运行，有相应的加密标准要求。系统方面，也是需要部署到Linux系统中，这方面因为前期产品是在Windows系统上开发的，还需要考虑跨平台的迁移。好在之前设计时就考虑了可移植性的问题，大部分代码都是可复用的。除此，系统中存在移动设备，这些节点需要通过无线网络接入电力系统内部，也就是需要穿透公网。为实现该需求，在系统设计时选择VPN加密通道的方法，采用专门的加密卡，在公网上构建安全私密的内部专用网络通道，保证数据的安全可靠，减少了接入风险。

除了这些项目关联的安全需求外，常见的身份认证、分级分组的权限管理、安全审计等措施也在系统设计中进行了对应的实施。

其他像可用性，可修改性，在前面的论述中也都有了相应的提及。像可修改性，系统采用了构件化的设计方式，前述的网络库就是以构件方式提供，编解码的业务口也是抽象设计为通用的接口，虽然底层的硬件接口不完全一样，但是在构件层面上，保证了接口的一致性，减少了对接成本，提高了开发效率。

通过上述措施的采用，整个系统的设计实现，基本满足了用户对相关质量属性的要求。上述有针对性的分析和设计，并采取必要的应对措施，有力的保证了整个项目的稳步推进。可以预见，如果没有对这些质量属性进行充分的挖掘和分析，系统的架构很可能成为空中花园，华而不实，且迟早会坍塌下来。

但是即便如此，系统投运后也出现了一些预料外的问题，主要是卫星会商业务的可用性。这一业务最初设想是融合电话和短信，通过短信构建控制通路，通过电话构建数据通路，以此搭建便捷实用的不受空间地点限制的正真意义上的应急会商。考虑到短信存在容易丢和超时的现实情况，为了便于业务层的开发（不用过于关注这些通道特性），在设计控制通路时采用了分层策略，底层包装出一个通道，业务层直接使用。但是实际测试中发现，使用移动网络可行的短信通道，在卫星网络下变得几乎不可用。为了构建一个可靠通道所引入的重传机制却成为占用带宽资源、影响正常传输的障碍。可见，理论上看似完美的方案，实际中可能举步维艰。后来还是放弃通道的设计概念，直接在短信上构建业务功能，在业务中根据需求、优先级特性等有差别的处理短信丢失和超时问题，才慢慢改进了业务体验。这是后续在架构设计方面需要汲取的经验教训。

以上就非功能需求对系统架构设计的影响进行了一些整理总结，希望对大家有所帮助。