过去了三周，终于有机会把之前落下的周记补上。这周的架构师学习周记，主要整理了关于软件架构风格的相关知识。
1、什么是软件架构风格
软件架构风格就是描述某一特定应用领域中系统组织方式的惯用模式。架构风格反映了应用领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。
2、软件架构风格分类
Garlan和Shaw给出了通用架构风格的分类：
（1）数据流风格：批处理序列；管道过滤器。
（2）调用/返回风格：主程序/子程序；面向对象风格；层次结构风格。
（3）独立构建风格：进程通信；事件系统。
（4）虚拟机风格：解释器；基于规则的系统。
（5）仓库风格：数据库系统；超文本系统；黑板系统。
2.1 数据流风格
- 2.1.1 批处理序列
批处理风格的每一步处理都是独立的，并且每一步是顺序执行的。只有当前一步处理完，后一步处理才能开始。数据传达在每一步处理之间作为一个整体。比较适用于需要顺序执行的某些固定操作的场景，并且这种流程不经常进行变化。
批处理的典型应用：
（1）经典数据处理；
（2）程序开发；
（3）Windows下的BAT程序就是这种应用的典型实例。
- 2.1.2 管道/过滤器
在管道/过滤器风格的软件架构中，每个构件都有一个输入和输出，构件读取输入的数据，通过内部处理，产生输出数据流。这里的构件就是过滤器，而这种风格的连接件就像是数据流传输的管道，把一个过滤器的输出数据流直接传输到另一个过滤器，作为它的输入数据。管道/过滤器的典型应用：
（1）UNIX shell 编写的程序；
（2）传统的编译器：一个阶段（包括词法分析、语法分析、语义分析和代码生成）的输出是另一个阶段的输入。
优点
（1）使得软构件具有良好的隐蔽性和高内聚、低耦合的特点；
（2）将整个系统的输入输出行为看成是多个过滤器的行为合集；
（3）支持软件复用（只要满足两个过滤器之间传送数据的要求，任何两个过滤器都可以被连接起来）；
（4）系统维护和增强系统性能简单（新的过滤器可以随时加入到系统中，旧的过滤器也可以随时被替换）；
（5）允许对一些吞吐量、死锁等属性的分析；
（6）支持并行执行。
缺点
（1）通常导致进程成为批处理的结构。这是因为虽然过滤器可以增量式地处理数据，但是它们是独立的，所以设计者必须将每个过滤器看成是一个完整的从输入到输出的转换；
（2）不适合处理交互的应用。当需要增量地显示改变是，这个问题尤为严重；
（3）因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样导致了系统性能的下降，并增加了编写过滤器的复杂性。
2.2 调用/返回风格
- 2.2.1 主程序/子程序
主程序/子程序风格是结构化开发时期的经典架构风格。这种风格一般采用单线程控制，把问题划分成若干处理步骤，构件就是主程序和子程序，主程序依次调用子程序，完成相关的处理动作。过程调用作为交互机制，充当了该架构的连接件。
- 2.2.2 面向对象风格
这种风格建立在数据抽象和面向对象的基础之上，数据的表示和它们的相应操作被封装在一个抽象数据类型或对象中。这种风格的构件就是对象，对象维护自身的完整性，通过函数和过程调用来进行交互（通过消息机制进行对象间的通信）。特点
（1）对象负责维护其表示的完整性；
（2）对象的表示对其他对象而言是隐蔽的。因为一个对象对它的客户隐藏了自己的表示，所以这些对象可以不影响它的客户就能改变其实现方法。
优点
（1）因为对象对其他对象隐藏它的表示，所以改变一个对象的表示，并不会对其他对象造成影响；
（2）设计者可以将一些数据存取操作的问题分解成一些交互的代理程序的集合。
缺点
（1）为了使一个对象和另外一个对象通过过程调用等进行交互，必须知道对象的标识。所以只要一个对象的标识改变了，就必须修改所有其他明确调用它的对象；
（2）必须修改所有显式调用它的其他对象，并消除因此带来的一些副作用。例如，如果A使用了对象B，C也使用了对象B，那么，C对B的使用所造成的对A的影响可能是料想不到的。
- 2.2.3 层次结构风格
主要的特征就是每一层只为上层进行服务，并作为下层的客户，内部的层一般只对相邻的层可见。最广泛的应用就是分层通信协议。这种架构风格支持功能增强和复用，但是层次结构风格需要特别注意对系统性能的考虑，划分的层次越多，层与层之间的交互成本就越高，整体的系统性能就越低，而且在实际操作中，往往很难找到一个合适的、正确的层次抽象方法。
2.3 独立构件风格
独立构件风格主要强调系统中的每个构件都是相对独立的个体，它们之间不直接通信，以降低耦合度，提升灵活性。
- 2.3.1 进程通信架构风格
进程通信架构风格：构件是独立的过程，连接件是消息传递。这种风格的特点是构件通常是命名过程，消息传递的方式可以是点对点、异步和同步方式以及远程过程调用等。
- 2.3.2 事件系统风格
基于事件的隐式调用风格，思想是Observer设计模式类似，构件不直接调用一个过程，而是通过触发或广播一个或多个事件。系统中其他构件中的过程，在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个时间中注册的所有过程，这样，一个事件的触发就导致了另一个模块中的过程调用。特点
主要特点是事件的触发者并不知道哪些构件会被这些事件影响。这样不能假定构件的处理顺序，甚至不知道哪些过程会被调用，因此，许多隐式调用的系统也包含显式调用作为构件交互的补充形式。
优点
（1）为软件重用提供了强大的支持（当需要将一个构件加入到现存系统中时，只需要将它注册到系统的事件中）。
（2）为改进系统带来了方便（当用一个构件替换另一个构件时，不会影响到其他构件的接口）。
缺点
（1）构件放弃了对系统计算的控制。一个构件触发了一个事件时，不能确定其他构件是否会影响它。而且即使它知道了事件注册了哪些构件的过程，它也不能保证这些过程被调用的顺序。
（2）数据交换的问题。有时数据可能被一个事件传递，但另一些情况下，基于事件的系统必须依靠一个共享的仓库进行数据交互。在这种情况下，全局性能和资源管理便成了问题。
2.4 虚拟机风格
虚拟机风格的基本思想是人为构建一个运行环境，在这个环境上，可以解析与运行自定义的一些语言，这样来增加架构的灵活性。
- 2.4.1 解释器风格
一个解释器通常包括完成解释工作的解释引擎，一个包含将被解释的代码的存储区，一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行进度的数据结构。解释器通常被用来建立一种虚拟机以弥合程序语义与硬件语义之间的差异。其缺点 是执行效率较低。典型的例子就是专家系统。
- 2.4.1 基于规则的系统风格
基于规则的系统包括规则集、规则解释器、规则/数据选择器及工作内存。适合根据外部事件，以自身状态为基础，自动进行处理和动作的场景。
2.5 仓库风格
在仓库风格中，有两种不同的构件： 中央数据结构说明当前状态，独立构件在中央数据存储上执行，仓库与外购件间的相互作用在系统中会有大的变化。
仓库风格中，主要有：数据库系统、超文本系统、黑板风格等。
数据库系统风格的构件主要有两大类：一个是中央共享数据源，保存当前系统的数据状态；另一个是多个独立处理元素，处理元素对数据元素进行操作。而超文本系统的典型代表，就是早期的静态页面。
-
黑板架构风格
适用于处理复杂的非结构化问题，能在求解过程中综合运用多种不同知识源，使得问题的表达、组织和求解变得比较容易，是一种问题求解模型。
黑板系统主要由三部分组成：
（1）知识源。知识源中包含独立的、与应用程序相关的知识，知识源之间不直接进行通信，它们之间的交互只通过黑板来完成。
（2）黑板（共享数据）。黑板数据是按照应用程序相关的层次来组织解决问题的数据，知识源通过不断地改变黑板数据来解决问题。
（3）控制。控制完全由黑板的状态驱动，黑板状态的改变决定使用的特定知识。
2.6 总结
在学习架构风格的过程中，我遇到了很多困难和疑问，因为架构风格是一个高度抽象的结构，理解起来比较吃力，所以建议学习过程中，最好上网找一些具体的实例加深理解和学习。另外，可以通过理论去联系实际，可以想一想实际项目中，都用到了哪些架构风格，或者说这种架构风格在实际项目中有没有被应用到，这样才能把每一种架构风格吃透。
另外需要指出的一点，软件架构风格是一个大粒度的软件复用，而且架构设计人员由于个人的视角和经历不同，设计的时候出发点会不一样，所以，在选择或者设计一个架构风格时，必须根据特定项目的具体情况、特点进行分析对比，多和其他项目成员沟通。这样才能保证我们选择的架构风格是最贴近于业务需求的，而不是因为某一个架构风格比较流行就去选择这个架构风格。
