软件体系架构风格21种整理

笔记使用MD写的，有很多本地插图，需要有图电子版可以去下载

题目

给“同学带饭”的架构风格

无约束：事件架构风格

黑板架构风格

基于规则的架构风格

什么架构风格的构件可以适应变动

插件、C2

概述

软件危机

软件危机是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。体现在：

• 软件开发进度难以预测
• 软件开发成本难以控制
• 用户对产品功能难以满足
• 软件产品质量无法保证

软件架构的主要思想和特征

软件架构在高级层次上对软件进行描述，便于软件开发过程中各个视角（用户、业务和系统）的统一，能够及早发现开发中的问题并支持各种解决方案的评估与预测。

软件架构的意义贯穿软件生命周期的各个阶段。

软件架构的两个主要焦点集中于系统的总体结构以及需求和实现之间的对应。

软件架构的概念

软件架构驳杂多端，其中影响较大的定义有两派：组成派和决策派。

组成派

关注软件本身，将软件看作组件和交互的集合。反映系统由哪些部分组成，以及这些部分是如何组成的，强调软件系统的整体结构和配置。

决策派

关注于软件架构中的实体（人），将软件架构视为一系列重要设计决策的集合。软件设计实际上是开发人员意志和决策在软件开发过程中的体现，软件架构更是高层领导和架构师意志和决策的体现，强调设计决策，更加注重架构风格和模式的选择。

其他定义

软件架构风格与模式

架构风格的定义

典型的软件架构风格

数据流风格

基本组件：数据处理单元

连接件：数据流

接口角色：Reader和Writer

在纯数据流系统中，处理之间除了数据交换没有任何其他的交互。

1. 批处理风格

基本组件：独立的应用程序

连接件：完整的数据

特点：

• 几乎线性
• 每个处理步骤都是一个独立的程序
• 每一步在前一步结束后才开始
• 数据必须是完整的，以整体的方式传播

public class KWIC2 {
    public static void main(String[] args) {
        getContext(new File("fileTemp/context.txt"));
    }

    private static void getContext(File file) {
        //读取文件
        //循环移位
        loopShift(strList);
    }

    private static void loopShift(List<String[]> strList) {
        //排序
        sort(shiftStrList);
    }

    private static void sort(List<String[]> shiftStrList) {
        shiftStrList.sort(Comparator.comparing(o -> o[0]));
        //输出
        printf(shiftStrList);
    }

    private static void printf(List<String[]> result) {
        for (String[] strings : result) {
            for (String string : strings) {
                System.out.printf(string + " ");
            }
            System.out.println();
        }
    }
}

2. 管道/过滤器风格

• 结果的正确性不依赖于各个过滤器运行的先后次序。
• **支持功能模块的复用。**具有较强的可维护性和可扩展性。
• 由于每个组件行为不受其他组件的影响，使得软件组织具有良好的隐蔽性和高内聚、低耦合、可并发的特点。

优点：

1. 简单性。
2. 支持复用。
3. 系统具有可扩展性和可进化型。
4. 系统并发性（每个过滤器可以独立运行，不同子任务可以并行执行，提高效率）。
5. 便于系统分析。

缺点：

1. 系统处理工程是批处理方式。
2. 不适合用来设计交互式应用系统。
3. 由于没有通用的数据传输标准，因此每个过滤器都需要解析输入数据和合成数据。
4. 难以进行错误处理。

调用/返回风格

3.主程序/子程序风格

组件：主程序和子程序

连接件：调用-返回机制

拓扑结构：层次化结构

约束：单线程

优点：相对于非结构化设计逻辑清晰；逐步细化，将大系统分解为若干模块。

缺点：在规模变大时会难理解、难测试、难维护；对数据存储格式的变化将会影响到几乎所有的模块；难以支持有效的复用。

public static void main(String[] args) {
        //读取文件
        List<String[]> result = getContext(new File("fileTemp/context.txt"));
        //循环移位
        result = loopShift(result);
        //排序
        sort(result);
        //输出
        printf(result);
}

4.面向对象风格

从现实世界中客观存在的事物出发，直接对问题域进行自然抽象。

5.层次化风格

层次化早已成为一种复杂系统设计的普遍性原则。

优点：

• 允许将一个复杂问题分解成一个增量步骤序列。
• 支持扩展。每一层的改变最多只影响相邻层。
• 支持重用。

缺点：

风格变种：12.客户机/服务器风格

两层C/S架构

三层C/S架构

风格变种：13.浏览器/服务器风格

独立组件风格

6. 事件驱动风格

• 显式调用

各个构件之间的互动是由显性调用函数或者程序完成的。

• 隐式调用

软件更多地变成被动性系统，构建持续地与其所处地环境打交道，但是不知道确切地交互次序。

◦ 组件不直接调用一个过程，而是发布或广播一个或多个事件。

◦ 系统中的其他组件通过注册与一个事件关联起来的过程，来表示对某一个事件感兴趣。当这个事件发生时，系统本身会调用所有注册了这个事件的过程。这样一个事件的激发会导致其它模块中过程的隐式调用。

缺点：

1. 该风格中，正确性验证成为一个问题。
2. 可能发生阻塞，无全局管理。
3. 存在数据交换问题。

优点：

1. 事件声明者不需要知道哪些组件会影响事件，组件之间关联较弱。一个组件出错将不会影响其他构件
2. 提高软件复用能力。只要在系统事件中注册组件的过程，就可以将该组件集成到系统中。
3. 系统便于升级。只要组件名和事件中所注册的过程名保持不变，原有组件就可以被新组件替代。

虚拟机风格

Java class文件并不是机器代码或者目标代码，而是一种具有标准中间格式的二进制文件，无法直接在任何OS平台上执行；Java class必须在JVM的支持下才能真正执行。

不管何种类别的虚拟机，本质上都是在高层次抽象的用户与低层次抽象的OS/硬件之间建立一道屏障。

如何把上层应用的请求映射到下层OS/ 硬件系统的执行？

7. 解释器风格

解释器

解释器的执行速度要慢于编译器产生的目标代码的执行速度，但是却低于编译器“编译+链接+执行”的总时间。

优点

◦ （1）它有利于实现程序的可移植性和语言的跨平台能力；

◦ （2）可以对未来的硬件进行模拟和仿真，能够降低测试所带来的复杂性和昂贵花费

缺点

◦ 额外的间接层次导致了系统性能的下降，如在不引入JIT（Just In Time）技术的情况下，Java应用程序的运行速度相当慢。

编译器

8.基于规则的系统风格

基本过程

◦ 使用规则定义语言（如：基于XML）将这些变化部分定义为“规则”；

◦ 在程序运行时，规则引擎根据程序执行的当前状态，判断需要调用并执行哪些规则，进而通过“解释器”的方式来解释执行这些规则。

◦ 其它直接写在源代码中的程序，仍然通过传统的“编译”或“解释”的办法加以执行。

将业务逻辑中可能频繁发生变化的代码从源代码中分离出来。

优点：

◦ 降低了修改业务逻辑的成本

◦ 缩短了开发时间

◦ 将规则外部化，可在多个应用之间共享

◦ 对规则的改变将非常迅速并且具有较低的风险

以数据为中心的风格

9.仓库风格

优点：

• 便于模块间的数据共享
• 方便模块的添加、更新和删除
• 避免了知识源不必要的重复存储

缺点：

• 对于各个模块，需要一定的同步/加锁机制保证数据结构的完整性和一致性

10.黑板系统风格

特点：没有可行的解决方案，将原始数据转换为高级数据结构。存在这些问题的领域包括视觉识别、图像识别、语音识别和监控等。算法的执行顺序不确定时还可能要求执行并行性。

优点：

◦ （1）便于多客户共享大量数据，他们不关心数据何时有的、谁提供的、怎样提供的。

◦ （2）既便于添加新的作为知识源代理的应用程序，也便于扩展共享的黑板数据结构。

◦ （3）知识源可重用。

◦ （4）支持容错性和健壮性。

缺点：

◦ （1）不同的知识源代理对于共享数据结构要达成一致，而且，这也造成对黑板数据结构的修改较为困难——要考虑到各个代理的调用。

◦ （2）需要一定的同步/加锁机制保证数据结构的完整性和一致性，增大了系统复杂度。

• 知识源：包含独立的、与应用程序相关的知识，知识源之间不直接通信。
• 控制器：完全由黑板的状态驱动，黑板的状态决定了需要使用的特定知识。
• 黑板：全局数据库。按照与应用程序相关的层次来组织并解决问题的数据.

仓库风格和黑板风格的区别：

如果由输入流中的事件来驱动系统进行信息处理，把执行结构存储到中央数据单元，则这个系统就是仓库风格系统。

如果由中央数据单元的当前状态来驱动系统运行，则这个系统就是黑板应用系统。

其他软件架构风格

11.C2风格（层次）

C2风格的主要思想来源于Chiron - 1用户界面系统，因此又被命名为Chiron - 2，简称C2。

概括为：通过连接件绑定在一起的按照一组规则运作的并行组件网络。该规则规定了所有组件之间的交互必须通过异步消息机制来实现。

**C2连接件：**负责把构件绑定在一起，其上可以连接任何数量的构建和连接件。主要职责为：消息的路由和广播；消息的过滤。

优点

◦ （1）可使用任何编程语言开发组件，组件重用和替换易实现；

◦ （2）由于组件之间相对独立，依赖较小，因而该风格具有一定扩展能力，可支持不同粒度 的组件；

◦ （3）组件不需共享地址空间；

◦ （4）可实现多个用户和多个系统之间的交互；

◦ （5）可使用多个工具集和多种媒体类型，动态更新系统框架结构。

缺点

◦ 不太适合大规模流式风格系统，以及对数据库使用比较频繁的使用。

13.平台/插件风格

 优点：

◦ （1）降低系统各模块之间的互依赖性

◦ （2）系统模块独立开发、部署、维护

◦ （3）根据需求动态的组装、分离系统

 缺点

◦ 插件是别人开发的可以用到某主程序中的，只服务于该主程序，可重用性差。

14.面向Agent风格 ？

 优点

◦ 面向Agent的软件工程方法对于解决复杂问题是一种好的技术, 特别是对于分布开放异构的软件环境。

 缺点

◦ 大多数结构中Agent 自身缺乏社会性结构描述和与环境的交互。

15.面向方面软件架构风格 AOP Aspect Oriented Programming

应用AOP的主要目的----尽量分离“技术问题实现”和“业务问题实现”，例如：日志功能

16.面向服务架构风格

SOA（面向服务的架构）是什么？ (biancheng.net)

优点

◦ （1）灵活性，根据需求变化，重新编排服务。

◦ （2）对IT资产的复用。

◦ （3）使企业的信息化建设真正以业务为核心。业务人员根据需求编排服务，而不必考虑技术细节。

缺点

◦ （1）服务的划分很困难。

◦ （2）服务的编排是否得当。

◦ （3）如果选择的接口标准有问题，如主流的Web service之类，会带来系统的额外开销和不稳定性。

◦ （4）对IT硬件资产还谈不上复用。

◦ （5）目前主流实现方式接口很多，很难统一。

◦ （6）目前主流实现方式只局限于不带界面的服务的共享。

17.正交架构风格

正交软件架构是一种以垂直线索组件族为基础的层次化结构。

 优点

◦ （1）结构清晰，易于理解。由于线索功能相互独立，组件的位置可以清楚地说明它所实现的抽象层次和负担的功能。

◦ （2）易修改，可维护性强。由于线索之间是 相互独立的，所以对一个线索的修改不会影响到其他线索。

◦ （3）**可移植性强，重用粒度大。**因为正交结构可以为一个领域内的所有应用程序所共享，这些软件有着相同或类似的层次和线索，可以实现架构级的重用。

缺点

◦ 在实际应用中，并不是所有软件系统都能完全正交化，或者有时完全正交化的成本太高。因此，在进行应用项目的软件架构设计时，必须反复权衡进一步正交化的额外开销与所得到的更好的性能之间的关系。

18.异构风格

在实际应用中，各种软件架构并不是独立存在的，在一个系统中，往往会有多种架构共存和相互融合，形成更复杂的框架结构，即异构架构。

 优点

◦ （1）选择异构架构风格，可以实现遗留代码的重用。

◦ （2）在某一单位中，规定了共享软件包和某些标准，但仍会存在解释和表示习惯上的不同。选择异构架构风格，可以解决这一问题。

 缺点

◦ 不同风格之间的兼容问题有时很难解决

19.基于层次消息总线的架构风格

1. 基本思想：

   1. 基于层次消息总线，支持组件的分布和并发，组件之间通过消息总线进行通讯
   2. 消息总线是系统的连接件，负责消息的分派、传递和过滤以及处理结果的返回
   3. 各组件挂接在消息总线上，向总线登记感兴趣的消息类型
   4. 不要求各个构建的物理分布，可较好的描述分布式并发系统

2. 优点

   1. 降低耦合性，增强重用性
   2. 可以动态增加和删除构件

3. 缺点

   1. 重用要求高，可重用性差

20.模型-视图-控制器风格

优点

多个视图与一个模型相对应，变化-传播机制确保相关视图都能够及时获取模型变化信息，从而使所有视图和控制器同步，便于维护
具有良好的一致性，由于模型独立于视图，因此可以方便的实现不同部分的移植
系统被分割成三个独立的部分，当功能发生变化时，改变其中的一个部分就能满足要求
缺点

增加了系统设计和运行复杂性
视图与控制器连接过于紧密，妨碍了二者的独立重用
视图访问模型的效率比较低，由于模型具有不同的操作接口，因此视图需要多次访问模型才能够获得足够的数据
频繁访问伪变化的数据，也将降低系统的性能

21.微服务架构风格

微服务架构风格的特点是：

◦ 围绕业务能力组织系统；

◦ 自动化部署；

◦ 智能化

◦ 对程序和数据的去中心化控制。

 这种风格可以设计出灵活、模块化且易扩展的架构。

微服务架构是面向服务架构的一个变形，由于它注重于单个服务的构建，能够轻松的增加、改进或删除服务，因此具有松耦合的特点。

使用微服务进行架构设计并非易事，因为使用微服务意味着需要管理分布式架构及接受其所带来的一系列挑战，包括管理网络延迟和不可靠性、容错能力、复杂服务的编排、数据一致性、事务管理以及负载均衡。