第一章系统架构的定义及发展历程

本章内容作为知识了解部分考试内容基本不涉及

系统架构的定义

• 架构是体现在组件中的一个系统的基本组织、它们彼此的关系与环境的关系及指导它的设计和发展的原则。
• 系统是组织起来完成某一特定功能或一组功能的组件集。系统这个术语包括了单独的应用程序、传统意义上的系统、子系统、系统之系统、产品线、整个企业及感兴趣的其他集合。系统用于完成其环境中的一个或多个任务。
• 环境或者上下文决定了对这个系统的开发、运作、政策以及会对系统造成其他影响的环境和设置。
• 任务是由一个或者多个利益相关者通过系统达到一些目标的系统的一个用途或操作。

通俗地说，系统架构（System Architecture ）是系统的一种整体的高层次的结构表示，是系统的骨架和根基，支撑和链接各个部分，包括组件、连接件、约束规范以及指导这些内容设计与演化的原理，它是刻画系统整体抽象结构的一种手段。系统架构设计的目的是对需要开发的系统进行一系列相关的抽象，用于指导系统各个方面的设计与实现，架构设计在系统开发过程中起着关键性作用，架构设计的优劣决定了系统的健壮性和生命周期的长短。我们通常把架构设计作为系统开发过程中需求分析阶段后的一个关键步骤，也是系统设计前的不可或缺工作要点之一。

架构设计的作用

架构设计的作用主要包括以下几点：

1. 解决相对复杂的需求分析问题；
2. 解决非功能属性在系统占据重要位置的设计问题;
3. 解决生命周期长、扩展性需求高的系统整体结构问题；
4. 解决系统基于组件需要的集成问题；
5. 解决业务流程再造难的问题。

系统架构设计是成熟系统开发过程中的一个重要环节，它不仅是连接用户需求和系统进一
步设计与实现的桥梁，也是系统早期阶段质量保证的关键步骤。

系统架构的发展阶段

基础研究阶段（1968-1994年）

模块化开发：模块化开发方法是指把一个待开发的软件分解成若干个小的而且简单的部分，采用对复杂事物分而治之的经典原则。
将系统分解成模块时，应该遵循以下规则：

1. 最高模块内聚。也就是在一个模块内部的元素最大限度地关联，只实现一种功能的模块是高内聚的，具有三种以上功能的模块则是低内聚的。
2. 最低藕合。也就是不同模块之间的关系尽可能弱，以利于软件的升级和扩展。
3. 模块大小适度。颗粒过大会造成模块内部维护困难，而颗粒过小又会导致模块间的祸合增加。
4. 模块调用链的深度（嵌套层次）不可过多。
5. 接口简单、精炼（扇入扇出数不宜太大），具有信息隐蔽能力。
6. 尽可能地复用己有模块。

概念体系和核心技术形成阶段（1999-2000 年）

这一阶段的主要成就之一就是软件组件化技术
通常，组件具有可组装性和可插拔性。每个组件的运行仅依赖于平台或者容器，组件与组件之间不存在直接的藕合关系。同时，组件和组件之间又并非绝对独立。组件经过组装后可以与其他组件进行业务上的交互。组件化开发并不等同于模块化开发。模块化开发只是在逻辑上做了切分，物理上（代码）通常并没有真正意义上的隔离。组件化也不等同于应用集成，应用集成是将一些基于不同平台或不同方案的应用软件有机地集成到一个无缝的、并列的、易于访问的单一系统中，以建立一个统一的综合应用。组件化比模块化更独立，但比应用集成结合得更加紧密。

理论体系完善与发展阶段（1996 年至今）

研究重点主要包括：

1. 软件架构描述与表示
2. 软件架构分析、设计和测试
3. 软件架构发现、演化与重用
4. 基于软件架构的开发方法
5. 软件架构风格

普及应用阶段（2000年至今）

软件架构是软件生命周期的重要产物，它影响软件开发的各个阶段。

• 需求阶段：把软件架构有的概念引入需求分析阶段，有助于保证需求规约和系统设计之间的可追踪性和一致性。
• 设计阶段：设计阶段是软件架构研究关注最早、最多的阶段，这一阶段的软件架构主要包括软件架构的描述、软件架构模型的设计与分析以及对软件架构设计经验的总结与复用等。
• 实现阶段：将设计阶段设计的算法及数据类型用程序设计语言进行表示，满足设计、架构和需求分析的要求，从而得到满足设计需求的目标系统。
• 维护阶段：为了保证软件具有良好的维护性，在软件架构中针对维护性目标进行分析时，需要对一些有关维护性的属性（如可扩展性、可替换性）进行规定，当架构经过一定的开发过程实现和形成软件系统时，这些属性也相应地反映了软件的维护性。

软件架构的常用分类及建模方法

软件架构的常用分类

1. 分层架构
   1. 表现层：用户界面，负责视觉和用户互动
   2. 业务层：实现业务逻辑
   3. 持久层：提供数据，SQL语句就放在这一层；
   4. 数据库：保存数据。
      有的项目在逻辑层和持久层之间加了一个服务层（service），提供不同业务逻辑需要的一些通用接口。
2. 事件驱动架构
   1. 事件队列
   2. 分发器
   3. 事件通道
   4. 事件处理
3. 微核架构
   微核架构又称为插件架构，是指软件内核相对较小，主要功能和业务逻辑都通过插件实现，内核通常只包含系统运行的最小功能。插件则是互相独立的，插件之间的通信应该减少到最低，避免出现相互依赖的问题。
4. 微服务架构
   每一个服务就是一个独立的部署单元，微服务架构分成三种实现模式
   1. RESTful API模式：服务通过API提供，云服务就属于这一类。
   2. REATful 应用模式：服务通过传统的网络协议或者应用协议提供，背后通常是一个多功能的应用程序，常见于企业内部；
   3. 集中消息模式：采用消息代理（Message Broker ）可以实现消息队列、负载均衡、统一日志和异常处理，缺点是会出现单点失败，消息代理可能要做成集群。
5. 云架构
   云架构主要分成两部分：处理单元（Processing Unit ）和虚拟间件（Virtualized Middleware )
   处理单元：实现业务逻辑。
   虚拟中间件：负责通信、保持会话控制（sessions) 、数据复制、分布式处理和处理单元的部署。虚拟中间件又包含四个组件：
   a. 处理单元
   b. 虚拟中间件
   c. 消息中间件
   d. 数据中间件
   e. 处理中间件
   f. 部署中间件

软件架构的应用场景

不同的架构风格具有各自的优缺点和应用场景
6. 管道-过滤器风格适用于将系统分成若独立的步骤
7. 主程序/子程序和面向对象的架构风格可用于对组件内部进行设计
8. 虚拟机风格经常用于构造解释器或专家系统
9. C/和B/S风格适合于数据和处理分布在一定范围，通过网络链接构成系统
10. 平台/插件风格适用于具有插件扩展功能的应用程序
11. MVC风格被广泛的应用于用户交互程序的设计
12. SOA风格应用在企业集成等方面
13. C2风格适用于GUI软件开发，用以构建灵活和可扩展的应用系统等