成都网站app开发,网站备案个人可以做吗,建筑网图,wordpress评论滑动插件从大的方面来讲#xff0c;软件系统的需求分为功能性需求和非功能性需求。功能性需求一般由业务分解而来#xff0c;是直接面向用户的需求#xff0c;也是直接体现用户价值的需求。非功能性需求一般多是由功能性需求的内在要求衍生而来#xff0c;其价值更多的体现在对功能…从大的方面来讲软件系统的需求分为功能性需求和非功能性需求。功能性需求一般由业务分解而来是直接面向用户的需求也是直接体现用户价值的需求。非功能性需求一般多是由功能性需求的内在要求衍生而来其价值更多的体现在对功能性需求的支撑上。通常也将这两者称为软件系统的功能属性和质量属性。
虽然功能属性很重要但是架构设计中研究更多的是非功能属性也就是质量属性。因为这些属性决定着架构是否满足要求从而可支撑用户的需求是否足够健壮从而可长期运行是否足够灵活从而可应对未来的变化等等。要做到这一点就需要对质量属性进行提取以便针对性的做出决策。下面我们从理论上先看看常见的质量属性有哪些。
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加密通道的方法采用专门的加密卡在公网上构建安全私密的内部专用网络通道保证数据的安全可靠减少了接入风险。
除了这些项目关联的安全需求外常见的身份认证、分级分组的权限管理、安全审计等措施也在系统设计中进行了对应的实施。
其他像可用性可修改性在前面的论述中也都有了相应的提及。像可修改性系统采用了构件化的设计方式前述的网络库就是以构件方式提供编解码的业务口也是抽象设计为通用的接口虽然底层的硬件接口不完全一样但是在构件层面上保证了接口的一致性减少了对接成本提高了开发效率。
通过上述措施的采用整个系统的设计实现基本满足了用户对相关质量属性的要求。上述有针对性的分析和设计并采取必要的应对措施有力的保证了整个项目的稳步推进。可以预见如果没有对这些质量属性进行充分的挖掘和分析系统的架构很可能成为空中花园华而不实且迟早会坍塌下来。
但是即便如此系统投运后也出现了一些预料外的问题主要是卫星会商业务的可用性。这一业务最初设想是融合电话和短信通过短信构建控制通路通过电话构建数据通路以此搭建便捷实用的不受空间地点限制的正真意义上的应急会商。考虑到短信存在容易丢和超时的现实情况为了便于业务层的开发不用过于关注这些通道特性在设计控制通路时采用了分层策略底层包装出一个通道业务层直接使用。但是实际测试中发现使用移动网络可行的短信通道在卫星网络下变得几乎不可用。为了构建一个可靠通道所引入的重传机制却成为占用带宽资源、影响正常传输的障碍。可见理论上看似完美的方案实际中可能举步维艰。后来还是放弃通道的设计概念直接在短信上构建业务功能在业务中根据需求、优先级特性等有差别的处理短信丢失和超时问题才慢慢改进了业务体验。这是后续在架构设计方面需要汲取的经验教训。
以上就非功能需求对系统架构设计的影响进行了一些整理总结希望对大家有所帮助。
