计算机基础知识（第五篇）

计算机基础知识（第五篇）

架构演化与维护

软件架构的演化和定义

软件架构的演化和维护就是对架构进行修改和完善的过程，目的就是为了使软件能够适应环境的变化而进行的纠错性修改和完善性修改等，是一个不断迭代的过程，直至满足用户需求。

举例：有一家电子商务公司，他们的在线购物平台拥有数百万用户。初始时，他们的平台采用单一的单体架构，所有功能都集成在一个应用程序中，但随着时间推移，业务发展，用户数量增加，公司开始遇到一些问题：

• 性能问题：由于用户数量的增加，平台的性能开始下降，响应时间变得较长．
• 扩展性问题：随着新功能的添加，开发团队发现很难扩展和维护整个应用程序．
• 部署问题：每次发布新版本时，整个应用程序都需要重新部署，导致停机时间和风险增加。

为了解决这些问题，公司决定对软件架构进行演化和维护。他们采取了以下措施：

• 微服务架构：他们将应用程序拆分成多个小型服务，每个服务负责一个特定的功能，如用户管理、购物车、支付等。这使得每个服务可以独立扩展和部署，提高了系统的灵活性和性能。
• 容器化：他们引入了容器技术，如Docker，以便更轻松地管理和部署服务。这减少了部署的停机时间，并提高了可靠性。
• 自动化部署：公司建立了自动化部署管道，以便快速发布新功能和修复bug，而无需手动干预．
  通过这些改进，公司成功地演化和维护了他们的软件架构，解决了之前的问题，并为未来的增长和变化做好了准备。这个例子说明了软件架构的演化和维护是一个持续的过程，旨在适应变化的环境和满足用户需求．

演化过程涵盖了软件架构的全生命周期：

• 软件架构需求的获取：识别和确定软件需要满足的需求和目标。
• 软件架构建模：创建架构模型，描述系统的整体结构和组件间的关系。
• 软件架构文档：记录架构设计，提供对系统结构的清晰描述和参考。
• 软件架构实现：将架构设计转化为实际的系统代码和组件。
• 软件架构维护：对架构进行持续的修改和优化，以应对新需求和环境变化。

软件架构演化的重要性：

• 架构是整个系统的骨架：它是软件系统具备诸多良好特性的保障。良好的架构设计能够确保系统的稳定性、可扩展性和性能。
• 架构作为软件蓝图：它为人们宏观管控软件系统的整体复杂性和变化性提供了一条有效途径。通过架构设计，人们可以更好地理解和管理系统的各个部分及其相互关系，从而更有效地应对系统的变化和发展。

软件架构的定义三大要素：

软件架构的定义包含三个主要要素：组件、连接件、约束。软件架构的演化主要关注这三个要素之间的添加、修改和删除等变化。

面向对象软件架构演化

对象演化

在顺序图中，组件的实体是对象，对架构设计的动态行为影响的演化包括Add Object (AO)和Delete Object (DO)两种情况。这两种演化方式在软件架构设计中扮演重要角色，对系统的动态变化和优化起到关键作用。

消息演化

在消息演化中，常见的演化方式包括 AddMessage (AM)、DeleteMessage (DM)、SwapMessageOrder (SMO)、OverturnMessage (OM)、ChangeMessageModule (CMM) 这五种。每种演化方式对于消息在系统中的传递和交互方式有着不同的影响和作用。

复合片段演化

在复合片段演化中，常见的演化方式包括 AddFragment (AF)、DeleteFragment (DF)、FragmentTypeChange (FTC) 和 FragmentConditionChange (FCC) 这四种。复合片段描述了对象交互关系的控制流，表示不同场合可能发生的交互行为，与消息属于连接件范畴，对系统的控制流程具有重要的作用。

约束演化

在顺序图中，约束信息以文字描述的方式存储于对象或消息中，而约束演化则是对这些约束信息进行直接的添加和删除操作。

软件架构演化方式的分类

按照软件架构的实现方式和实施粒度分类：

• 基于过程和函数的演化
• 面向对象的演化
• 基于组件的演化
• 基于架构的演化

按照研究方法分类：

• 第一类：对演化的支持，如代码模块化的准则、可维护性的指示（如内聚和耦合）、代码重构等
• 第二类：版本和工程的管理工具
• 第三类：架构变换的形式方法，包括系统结构和行为变换的模型，以及架构演化的重现风格等
• 第四类：架构演化的成本收益分析，决定如何增加系统的弹性

按照软件架构演化过程是否处于系统运行时期分类：

• 静态演化
• 动态演化

软件架构的演化时期

设计时演化：发生在体系结构模型和相关代码编译之前的软件架构演化阶段。

运行前演化：发生在代码编译后、但应用程序执行之前的软件架构演化。在这个阶段，可以不考虑应用程序的状态，但需要考虑系统的体系结构，并且系统需要具备添加和删除组件的机制。

有限制运行时演化：系统在设计时规定了演化的具体条件，将系统置于“安全”模式下。演化只能在特定约束满足时进行，限制了可以执行的演化操作。

运行时演化：系统的体系结构在运行时无法满足需求时发生的软件架构演化。这包括添加组件、删除组件、升级替换组件、改变体系结构的拓扑结构等操作。这种演化通常是最具挑战性的，因为必须在系统运行时维持其正常操作。

静态演化

软件架构的静态演化主要发生在设计时演化和运行前演化阶段。与之对应的维护方法有三类：

1. 更正性维护：修复系统中的错误。
2. 适应性维护：调整系统以适应新的需求或环境。
3. 完善性维护：增强系统的功能和性能。

软件的静态演化通常包括以下五个步骤：

• 软件理解：查阅软件文档，分析软件架构，识别系统组成元素及其相互关系，提取系统的抽象表示形式。
• 需求变更分析：分析用户需求变化、系统运行出错和运行环境改变等原因，找出新的软件需求与原有需求的差异。
• 演化计划：分析原系统，确定演化范围和成本，选择合适的演化计划。
• 系统重构：根据演化计划对系统进行重构，使其适应当前的需求。
• 系统测试：对演化后的系统进行测试，查找错误和不足之处。

动态演化

动态演化是在系统运行期间进行的演化，需要在不停止系统功能的情况下完成，这使得它较之静态演化更加困难。

软件内部执行所导致的体系结构改变：

例如，许多服务器端软件会在客户请求到达时创建新的组件来响应用户需求。假设有一个在线游戏服务器，它需要动态地创建新游戏房间以响应不同的玩家请求。当玩家请求加入一个新的游戏房间时，服务器会根据请求创建一个新的游戏房间。

软件系统外部的请求对软件进行的重配置：

例如，操作系统在升级时无须重新启动，在运行过程中就完成对体系结构的修改。在操作系统中，内核负责管理硬件资源和执行系统级任务。当需要进行内核更新时，通常不需要重新启动整个计算机。

动态演化的必要性：对于一些需要长期运行且具有特殊使命的系统（如航空航天、生命维持、金融、交通等），如果系统需求或环境发生变化，停止系统运行进行更新或维护将产生高额费用和巨大风险，并对系统的安全性产生很大影响。

软件的动态演化等级分为三个级别：

1. 交互动态性：要求数据在固定的结构下动态交互。
2. 结构动态性：允许对结构进行修改，通常形式是组件和连接件实例的添加和删除，这种动态性是研究和应用的主流。
3. 架构动态性：允许软件架构的基本构造的变动，即结构可以被重定义，如新的组件类型的定义。

软件的动态演化四个方面：

• 属性改名：目前所有的ADL（架构描述语言）都支持对非功能属性的分析和规约，而在运行过程中，用户可能会对这些指标进行重新定义，比如将服务响应时间改为响应时间。
• 行为变化：在运行过程中，用户需求变化或系统自身服务质量的调节都将引发软件行为的变化。例如，一个在线社交媒体平台，最初允许用户发布文字和图片。然后，用户需求发生变化，要求支持视频发布；又或者为了提高安全级别而更换加密算法，将HTTP协议改为HTTPS协议。
• 拓扑结构改变：如增删组件，增删连接件，改变组件与连接件之间的关联关系等。例如，一个分布式系统中有多个服务节点，它们相互连接以共同处理请求。随着系统的扩展，需要增加新的服务节点，同时删除一些不再需要的旧节点。
• 风格变化：一般软件演化后其架构风格应当保持不变，如果必须改变软件的架构风格，也只能将架构风格变为其衍生风格。例如，一个企业级应用程序最初采用了两层客户端/服务器（C/S）架构，其中客户端直接与数据库交互。后来，由于需求的变化或性能问题，决定将架构改变为三层C/S架构，其中增加了应用服务器层来处理业务逻辑。

软件架构演化原则

1. 演化成本控制原则

演化成本控制原则旨在确保在软件架构演化过程中，相关成本能够得到有效控制。

2. 进度可控原则

进度可控原则强调在软件架构演化过程中，需要确保整体进度的可控性。

3. 风险可控原则

风险可控原则旨在确保在软件架构演化过程中，所有潜在的风险都能被有效识别、评估和管理。

4. 主体维持原则

主体维持原则旨在确保在软件架构演化过程中，软件系统的主体行为和核心功能保持稳定不变。

5. 系统总体结构优化原则

系统总体结构优化原则旨在确保在软件架构演化过程中，最终的系统整体结构更加合理和优化。

6. 平滑演化原则

平滑演化原则强调在软件架构演化过程中，确保演化速率趋于稳定，相邻版本的更新率相对固定。

7. 目标一致原则

目标一致原则旨在确保软件架构演化过程中，阶段性目标和最终目标之间保持一致性。

8. 模块独立演化原则

模块独立演化原则强调在软件架构演化过程中，确保各模块能够相对独立地演化，不影响其他模块的正常运行。

9. 影响可控原则

影响可控原则旨在确保在变更一个模块时，其对其他模块的影响保持在可控范围内。

10. 复杂性可控原则

复杂性可控原则旨在确保在软件架构演化过程中，系统的复杂性保持在可控范围内。

11. 有利于重构原则

有利于重构原则强调在软件架构演化过程中，使得架构更易于进行重构。

12. 有利于重用原则

有利于重用原则强调在软件架构演化过程中，提高系统的整体可重用性。

13. 设计原则遵从性原则演化

设计原则遵从性原则演化强调在软件架构演化过程中，不违背已有的架构设计原则。

14. 适应新技术原则

适应新技术原则强调软件系统独立于特定技术手段，适用于不同平台和技术环境。

软件架构演化评估方法

根据演化过程是否已知可将评估过程分为：演化过程己知的评估（正向）和演化过程未知的评估（逆向）。

演化过程已知的评估其目的在于通过对架构演化过程进行度量，比较架构内部结构上的差异以及由此导致的外部质量属性上的变化，对该演化过程中相关质量属性进行评估。

基于度量的架构演化评估方法

基于度量的架构演化评估方法的基本思路是通过对演化前后软件架构进行度量，比较架构内部结构上的差异以及由此导致的外部质量属性上的变化。

具体步骤：

• 架构修改影响分析：

  识别和记录架构在演化过程中所做的每一项修改。
  分析每项修改对架构内部结构和外部质量属性的影响。
  

• 监控演化过程：

  在架构演化过程中，持续监控架构的变化。
  收集和记录每个演化步骤中的度量数据，确保实时跟踪架构质量属性的变化。
  

• 分析关键演化过程：

  对演化过程中关键步骤进行深入分析。
  识别出对质量属性影响较大的关键修改。
  比较这些关键步骤前后的质量属性变化，评估其对整体架构质量的影响。
  

演化过程未知时的评估

当演化过程未知时，我们无法追踪架构在演化过程中的每一步变化。此时只能根据架构演化前后的度量结果逆向推测出架构发生了哪些改变，并分析这些改变与架构相关质量属性的关联关系。

具体步骤：

• 初始和最终架构度量：

  对演化前的初始架构和演化后的最终架构进行全面的质量属性度量。
  获取初始架构的度量结果Q0和最终架构的度量结果Qn。
  

• 比较度量结果：

  比较Q0和Qn，识别出质量属性的变化。
  分析这些变化可能对应的架构修改。
  

• 逆向推测架构演化

  根据质量属性的变化，逆向推测架构在演化过程中可能的修改步骤。
  分析这些修改与架构质量属性之间的关联关系。
  

大型网站架构演化

单体架构

特点：

• 所有业务在一个服务器上：
• 所有的功能模块和业务逻辑都部署在同一个服务器上。
• 各个组件之间紧密耦合，形成一个整体。
• 通常一个代码仓库，包含所有的业务逻辑、数据访问层和用户界面。

优点：开发简单、部署简单、性能优化容易

缺点：扩展性差、可靠性差、单点故障、团队协作难、技术栈统一

适用场景：

• 初创公司或小型项目，业务逻辑简单，快速开发和部署。
• 对于短期内不会有大规模扩展需求的项目。

垂直架构

特点：

• 每种业务在一个单独服务器上

优点：独立部署、扩展性强、可靠性高、技术灵活、团队协作方便

缺点：复杂性增加、成本增加、运维复杂

适用场景：

• 业务规模逐渐扩大，需要更高的系统可靠性和可扩展性。
• 各业务模块之间相对独立，可以清晰地分离和解耦。
• 需要不同的业务模块使用不同的技术栈，以满足多样化的需求。

使用缓存改善网站性能

特点：

• 使用缓存提高网站查询效率

优点：提高性能、降低成本、提高可用性

缺点：数据一致性问题、缓存失效与更新、额外的运维和管理

适用场景：

• 频繁的数据库查询对系统性能造成压力，需要通过缓存减轻负载。
• 需要快速响应的场景，如电商网站的商品详情页、社交媒体的用户动态等。
• 静态资源（如图片、CSS、JavaScript文件）和不频繁变动的数据（如热门文章、排行榜等）。

使用服务集群改善网站并发处理能力

特点：

• 多台应用服务器解决访问量过大效率降低的问题

优点：提高并发处理能力、增强系统可靠性、灵活的扩展性

缺点：增加系统复杂性、高成本投入、网络延迟和带宽问题

适用场景：

• 网站访问量大，单台服务器无法满足并发处理需求，如大型电商平台、社交网络等。
• 需要提供高可用性和容错能力的关键业务系统。
• 业务需求波动较大，需要灵活扩展服务器资源的场景。

数据库读写分离

特点：

• 数据库拆分为主从数据库

优点：提高性能、增强扩展性、提高系统稳定性

缺点：数据一致性问题、增加系统复杂性、负载均衡和路由问题

适用场景：

• 读操作频繁且读写比例悬殊的场景，如新闻网站、社交媒体平台等。
• 数据量大、并发访问高，单一数据库无法满足性能需求的业务系统。
• 需要提高系统的可靠性和容灾能力的数据密集型应用。

使用反向代理和CDN加速网站响应

特点：

• 使用CDN解决不同地域访问效率差异问题

优点：提升访问速度、减少服务器压力、提高网站可用性、优化带宽使用

缺点：成本增加、管理和维护复杂性、缓存一致性问题

适用场景：

• 网站用户分布广泛，存在不同地域访问速度差异的问题，如全球性电商平台、国际新闻网站等。
• 网站流量大，服务器负载高，需要提升响应速度和用户体验的场景。
• 需要提高网站可用性、容灾能力和带宽优化的业务系统。

使用分布式文件系统和分布式数据库系统

特点：

• 文件服务器和数据库服务器使用分布式来部署分摊访问压力：

优点：提升系统性能和可扩展性、提高数据可靠性和可用性、优化数据访问和负载均衡、支持大数据和实时处理

缺点：部署和管理复杂性、数据一致性和事务处理挑战、网络延迟和带宽消耗

适用场景：

• 大规模数据存储和处理需求，如社交媒体平台、视频流媒体服务、大数据分析系统等。
• 高并发访问和高可用性要求的业务系统，如金融交易平台、在线购物网站、实时监控系统等。
• 需要快速扩展和灵活调整资源的业务场景，如云计算平台、分布式计算集群等。

使用NOSQL和搜索引擎

特点：

• 使用NoSQL数据库提升访问性能：显著提升数据访问性能。
• 引入搜索引擎提升数据检索效率：提高数据查询和分析效率。

优点：高性能和高并发处理、灵活的扩展性、多样化的数据模型支持、高可用性和容错性

缺点：一致性和事务支持不足、复杂的运维和管理、学习成本和技术门槛

适用场景：

• 高并发读写和大数据处理需求：社交媒体平台、在线游戏等
• 非结构化数据和全文搜索需求：内容管理系统、电子商务平台等。

业务拆分

特点：

• 把所有业务拆分成微服务的形式：每个微服务负责特定的业务功能
• 更加灵活方便的部署和调整：微服务架构允许独立部署和更新各个服务，减少系统整体停机时间，提升迭代速度和灵活性。

优点：独立部署和持续交付、灵活的扩展性和高可用性、技术栈多样化、团队分工和协作

缺点：复杂的运维和管理、通信开销和一致性管理、开发和测试复杂度

适用场景：

• 复杂和多变的业务需求：需要快速响应市场变化和用户需求。
• 高并发和高可用性要求：用户量大、访问频繁的在线系统。
• 需要快速创新和试验的场景：初创公司和创新型业务，通过微服务架构快速试验新功能和业务模式，降低试错成本。

分布式服务

特点：

• 把应用服务器从集群改为分布式：将应用服务器从传统的集群架构转变为分布式架构。
• 进一步提升性能：分布式架构通过将工作负载分散到多个服务器上，能够更好地利用硬件资源，提高系统的并发处理能力和响应速度。

优点：高可扩展性、高可用性和容错性、资源利用优化、灵活的部署和管理

缺点：复杂的系统设计和管理、通信延迟和一致性问题、运维和监控的复杂度

适用场景：

• 高并发和高性能需求：需要处理大量并发请求和高流量的互联网应用，如电商平台、社交媒体、在线游戏等。
• 高可用性和容错要求：业务连续性和高可用性要求高的金融服务、医疗系统、电信运营等。
• 分布式计算和大数据处理：需要进行大规模数据处理和计算的业务场景，如大数据分析、机器学习、分布式数据库等。

软件架构维护

软件架构维护过程一般涉及架构知识管理、架构修改管理和架构版本管理。

软件架构知识管理是对架构设计中所隐含的决策来源进行文档化表示，进而在架构维护过程中帮助维护人员对架构的修改进行完善的考虑，并能够为其他软件架构的相关活动提供参考。

• 架构知识的定义：架构知识＝架构设计＋架构设计决策。即需要说明在进行架构设计时采用此种架构的原因。
• 架构知识管理侧重于软件开发和实现过程所涉及的架构静态演化，从架构文档等信息来源中捕捉架构知识，进而提供架构的质量属性及其设计依据以进行记录和评价。

在软件架构修改管理中，一个主要的做法就是建立一个隔离区域保障该区域中任何修改对其他部分的影响比较小，甚至没有影响。为此，需要明确修改规则、修改类型，以及可能的影响范围和副作用等。

软件构版本管理为软件架构演化的版本演化控制、使用和评价等提供了可靠的依据，并为架构演化量化度量奠定了基础。

未来信息综合技术

信息物理系统