在讲到软件架构的概念时，首先我们要了解到，架构是在做什么样的事情，它在整个软件开发周期中所属什么样的位置。

之前学习软件工程时，我们学到了开发模型，里面涉及到需求分析，概要设计，详细设计，编码，测试。但事实上，没有提到架构这个东西。

为什么这么重要的东西没有在软件开发模型体现呢，其实是因为软件架构的兴起是滞后于软件开发模型的。比如瀑布模型，是用结构化的方式设计的，也就是面向过程的程序，那时候是没有涉及到架构的概念的。

其实架构设计就放在原来的需求分析之后，软件设计之前。因为需求分析比较偏向于业务的（一般需求来自于客户的业务），而软件设计是偏向技术，就是利用技术去完成需求所定义的内容。这个之间就很可能出现断代鸿沟，因为客户方更懂业务，需求分析是大量跟客户做对接，而技术人员就是拿着这个需求规格说明说去实现，但是技术人员不懂业务，就可能出现一个需求规格书转化为技术的过程会出现问题，因为各自的技术人员实现出来的东西不一样。

所以就需要架构设计这个环节，架构师需要理解需求，然后将需求砍成多个板块，然后把每个板块去完成一部分需求，从而简化需求。

1、软件架构相关概念

软件架构风格概念

软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式（也叫做架构模式）。架构风格定义一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构建和连接件类型，而这组约束指出系统是如何将这些构建和连接件组合起来的。

软件架构概念

软件架构为软件系统提供了一个结构，行为和属性的高级抽象，由构成系统的元素描述，这些元素的相互作用，指导元素集成的模式以及这些模式的约束组成。

软件架构是项目干系人进行交流的手段，明确了对系统实现的约束条件，决定了开发和维护组织的组织结构，制约着系统的质量属性。

软件架构使推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训的基础。

软件架构是可传递和可复用的模型，通过研究软件架构可以预测软件的质量。

2、软件架构的发展历史

• 无架构阶段：主要使用汇编语言，并且基本使用命令，没有架构的概念
• 萌芽阶段：开始做程序结构设计，做面向过程开发，比如由顺序，分支，循环等结构
• 初级阶段：开始使用统一建模语言（UML）
• 高级阶段：使用4 1视图，做面向对象的设计了

3、软件架构建模

• 结构模型（静态）：以架构的构建、连接件和其他概念来刻画结构
• 框架模型：不太侧重描述结构的细节而更侧重于整体的结构
• 动态模型：系统的“大颗粒”的行为性质
• 过程模型：构建系统的步骤和过程
• 功能模型：由一组功能构建按层次组成，下层向上层提供服务

以上概念了解即可，不是重点

• 开发视图：对应了UML的实现视图，主要针对的是编程人员，关注的是软件管理，也就是源代码
• 进程视图：对应了UML的进程视图，主要针对的是系统集成人员，关注的是性能的可扩充性、吞吐量等。其实就是关注的并发
• 逻辑视图：对应了UML的逻辑视图，针对的是最终用户，关注的是功能需求，也就是系统有哪些功能
• 物理视图：对应了UML的部署试图，针对的是系统网络工程人员，关注的是系统的拓扑、安装、通信等。其实就是关注软件到硬件的映射关系
• 场景：对应了UML的用例视图，展示了系统的外部人员与系统的交互

其实架构的4 1视图也是一个化繁为简的过程，就是从不同维度去看问题，从而简化问题。

4、软件架构风格（重要）

• 软件架构的一个核心问题是能否达到架构级的软件复用
• 架构风格反应了领域中众多系统所共有的结构和语义特征，并知道如何将各个构建有效地组织成一个完整的系统
• 架构风格定义了用于描述系统的术语表和一组指导构建系统的规则

软件架构到底有哪些风格呢？

• 数据流风格
• 批处理序列、管道-过滤器。比如我们的Flink做批量流处理，实时流处理，就是数据流风格
• 调用/返回风格
• 主程序/子程序、面向对象、层次结构。我们的B/S架构风格，提供一个restful接口，发送请求也就返回。
• 独立构建风格
• 进程通信、事件驱动系统（隐式调用）。事件驱动系统现在也是很多
• 虚拟机风格
• 解释器、基于规则的系统。比如工作流引擎就是解释器。比如风控系统，需要编写大量风控规则来拦截风险交易，就是基于规则的系统。
• 仓库风格
• 数据库系统、超文本系统、黑板系统。现在是系统肯定离不开数据库。

这几种架构风格不会涵盖所有的架构风格，因为当时有些架构风格还没产生，现在又没有专门的归类，所以存在不属于这几种风格的架构风格。

所以虽然我们有很多分类，但是我们使用时，基本都是混合使用，一个系统一般都包含多种风格。

4.1、数据流风格

过滤器：对应了我们平常的函数，方法这些

管道：就是连接过滤器的东西，可以理解为一些调用的机制，就是管道

其实批处理和管道-过滤器的示意图都是差不多的，只是批处理是一般处理事后数据，一批一批的处理。并且批处理的数据必须是完整的，以整体的方式传递。

管道-过滤器一般是可以进行实时的流处理，一般针对单条数据，单个单个的处理。支持流式数据处理，也就是处理数据流。

一般类似Flink这样的框架就是批流一体的处理框架，既可以批量处理数据（一般是处理事后/非实时的数据），也可以进行流式处理数据（一般是事中/实时）。

批处理序列

构件为一系列固定顺序的计算单元，构件之间只通过数据传递交互。每个处理步骤是一个独立的程序，每一步必须再其前一步结束后开始。数据必须是完整的，以整体的方式传递。

管道-过滤器

每个构件都有一组输入和输出，构件读取输入的数据流，经过内部处理，然后产生输出数据。

这个过程冗长是通过输入数据流的变换或计算来完成的，包括通过计算和增加信息以丰富数据，通过浓缩和删除以精简数据，通过改变记录方式以转化数据和递增的转换数据等。

这里的构件称为过滤器，连接件就是数据流传输的管道，将一个过滤器的输出传到另一个过滤器的输入。

早期编译器就是采用在这种架构，要一步一步的处理，均可考虑采用此架构风格。因为早期代码是一步一步往下处理，所以早期编译器使用这种处理方式。

4.2、调用/返回风格

调用/返回风格是应用最为广泛的架构风格，每一个系统都逃不开调用/返回风格。一般都是定义一个接口，供前端调用，然后返回数据给前端，这就是调用/返回。所以它无处不在。

主程序/子程序

单线程控制，把问题划分为若干个处理步骤，构件即为主程序和子程序，子程序通常可合成为模块。

过程调用作为交互机制，即充当连接件的角色。调用关系具有层次性，其语义逻辑表现为主程序的正确性取决于它滴哦安永的子程序的正确性。

面向对象

构件是对象，对象是抽象数据类型的实例。在抽象数据类型中，数据的表示和它们的相应操作被封装起来，对象的行为体现在其接受和请求的动作。

连接件即是对象交互的方式，对象是通过函数或过程的调用来交互的。

层次结构

构件组织成一个层次结构，连接件通过决定层次间如何交互的协议来定义。每层为上一层提供服务，使用下一层的服务，只能见到与自己相邻的层。

通过层次结构，可以将大的问题分解为若干个渐进的小问题逐步解决，可以隐藏问题的复杂度。修改某一层，最多影响其相邻的两层（通常只能影响上层）。

优点

• 这种风格支持基于可增加抽象层的设计，允许将一个复杂问题分解为一个增量步骤序列实现。
• 不同的层次处于不同的抽象级别，越靠近底层，抽象级别越高，越靠近顶层，抽象级别越低
• 由于每一层最多只影响两层，同时只要给邻居层提供相同的接口，允许每层用不同的方法实现，同样为软件复用提供了强大的支持。

缺点

• 并不是每个系统都可以很容易的划分为分层的模式
• 很难找到一个合适的，正确的层次抽象方法

分层思想

所以现在我们的架构设计一般都是要分层调用的，比如后台的接口的controller（控制器层）调用service（业务层），再调用dao层（数据处理层）然后再一层一层的返回。这就是分层的思想在里面。

但是有些系统也不适合分层，因为分层太多了可能导致效率，性能。所以一般我们的后端分层都是三层，再加上前端调用，前端又有MVVM模式，所以一般在3-7层。函数调用一般不会超过7层。

4.3、独立构件风格

封装构件的时候，保证构件的独立性。其实就是不直接关联呗。比如我们的消息中间件进行解耦。或者某个事件进行处理，通过事件监听器来处理，从而降低关联性。再比如我们系统间的调用，使用RPC来解耦，调用远程就像调用本地一样，也是一种解耦机制。

进程通信

构件是独立的过程，连接件是消息传递。构件通常命名过程，雄安锡传递的方式可以是点对点，异步或同步方式，以及RPC【远程过程（方法）调用】等。

事件驱动系统（隐式调用）

构件不直接调用一个过程，而是通过广播一个或多个事件。

构件中的过程在一个或多个事件中注册，当某个事件被出发时，系统自动调用在事件中注册的所有过程。一个事件的出发就导致另一个模块中的过程调用。

这种风格中的构件时匿名的过程，它们之间交互的连接件往往是以过程之间的隐式调用来实现的。

优点

主要的优点是为软件复用提供了强大的支持，为构件的维护和演化带来了方便。

缺点

缺点是构件放弃了对系统计算的控制

4.4、虚拟机风格

一般是适用于存在自定义的场景，比如自定义风控规则，然后解释器来解析规则代码.

解释器

解释器通常包括一个完成解释工作的解释引擎，一个包含被解释的代码的存储区，一个记录解释器引擎当前工作状态的数据结构，以及一个记录源代码被解释器执行的进度的数据结构。

具有解释器风格的软件中有含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用。

缺点是执行效率比较低

基于规则的系统

基于规则的系统包括规则集，规则解释器，规则/数据选择器和工作内存，一般用在人工智能领域和DSS中。一般还有风控规则引擎系统，决策流引擎系统等。

4.5、仓库风格

仓库风格中构件分为两种：一种是中央数据结构，保存系统的当前状态。另一种是独立构件，对中央数据存储进行操作。

其实就是有一个中心仓库, 然后有一堆的处理部件,这些部件都对这个中心仓库进行处理.比如我们的数据库,其实本身就是一个数据库系统.

数据库系统

其实就是我们平常使用的数据库mysql, oracle等

黑板系统

包括知识源、黑板和控制三部分。

知识源包括如果独立计算的不同单元，提供解决问题的知识。知识源响应黑板的变化，也只修改黑板。

黑板是一个全局数据库，包含问题域解空间的全部状态，是知识源相互作用的唯一媒介。知识源响应是通过黑板状态的变化来控制的。

黑板系统通常应用在对于解决问题没有确定性算法的软件中（信号处理，问题划分,语音识别和编译器优化等）

其实黑板系统看上去与数据库系统一样,因为就是按照数据库系统思想去做的,所以也不奇怪.

为什么叫黑板系统呢, 思想就是来自现实中教学的黑板, 它会把一个公共的数据区域, 不但作为存储的位置, 而且作为一种数据传递, 控制的一种机制.

比如老师, 学生通过黑板交换数据, 也就是老师把意见卸载黑板上, 学生也把意见写在黑板上.所以有一些数据传递共享的思想在里面.

超文本系统

构件以网状链接方式交互连接，用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。

超文本是一种非线性的网状信息组织方法，它以节点为基本单位，链作为节点之间的联想式关联。超文本系统通常应用在互联网领域。

现代集成编译环境一般采用这种结构风格。

5、小结

架构风格其实是很重要的知识,我们先了解这五种架构风格, 我们之前提到除了这物种风格之外, 还有一些没有收录在这几种风格之内的, 下一次会去做一个了解. 学无止境,继续加油!