复杂系统体系结构 课件 第九章复杂系统架构设计方法

第九章2024复杂系统架构设计方法目录2024复杂系统的属性01复杂系统架构设计考虑的因素02复杂系统架构分析方法0304复杂系统架构设计原则第复杂系统文档设计方法第09复杂系统架构设计方法9.1复杂系统架构设计考虑的因素9.1.1架构设计的复杂度架构设计的核心目标架构设计是控制系统复杂性、引导系统向可控方向发展的重要手段软件系统总是朝复杂度增加的方向发展（物理学熵增定律）设计架构时，首先需要分析系统复杂性0102解决软件系统的复杂性案例：如果一个系统的复杂度主要来源于业务逻辑复杂、功能耦合严重，架构师却设计了一个TPS达到10000/秒的高性能架构

那么这个架构无法解决系统的真正复杂性问题错误判断复杂性可能导致资源浪费TPS优化无法解决逻辑耦合问题09复杂系统架构设计方法复杂度的三大组成部分高性能

专注于高并发、高吞吐量的系统优化快速故障恢复和并发控制（如分布式缓存）分布式系统优化负载均衡冗余架构与弹性扩展高可用可扩展高性能高性能、高可用、可扩展的关系架构设计理想目标但往往难以实现需根据实际需求权衡可扩展支持横向或纵向扩展的设计高可用

针对故障容错、数据备份、

恢复机制的设计09复杂系统架构设计方法按优先级处理复杂度复杂度识别将主要的复杂度问题列出来，按优先级顺序进行解决是非常重要的理论上存在，现实中几乎不可能出现软件系统的可塑性和易变性案例Hadoop能将高可用、高性能、大容量三个大数据处理的复杂度问题同时解决注意：架构师不能生搬硬套，认为在任何情况下架构都必须同时满足这三个方面的要求大部分场景下，复杂度只包含其中某一个方面，少数情况下包含其中两个方面出现需要解决三个或以上复杂度情况时，说明系统之前的设计存在问题或者架构师判断失误优先级排序过度设计和错误的复杂性判断引发问题：系统复杂无比、运维效率低下、开发效率低下等问题：可能会出现解决了优先级排在前面的复杂度后，解决后续复杂度的方案需要将已经落地的方案推倒重来09复杂系统架构设计方法案例：微博系统架构的复杂度解决一个微博创业公司。该公司业务快速发展，系统数量不断增加，但系统间协作效率很低。例如，当用户发一条微博时，微博子系统需要通知审核、统计、广告和消息子系统进行相应操作。这意味着一条微博需要通知十几个不同的子系统，且这些通知都是通过接口调用完成的。每当引入一个新系统，微博子系统都必须设计接口、进行测试，并经常会和其他子系统的技术人员产生分歧，导致问题定位麻烦，微博子系统的开发人员备感压力。另外，当用户等级达到VIP后，等级子系统需要通知福利、客服和商品子系统，以进行相应的操作。等级子系统的开发人员同样面临困扰。针对微博的消息队列系统，采用排查法来分析复杂度问题根源架构上各业务子系统强耦合引入消息队列系统解决方法09复杂系统架构设计方法案例：微博系统架构的复杂度解决架构师的具体分析过程系统需要具备高性能读取的能力考虑到消息丢失可能导致的严重后果，消息队列系统也需具备高可用性，包括消息写入、存储和读取由于消息队列的功能较为明确，不需要进行过多的扩展，因此可扩展性并不是复杂度的关键这个消息队列是否需要高性能？假设微博系统用户每天发送1000万条微博，那么微博子系统一天会产生1000万条消息。如果平均每条消息被10个子系统读取，那么其他子系统读取的消息大约为1亿次。对于架构师来说，关注的并不是一天的数据，而是1秒钟的数据（即TPS和QPS）。按秒来计算，每天内平均每秒写入消息数为115条，每秒读取的消息数为1150条。由于读写操作并不完全平均，因此设计目标应以峰值为基础，通常取平均值的3倍。因此，消息队列系统的TPS为345，QPS为3450。问题：存在强耦合的业务子系统，导致系统间协作效率低下解决方法09复杂系统架构设计方法解决复杂度的实践原则优先级排序：综合考虑各因素业务需求：架构设计必须满足业务需求，确定关键复杂度（如性能、可用性等）。技术背景：架构师需要评估团队的技术能力，以便选择合适的技术方案。团队协作：考虑团队规模、沟通效率和技术熟练度，确保架构设计的可执行性和实施效率。安全性因素：架构方案必须兼顾系统的安全性，避免因复杂度过高而导致安全漏洞。架构师的关键任务：逐一解决复杂度问题架构师的关键任务：逐一解决复杂度问题综合分析复杂度：考虑性能、可用性、扩展性等因素的平衡。优先解决关键问题：按业务需求优先级排序，优先解决最紧迫的复杂度问题。技术方案的合理选型：在考虑团队能力的基础上，选用合适的技术工具和框架（如消息队列、分布式系统等）。保持系统可扩展和稳定：设计的架构需保证后期能够灵活应对需求变化。09复杂系统架构设计方法9.1.2认知的复杂度认知分类背景认知复杂度是软件的本质复杂度认知是解决复杂性的基石业务认知是指对业务领域的理解，包括业务流程、需求、规则等方面的认识。它是设计和架构中不可或缺的一部分，直接影响到系统架构的复杂度。业务认知技术认知技术认知是指对当前技术、工具和设计方法的理解及运用能力。技术的不断发展要求架构师时刻保持对新技术的学习和理解，才能提供最佳的设计方案。09复杂系统架构设计方法业务认知和技术认知的案例分析SpringBean扫描：Spring框架的复杂性源于多种Bean定义方式（如嵌套定义Bean、使用@ComponentScan加载其他Bean等）。这种设计不仅解决了多个场景的需求，还增加了实现的复杂度。SpringMVC中的Handler映射：在SpringMVC中，URL的映射不仅仅是单一的URL到Handler的简单映射。它涉及到多个请求方法和不同的匹配逻辑，增加了系统的复杂度。业务认知技术认知事件通知框架设计：设计一个事件通知框架时，最复杂的部分是如何选择事件处理器。常见的做法是让用户指定事件类型，但这种方法增加了用户的负担，未能简化系统设计。站在设计者的角度，应该通过自动化或更智能的方式处理事件类型的分配，避免将复杂性留给用户。09复杂系统架构设计方法提升两种认知的方式深入了解业务：通过学习和实践，真正理解业务流程和需求背后的核心问题。沟通与交流：和业务方保持良好的沟通，定期交流业务变化和需求，确保架构设计能够准确地反映业务需求。案例学习与总结：通过分析和总结实际工作中的错误与挑战，逐步完善业务认知，避免重复错误。业务认知技术认知持续学习和研究：随着技术的不断发展，架构师必须不断跟进新技术，学习并理解其优缺点及适用场景。实践中的总结与反思：通过参与项目实践和技术难题的解决，积累经验并总结最佳实践。技术分享与团队协作：通过团队内的技术分享，促进成员之间的技术交流，共同解决技术问题，提升团队的技术认知水平。相辅相成09复杂系统架构设计方法9.2复杂系统架构分析方法9.2.1领域驱动设计基本概念背景领域驱动设计的概念是2004年EvicEvans在其著作《Domain-DrivenDesign:TacklingComplexityintheHeartofSoftware》（领域驱动设计：软件核心复杂性应对之道）中提出的领域驱动设计是一套方法论指导我们将复杂问题进行拆分、拆分出各个子系统间的关联以及是如何运转的，帮助我们解决大型的复杂系统在落地中遇到的问题[1][2][1]许铁.机器学习vs复杂系统[M]．电子工业出版社.2018[2]Yang,Tang,Han,Feng,Jiang,Yin,andHu.HarnessingthePowerofLLMsinPractice:ASurveyonChatGPTandBeyond[J].2023.09复杂系统架构设计方法领域驱动设计的两大阶段领域驱动设计的核心——建立正确的领域驱动模型不同设计方法的复杂度与开发时间关系0102通用语言的建立建立领域专家、设计人员和开发人员之间的通用语言，确保不同角色能有效沟通领域模型驱动软件设计利用领域模型指导软件的实际设计与实现通过代码实现领域模型，确保软件开发过程中满足业务需求复杂度和开发时间的关系09复杂系统架构设计方法软件系统设计的两大部分战略设计与战术设计

01战略设计

02战术设计指导如何拆分一个复杂系统涉及到域、子域、限界上下文等概念指导如何将拆分出的子系统具体实现涉及到实体、值对象、聚合、领域服务等概念09复杂系统架构设计方法领域模型的特点与重要性领域模型：是对业务领域的抽象，反映了业务需求的核心，帮助开发人员理解和实现复杂的业务逻辑。126357贯穿开发全程贯穿软件的分析、设计与开发过程，确保需求不偏离沟通工具领域专家、设计人员和开发人员通过领域模型进行沟通，共享知识和信息表达方式多样能够灵活响应需求变化集中业务逻辑便于维护和理解与技术无关专注于业务需求不涉及具体技术实现抽象与边界反映了领域内的核心部分并定义了边界领域模型的特点4促进知识转化帮助开发人员平滑地将业务知识转化为软件构造8应对需求变化可以通过图、代码或文字等多种方式表达注意UL与UML的区别09复杂系统架构设计方法通用语言（UbiquitousLanguage）领域驱动设计的一个核心的原则是使用一种基于模型的语言——通用语言（UbiquitousLanguage）定义：在领域驱动设计中，团队成员使用统一的语言进行交流，确保在所有交流形式（图形、文字、代码）中都保持一致性作用：推动软件专家和领域专家之间的沟通，从而发现要在模型中使用的主要的领域概念UML（统一建模语言）：一种标准化的建模语言，用于描述和设计软件系统的结构和行为，强调使用图形化的方式表示系统的各种构件及其交互。通用语言并不要求图形化表示，它注重的是不同角色之间通过共同的语言进行有效沟通。它关注的是“语言一致性”，而不是形式上的建模工具或图形。通用语言通过自然语言、术语、定义等方式在团队成员之间共享，而UML更多是用于系统分析和设计阶段的具体建模工具。09复杂系统架构设计方法9.2.2领域驱动设计的方法领域驱动设计的核心领域驱动设计的核心是领域模型，可以理解为先找到业务中的领域模型，以领域模型为中心驱动项目的开发领域模型将紧密联系的业务设计为一个领域模型，隐藏其内部实现细节，从而减少业务之间的复杂耦合关系[3-5]低耦合高内聚领域模型的设计精髓在于面向对象分析面向对象分析[3]王鹏，刘渊，冷文浩.领域驱动设计在SPP系统中的应用计算机工程与设计.CNKI:SUN:SJSJ.0.2008-13-029[4]EricEvans，赵俐，盛海艳，刘霞.领域驱动设计.人民邮电出社.2007.[5]JimmyNilsson，尼尔森，赵俐，马燕新.领域驱动设计与模式实战.人民邮电出版社.200909复杂系统架构设计方法通用领域驱动设计的架构——四个概念层领域驱动设计的架构负责向用户展现信息、解释用户命令用户界面/展现层1领域层3协调应用的活动，不包含业务逻辑，不保留业务对象状态，但保有应用任务的进度状态2应用层包含关于领域的信息，是业务软件的核心保留业务对象的状态作为其他层的支撑库存在，提供了层间的通信，实现对业务对象的持久化4基础设施层09复杂系统架构设计方法领域驱动设计的四重边界方法四重边界架构设计的基本思想：分而治之通过规划四重边界，DDD将领域知识合理固化和分层，确保不同领域之间的解耦。第一重边界：定义项目的愿景与目标第二重边界：限界上下文第三重边界：分层架构第四重边界：聚合设计确定问题空间划分核心子领域、通用子领域与支撑子领域为每个子域定义物理和逻辑上的隔离，确保业务模型一致性在每个限界上下文内，使用分层架构进行最小的隔离确保领域层的完整性和一致性，将领域模型的最小单元通过聚合进行隔离09复杂系统架构设计方法9.2.3领域驱动设计的典型架构整洁分层架构（CleanLayeredArchitecture）核心思想：通过将领域逻辑与基础设施层分离，保持业务逻辑的独立性。特点：领域层（DomainLayer）：包含领域模型和业务逻辑，不依赖任何外部实现。基础设施层（InfrastructureLayer）：提供技术实现（如数据库、消息队列等），可灵活更换，不影响核心领域。优势：便于替换和扩展基础设施，不影响核心业务逻辑。能够将领域模型从具体的技术实现中解耦。09复杂系统架构设计方法六边形架构（HexagonalArchitecture）核心思想：通过端口和适配器模式将外部系统与核心业务逻辑解耦。特点：通过外层依赖内层实现，使得应用核心与外部依赖之间的耦合更加合理。端口（Port）定义应用与外界交互的接口，适配器（Adapter）负责与外界进行具体实现的交互。优势：增强应用的可测试性，保证核心业务逻辑和外部系统之间的隔离。输入适配器（InboundAdapters）：将外部请求（如HTTP请求、用户输入等）转化为可以传递到领域模型的格式输出适配器（OutboundAdapters）：将领域模型中的数据和操作传递给外部系统09复杂系统架构设计方法洋葱架构（OnionArchitecture）核心思想：将应用的核心领域模型放在最内层，外围通过接口与外部系统交互。分层：核心层（CoreLayer）：领域模型和业务逻辑，所有业务规则都在这一层处理。应用层（ApplicationLayer）：协调领域层的操作，负责外部接口的接入。基础设施层（InfrastructureLayer）：处理与外部系统的交互，如数据库、文件系统等。特点：所有依赖都指向内层领域模型，保证核心业务逻辑不受外部影响。优势：增强应用的可测试性，保证核心业务逻辑和外部系统之间的隔离。09复杂系统架构设计方法9.3复杂系统架构设计原则常见的架构设计原则常见的设计原则SOLID：面向对象设计中的五个基本原则（单一职责、开放封闭、里氏替换、接口隔离、依赖反转）。GRASP：一般责任分配的设计原则（例如信息专家原则、低耦合高内聚原则等）。KISS：简化设计，避免不必要的复杂度。分层架构：系统按照不同的层次进行分解，增强可维护性和扩展性。09复杂系统架构设计方法9.3复杂系统架构设计原则9.3.1职责分解职责分离的两点核心原则拥有什么信息就应该承担怎样的职责一个类只做一件事GRASP的信息专家原则SOLID的单一职责原则职责分解的挑战：如何合理地划分职责的粒度——多细或多粗信息专家原则（GRASP）定义：在系统设计中，拥有某些信息的类应该承担与这些信息相关的职责。应用：当类中的成员属性的操作放在其他类中时，很可能违背了信息专家原则。单一职责原则（SOLID）定义：一个类应该仅有一个变化的原因，即它应该专注于做一件事。应用：通过专注于单一职责来提升类的复用性，减少不必要的依赖。避免耦合以及改动已经稳定的部分。09复杂系统架构设计方法9.3.2层次抽象什么是层次抽象？定义：层次抽象是通过识别系统中常见的规律和模式，将复杂系统分解为多个层次，每个层次负责不同的功能，从而简化开发过程，降低复杂度。作用：通过层次化的设计，能够使开发更具结构性和可维护性，同时提高开发效率。常见的层次抽象示例分层结构视图层：负责与用户的交互，展示数据。业务逻辑层：处理业务逻辑，协调各类操作。数据访问层：负责与数据库或其他存储系统的交互，管理数据。高层次依赖低层次：高层次越具象，越能简化问题的处理。09复杂系统架构设计方法层次抽象的实例传统Servlet开发SpringMVC中的层次抽象过程：首先从HTTP请求中获取参数，转化为业务对象，再进行业务处理。问题：每个业务逻辑处理步骤都需要进行类似的参数获取操作，增加了开发的复杂度。改进：SpringMVC通过POJO（普通Java对象）直接映射请求参数，避免了重复的底层操作。优势：简化了开发流程，不需要开发者手动处理请求参数的提取，将业务逻辑与底层细节解耦。层次抽象的特性固有属性：复杂系统本身就具有层次性，层次抽象是为了有效地管理系统复杂性。降低认知复杂度：通过分层的方式，系统变得更加清晰和可理解，开发者能够更容易掌握系统的结构和逻辑。提高效率：利用已发现的规律，使得开发过程更加高效，避免重复性工作。09复杂系统架构设计方法9.3.3变化扩展变化扩展的挑战变化带来的挑战：软件开发中最常见的现象是需求的不断变化。设计原则的真正作用在于应对这些变化，尤其是在变化的复杂性和可预测性上。技术难点：变化扩展的挑战不在于技术本身，而是在于如何准确识别和理解“变化”的位置。变化扩展的常见技术手段提供基本的框架定义灵活的接口供不同模块或子系统实现，应对业务需求的变化通过外部配置来管理变化，减少硬编码，灵活应对需求的变化配置项实现对请求和响应的动态处理接口抽象类为不同的服务提供者定义扩展点，实现系统功能的灵活扩展拦截器SPI允许系统在运行时动态加载新的功能模块，应对不断变化的需求插件09复杂系统架构设计方法9.3.3变化扩展认识变化的难点变化识别的难度：最难的部分不是技术实现，而是如何识别和理解哪些功能会发生变化。依赖变化的认知宽度：能够识别变化的范围决定了系统设计的灵活性和可扩展性。设计师需要具备前瞻性和全局视野。实际案例：常见用法：定义一个Controller类，并在方法上使用@RequestMapping注解来处理请求。扩展变化：除了常规的方式，还可以实现Controller接口，这种方法处理请求的方式有所不同。不同场景的差异：这些变化源于不同的业务场景和需求类型，在设计时需要考虑如何处理这些变化。SpringMVC中的变化扩展09复杂系统架构设计方法9.3.4抽象治之抽象——应对复杂场景的有效方法定义：抽象是应对复杂业务场景和系统结构的有效手段，通过抽象，能够简化复杂系统的理解和管理。挑战：最难的部分在于抽象什么来刻画业务。选择正确的抽象方法是系统设计的核心。AOP（面向切面编程）中的抽象概念：AOP通过对类和方法进行切面增强，提供了处理共性业务逻辑（如日志、权限检查）的机制。业务视角：从用户角度来看，AOP告诉我们哪些类和方法需要增强什么样的共性逻辑（例如日志、权限）。关键元素：切面（Aspect）：对共性业务逻辑的封装，如日志切面、权限切面。切点（JoinPoint）：指定的类和方法，表示在哪些地方增强特定逻辑。通知（Advice）：在切点上织入的具体增强逻辑。通过切面编程在指定的类和方法上织入特定的共性逻辑09复杂系统架构设计方法9.4复杂系统文档设计方法9.4.1复杂系统需求分析文档需求分析概述基于需求确认和验证(V&V)的系统工程流程需求的根本目的：复杂系统的需求分析是设计、制造与客户之间的主要沟通桥梁。确保系统设计能够满足客户需求，通过明确的需求指导产品的工程开发。需求分析的工程化与条目化：需求应该能够转化为工程模型，进一步驱动产品的开发和验证。系统工程方法：基于模型的系统工程（MBSE）要求通过模型支持需求定义、设计、分析、验证等过程，从概念设计阶段一直贯穿整个开发过程。09复杂系统架构设计方法需求分析的业务流程和方法需求模型的树状结构需求分析的业务流程：是一个不断迭代和验证的过程，最终目的是冻结需求并确认其完整性。需求模型的层次结构：客户需求层：国家或采购方的技术要求、法规等。产品需求层：总体技术要求。分系统需求层：子系统技术要求。设备零件需求层：设备零件设计要求。层级化管理需求，确保需求的完整性和可追溯性09复杂系统架构设计方法需求文件的组成及导入和导出需求模型与相关对象的追踪需求文件的管理需求模型与相关对象的追踪导入：将外部的需求文件（如WORD、PDF等）按照预定格式导入到需求管理系统。导出：将需求模型导出为报告形式，形成完整的需求报告或文件，便于审查与浏览。需求通过内部链接与其他需求关联，确保需求的一致性和完整性。需求与其他系统对象（如设计、制造、测试等）之间的关系通过外部链接进行追踪。09复杂系统架构设计方法需求模型的成熟度和属性演变需求模型的成熟度09复杂系统架构设计方法9.4.2复杂系统架构设计文档复杂系统架构设计文档概述架构设计文档的目标：复杂系统架构设计文档的目的是定义系统的整体架构方案，描述系统的各个组件和子系统之间的关系，确保开发、部署和维护过程中的一致性。架构设计的重要性：确保系统的可扩展性、性能、可维护性和安全性。在复杂系统中，架构设计文档作为沟通工具，确保不同团队在设计和实施过程中保持一致的理解。复杂系统架构设计文档的基本流程BABSC架构方法论：是一个逐步进行、循环验证和修改的工程过程。构建商业架构概念构建应用架构概念确立系统架构基线子系统架构及设计构件与单元设计关键特点：每个步骤不仅是对架构的逐步完善，也是对系统需求、功能和性能要求的精细化处理。09复杂系统架构设计方法构建商业架构概念目标：全面了解当前商业模型及其运作方式，为架构设计奠定基础。必需活动：建立产品/项ID信息概览：确定产品的范围、最终用户和商业背景。建立术语字典：确保所有利益相关者在商业及架构描述中的理解一致。商业运作总体概念：明确商业运作的流程、功能边界和交互。商业组织结构分析：理解并分析商业运作的组织结构和协作关系。商业活动与节点分析：分析商业运作中的节点及其协同工作模式。事件与消息分析：汇总商业活动中的事件和信息流转。动态商业活动建模：分析商业活动在动态运行时的特征和变化过程。商业节点状态变化：分析商业活动对节点或内部状态变化的影响。数据交换模型构建：汇总商业活动中数据交换的基本模型。商业数据关系模型：分析商业活动中