软件架构设计是系统架构分析与设计中的关键环节其中包含不同的软件架构设计风格、软件架构开发方法、软件设计中的非功能性需求、软件架构评估以及系统架构的演化等。本文简单整理了这些基本概念以了解。从系统架构设计师的角度屡败屡战后在上半年非常侥幸的通过工作中的考试或许就是一个“一鼓作气再而衰三而竭”的过程有时候会带有一定的运气成分。以考代学对架构设计的基本概念也有一定的认识和理解以下之前整理的相关素材可以作为参考。架构系列之软件工程基本概念架构系列之DevOps的核心理念与方法实践架构系列之Service Mesh服务网格基本概念解析架构系列之分布式事务常见实现算法基本介绍架构系列之分布式系统的防重和幂等机制架构系列之负载均衡相关基本概念架构系列之微服务架构设计的原则和约束架构系列之云原生架构中常用架构模式架构系列之六边形架构介绍1、软件架构的概念1.1 软件架构的定义一个程序和计算系统软件体系结构是指系统的一个或多个结构。结构中包括软件的构件、构件的外部可见属性以及它们之间的相互关系1.2 软件架构设计与生命周期1需求分析阶段需求分析和软件架构根据需求模型构建SA模型、保证模型转换的可跟踪性。在需求阶段研究SA将SA概念贯穿整个软件生命周期2设计阶段SA模型的描述、SA模型的设计与分析方法、SA设计经验的总结与复用经典41模型逻辑视图、进程视图、开发视图、物理视图加上统一场景UML统一建模语言逻辑视图类与对象、实现视图物理代码文件和组件、进程视图线程和进程、部署视图软件到硬件的映射加上用例视图需求分析模型3实现阶段基于SA的开发过程支持、从SA向实现的过渡路径、基于SA的测试技术4构件组装阶段可复用构建的互联、组装过程中检测并消除体系结构失配的问题。中间件提供构件之间跨平台的交互能力5部署阶段提供高层的体系结构视图来描述部署阶段的软硬件模型、分析部署方案的质量属性6后开发阶段围绕维护、演化、复用等方面动态软件体系结构软件内部执行所导致的体系结构改变软件系统外部请求对软件进行的重配置体系结构恢复与重建从已实现的系统中获取体系结构的过程1.3 架构描述语言ADLADL是在底层语义模型的支持下为软件系统的概念系统结构建模提供了具体语法和概念框架构件计算或数据存储单元连接件构件之间相互建模的体系结构构造块及支配交互的规则架构配置描述体系结构的构件与连接中的连接图2、软件架构风格2.1 数据流风格2.1.1 批处理每个处理都是单独的程序每一步在前一步结束后才开始。数据必须是完整的以整体的方式传递。2.1.2 管道过滤器处理步骤由过滤器实现数据传输由管道负责2.2 调用/返回风格2.2.1 主程序/子程序单线程控制构件为主程序和子程序、过程调用充当连接件2.2.2 面向对象体系建立在面向对象和数据抽象的基础上构件是对象或抽象数据类型的实例2.2.3 层次型体系每一层为上层提供服务并作为下层的客户构件在层上实现了虚拟机2.2.4 客户端/服务器两层C/S和三层C/S三层C/S分为表示层、功能层和数据层2.3 独立构件风格2.3.1 进程通信体系结构构件是独立的过程、连接件是消息传递。消息传递的方式可以是点对点、异步或同步方式以及远程过程调用2.3.2 事件系统体系结构基于事件的隐式调用构件不直接调用一个过程而是触发或广播一个或多个事件2.4 虚拟机风格2.4.1 解释器体系包含解释工作的解释引擎、被解释代码的存储区、记录解释引擎当前的工作状态、记录源代码被解释执行的进度含有一个虚拟机仿真硬件的执行过程和一些关键应用。2.4.2 规则系统包括规则集、规则解释器、规则/数据选择器及工作内存2.5 以数据为中心仓库风格2.5.1 仓库体系风格存储和维护数据的中心场所中央数据构件以及对中央数据构件进行操作的独立构件连接件为仓库与独立构件之间的交互2.5.2 黑板体系风格问题求解模型组织推理步骤、控制状态数据和问题求解领域的知识框架应用在语音识别、模式识别等2.6 闭环控制架构适合嵌入式系统用于简单闭环控制问题如空调温控、定速巡航2.7 C2风格构件和连接件都有一个顶部和一个底部构件的顶部要连接到连接件的底部构件的底部要连接到连接件的顶部3、层次化架构风格3.1 C/S架构3.1.1 两层C/S架构将应用功能划分为客户端表示层和服务器数据层端的网络架构模式3.1.2 三层C/S架构在两层架构的基础上将应用功能进一步划分为表示层、功能层和数据层三个部分的网络架构模式表示层位于客户端负责与用户进行交互显示数据和接收用户输入功能层应用服务器层负责处理业务逻辑和应用程序的执行。它接收表示层的请求与数据层进行交互并将处理结果返回给表示层。数据层负责数据的存储和管理。它根据功能层的请求进行相应的数据操作并返回结果。两层C/S架构相对简单、三层C/S安全性更高3.2 B/S架构将系统功能实现的核心部分集中到服务器中同时简化了系统的开发、维护以及使用。用户通过浏览器即可访问服务器上的应用程序无需安装其他客户端。缺乏对动态页面的支持能力没有集成有效的数据库处理能力B/S架构的安全性难以控制速度查询等响应速度上低于C/S架构数据提交一般以页面为单位数据的动态交互性不强3.2.1 三层B/SMVC风格Model-处理应用程序中数据逻辑部分、View-处理数据显示部分、Controller-处理用户交互部分。缺点是视图和控制器之间的交互可能过于紧密导致代码难以维护Controller承担过多的业务逻辑MVP风格MVC的变种实现View和Model之间的解耦。Presenter作为中间层负责接收用户的输入、调用模型以及更新视图。它充当了视图和模型之间的桥梁协调它们之间的交互。MVVM风格ViewModel作为中间层负责协调视图和模型之间的交互。它封装了业务逻辑和数据转换逻辑并将模型中的数据转换为视图可以显示的数据格式。3.3 基于服务的架构SOA服务是为了满足某项业务需求的操作、规则等的逻辑组合包含有一系列有序活动的交互为实现用户目标提供支持服务服务是自包含的、模块化的软件组件可以被不同的应用程序或业务流程调用。接口接口是服务之间的通信方式它采用中立的方式进行定义独立于实现服务的硬件平台、操作系统和编程语言。松耦合服务之间松耦合意味着服务之间是相互独立的修改一个服务不会影响其他服务。降低了服务之间的依赖性有利于系统的模块化和维护。3.3.1 核心功能服务识别与定义识别业务功能并将其定义为独立的服务。服务抽象隐藏服务内部实现的细节只暴露接口。服务目录创建服务目录或注册中心以便服务消费者发现可用服务。服务组合允许通过组合多个服务来构建复杂的业务流程。服务交互实现服务之间的通信和数据交换。3.3.2 特点与优势重用性服务可以在不同的应用程序和业务流程中重复使用提高了系统的开发效率和维护成本。互操作性服务遵循标准协议可以在不同的平台和环境中工作实现了跨系统的互操作性。标准化服务接口遵循标准化的协议如SOAP、REST等使得服务之间的通信更加规范和可靠。灵活性SOA架构将系统拆分成独立的服务可以按需组合和重组这些服务从而实现系统的快速扩展和灵活部署。可维护性由于服务之间的松耦合关系降低了服务之间的依赖性使得系统的维护更加简单和方便。3.4 微服务将单一的应用程序划分为一组小的服务每个服务之间互相协调、互相配合每个服务运行在独立的进程中服务与服务之间采用轻量级的通信机制互相沟通3.4.1 特性服务分解应用程序被分解成一组小型服务每个服务实现特定的业务功能。独立部署每个微服务都可以独立部署不会影响其他服务。技术异构性允许使用多种编程语言和技术栈来开发不同的微服务。易于维护和理解每个微服务都是独立的代码库和部署单元职责清晰。高度解耦微服务之间通过轻量级通信机制进行通信如HTTP/REST、消息队列等。3.4.2 缺陷与挑战部署与运维复杂需要管理多个服务单元每个服务单元都需要部署、监控和管理。部署自动化服务间的依赖测试与管理网络延迟和错误微服务之间通过网络进行通信可能会受到网络延迟和错误的影响。数据一致性难以保证每个服务单元都独立运作需要在服务单元之间保持数据一致性。安全性问题微服务架构涉及多个服务单元之间的网络通信存在数据泄露、劫持等安全问题。3.4.3 微服务与SOA对比4、软件架构复用4.1 复用类型机会复用开发过程中只要发现有可复用的资产既对其复用系统复用开发之前进行规划以决定哪些需要复用4.2 复用原因可以减少开发工作、减少开发时间以及降低开发成本提高生产力提高产品质量使其具有更好的互操作性产品维护变得简单4.3 基本过程构造/获取可复用的资产管理可复用资产使用可复用资产5、基于架构的软件开发ABSDABSD的概念与术语自顶向下、递归细化的方法。强调由业务、质量和功能需求的组合驱动设计视角与视图用不同的视角观察对架构的描述用例与质量场景用例捕获功能需求、特定场景捕获质量需求5.1 ABSD开发模型5.1.1 架构需求需求获取定义开发人员必须实现的软件功能以及获得软件质量属性的非功能性需求标识构件分为生成类图、对类进行分组、把类打包成构件需求评审需求是否满足用户需求、类的分组是否合理、构件合并是否合理等5.1.2 架构设计提出软件体系结构模型通过体系结构模型获得关于体系结构属性的理解把已标识的构件映射到软件体系结构中分析构件之间的相互作用产生软件体系结构设计评审5.1.3 架构文档化输出体系结构规格说明和测试体系结构需求的质量设计说明书5.1.4 架构复审标识潜在的风险及早发现体系结构设计中的缺陷与错误5.1.5 架构实现以复审后的文档化体系结构说明书为基础经过分析设计、构件实现、构件组装和系统测试阶段5.1.6 架构演化需求变动或变化后相应修改软件架构。包括需求变化归类、制定架构演练计划、修改删除增加构件、更新构件相互作用、构件组装与测试、最后技术评审6、特定领域的软件架构DSSA6.1 基本概念在一个特定应用领域中为一组应用提供提供组织架构参考的标准软件体系结构垂直域包含整个系统族内的多个系统水平域定义多个系统和系统族中功能区域的共有部分6.1.1 领域分析获得领域模型领域模型描述领域中系统之间的共同需求6.1.2 领域设计获得DSSA领域模型中表示需求的解决方案6.1.3 领域实现依据领域模型和DSSA开发和组织可重用信息6.2 DSSA参与人员领域专家、领域分析人员、领域设计人员和领域实现人员6.3 DSSA领域建立过程定义领域范围定义领域特定的元素定义领域特定的设计和实现需求设计定义领域模型和体系结构产生、搜集可重用的产品单元7、软件质量属性定义软件系统与明确地或隐含地定义的需求相一致的程度7.1 性能性能指系统的响应能力即要经过多长时间才能对某个事件做出响应或在某段时间内系统所能处理的事件的个数7.2 可靠性软件系统在系统或应用错误面前在意外或错误使用的情况下维持软件系统功能特性的基本能力MTTF平均失效等待时间MTBF平均失效间隔时间容错错误发生时确保系统正确的行为并进行内部修复健壮性在发生意外错误事件时确保应用系统处于预先定义好的状态7.3 可用性指系统能够正常运行的时间比例。用两次故障之间的长度或在出现故障时候系统能够恢复正常的速度来表示7.4 安全性指系统向合法用户提供服务的同时能够阻止非授权用户的使用企图和拒绝服务能力7.5 可修改性对系统进行变更的能力可维护性错误发生后可修复软件系统可扩展性使用新特性扩展系统使用改进版本替换构件结构重组重新组织软件系统构件及构件间的关系可移植性软件系统适用于多种硬件平台、操作系统、编程语言或编译器等7.6 功能性系统完成所期望工作的能力7.7 可变性架构经扩充或变更成为新架构的能力7.8 互操作性为外部可视的功能特性和数据结构提供精心设计的软件入口7.9 质量属性场景7.9.1 质量效应树质量属性效用树从根节点到叶节点包含四个固定层级其顺序和含义如下树根代表系统的整体目标例如“电商平台核心系统”。质量属性一级分支即系统关注的核心质量维度如性能、安全性、可用性、可维护性等。属性分类二级分支对质量属性进行细化。例如将“性能”细化为“延迟”和“吞吐量”或将“安全性”拆解为“机密性”、“完整性”等。质量属性场景叶节点是具体、可测量的需求描述。例如“99.9%事务的响应时间小于1秒”。7.10 质量属性场景描述刺激源生成该刺激的实体刺激当刺激到达系统时需要考虑的条件环境该刺激在某些条件内发生制品某个制品被刺激响应激励在到达后所采取的行动响应度量响应发生时能够以某种方式进行度量以对需求进行测试8、软件架构评估系统架构的评估方法基于调查问卷或检查表、基于场景、基于度量8.1 敏感点和权衡点敏感点是一个或多个构件的特性权衡点是影响多个质量属性的特性是多个质量属性的敏感点风险点是指架构设计中潜在的、存在问题的架构决策所带来的影响非风险点指不会带来隐患的分析与描述8.2 系统架构评估方法8.2.1 SAAM软件架构分析法关注可修改性主要质量属性。过程场景开发、架构描述、单个场景评估、场景交互和总体评估8.2.2 ATAM架构权衡分析法系统的可修改性、安全性、性能和可用性。过程场景和需求收集、架构视图和场景实现、属性模型的构造和分析、折中8.2.3 CBAM成本效益分析法质量属性为项目干系人带来收益。步骤整理场景、对场景进行求精、确定场景的优先级、分配效用、架构策略涉及哪些质量属性及响应级别、确定期望的质量属性级别、计算各策略架构的总收益、根据受成本影响的ROI选择架构策略8.3 ATAM方法评估实践8.3.1 演示介绍ATAM介绍业务驱动因素介绍要评估的体系结构8.3.2 调查和分析确定架构方法生成质量属性效用树根节点-效用-质量属性-场景-场景实现分析体系结构方法确定风险、无风险、敏感点和权衡点8.3.3 测试头脑风暴和优先场景分析架构方法8.3.4 报告ATAM评估期间收集的所有信息包括效用树、生成的场景、分析问题、确定的风险和非风险、确定的架构方法9、软件可靠性9.1 定义软件产品在规定条件和规定时间完成规定功能的能力9.2 可靠性定量描述MTTFMean Time To Failure系统正常运行到发生故障时间MTTRMean Time To Recovery出现故障到恢复的时间MTBFMean Time Between Failure平均故障间隔时间MTBFMTTFMTTRMTTR越短越好9.3 可靠性目标可靠度、故障强度和平均时效时间等描述9.4 可靠性管理9.4.1 需求分析阶段确定软件可靠性目标、制定可靠性管理框架等9.4.2 概要设计阶段可靠性度量、可靠性设计等9.4.3 详细设计阶段可靠性设计、可靠性预测等9.4.4 编码阶段可靠性测试、收集可靠性数据等9.4.5 测试阶段可靠性测试、可靠性建模和评价等9.4.6 实施阶段可靠性测试、可靠性评价等9.5 可靠性设计9.5.1 设计原则容错技术设计降低复杂度检错技术9.5.2 N版本程序设计增加了三个阶段相异成分规范评审、相异性确认、背对背测试N版本程序的同步、程序之间的通信、表决算法、一致比较问题、数据相异性9.5.3 恢复块方法保证主块和后备块之间的独立性主块和备块之间的共性程度降到最低必须保证验证测试程序的正确性9.5.4 系统配置技术双机热备、服务器集群技术9.6 可靠性测试可靠性目标的确定保证软件的可靠性达到要求运行剖面的开发软件的使用行为建模、开发使用模型测试用例的设计针对特定的功能或组合功能设计测试方案并编写成文档测试实施测试结果分析9.7 可靠性评价选择可靠性模型收集可靠性数据可靠性评估和预测10、软件架构的演化单体架构垂直架构使用缓存缓存与数据库的数据一致性问题缓存技术对比Redis分布式存储方案Redis数据分片的方式Redis数据淘汰算法Redis持久化Redis缓存雪崩Redis缓存穿透缓存预热、缓存更新与缓存降级使用服务集群数据库读写分离使用反向代理和CDN使用分布式文件系统和分布式数据库使用搜索引擎和NoSQL业务拆分分布式服务11、软件与中间件11.1 构件构件是一组组装单元具有规范的接口规约和显示的语境依赖独立部署单元作为第三方组装单元没有外部可见状态构件是一组需要同时部署的原子构件构件和原子构件的区别是大部分原子构件不会被单独部署原子构件是一个模块和一组资源11.2 中间件中间件是一类构件也是一类系统软件面向需求设计师集中精力于业务逻辑本身业务的分隔和包容性按照不同的业务进行功能划分体现为不同的接口或交互模式设计与实现隔离通过接口实现不必关心内部实现隔离复杂的系统资源将系统资源与应用构件隔离符合标准的交互模型实现了架构模型实现了标准的协议软件复用提供了构件封装、交互规则、与环境的隔离为软件复用提供了解决方案提供对应用构件的管理构件可以通过标识机制进行划分方便管理11.3 构件的复用水平复用部分行业领域通用垂直复用分行业领域专用11.3.1 检索与提取构件基于关键字检索树形或有向无回图结构刻面检索法利用Facet描述构件执行的功能、被操作的数据、构件应用的语境等超文本检索法按照人类的联想思维方式任意跳转到包含相关概念或构件的文档11.3.2 理解与评价构件构件的开发过程遵循公共标准11.3.3 修改构件构件的功能、行为和接口设计更为抽象化、通用化和参数化11.3.4 组装构件1组装的三种方式基于功能的组装基于子程序调用和参数传递的方式将构件组装起来基于数据的组装面向数据的设计方法面向对象的组装以基类为父类生成相应的子类2构件组装失配的问题由构件引起的失配由连接子引起的失配由于系统成分对全局体系结构的假设存在冲突引起的失配11.4 构件的标准COBRA、COM、EJB12、Web架构设计单体应用到数据库与Web服务器分离应用服务器集群负载均衡的引入应用层负载均衡和传输层负载均衡负载均衡算法有状态和无状态服务持久化技术ORMORM为对象与关系数据之间的映射数据库读写分离用缓存缓解读库的压力Redis特性内容分发网络CDN尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节使内容传输得更快、更稳定响应式Web设计页面设计布局智能的根据用户行为以及使用的设备环境进行相对应的布局业务中台和数据中台Web系统分层参考资料架构系列之软件工程基本概念系统架构设计师第二版教程软件架构实践