1、软件体系结构风格概述
软件体系结构风格是人们从大量实际的软件案例中提炼出来可以服用的架构层面解决的方案。
2、数据流风格
2.1原理与结构
数据流风格基本构件：处理
连接件：数据流
2.2、数据流风格子风格1：管道-过滤器风格
构件：过滤器
连接件：管道
工作原理： 递增的读取和消费数据流，过滤器在处理数据的时候不是收集然后再处理，而是在输入被完全消费之前，输出就产生了。
特点： 高并发，实时性。
例子：
1、编译器：
2、Unix管道
2.3、数据流风格子风格2：批处理风格
基本构件：独立的应用程序
连接件：某种类型的介质
特点：并发性差，延迟高
工作原理： 每一步处理都是独立的并且每一步都是顺序执行，只有在前一步结束后才能开始下一步的处理并且数据必须是完整的，以整体的方式来传递。
案例：
基于Eclipse的代码重复检测工具
2.4、管道-过滤器与批处理的比较
相似点： 两种子风格都把任务分解成一系列固定顺序的计算单元。彼此之间都只通过数据传递交互
不同点： 管道-过滤器风格中数据是增量式传递，并且构件的粒度较小，具有实时性，高并发的特点；而批处理风格则是采用整体传递数据的方式，构建力度较大，相应带来了高延迟，并发性差。
2.5、数据流风格的优缺点
优点： 由于构件之间仅仅通过数据进行交互，使得构建具有良好的隐蔽性和高内聚低耦合的特点；
并且只需要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可以被连接起来，从而支持良好的软件复用性。
新的过滤器也可以很方便的添加到现有系统中，替换旧的过滤器，系统维护和升级相对简单；
每个过滤器负责完成一个单独的任务，因此可以与其他任务并行执行，另外还允许对一些比如吞吐量，死锁等特性的分析。
缺点： 通常会导致系统进程成为批处理的结构，整体性能不高，不适合交互应用，由于每一个过滤器都成参加了解析和合成数据的工作，这样就导致了系统性能下降并且增强了编写过滤器的复杂性。
3、过程调用风格
3.1、主程序-子过程风格
构件：主程序，子程序
连接件：调用-返回机制
拓扑结构：层次化结构
本质：将大系统分解成为若干模块，主程序调用这些模块实现完整的系统功能。
优点： 有效地将一个比较复杂的程序系统设计任务分解成许多简单的，易于控制和处理的子任务，便于开发和维护，已被证明是成功的设计方法，可以被用于较大程序
缺点： 程序超过10万行的时候表现并不好，程序太大，开发太慢，测试也越来越困难。可重用性较差，难以开发大型软件和图形界面的应用软件。
3.2、面向对象风格
构件：类和对象
连接件：对象之间通过功能与函数调用实现交互
原理图：
优点： 一个对象对外隐藏了自己的信息，对象将数据与操作封装在了一起。
缺点： 首先需要管理大量的对象，难以确定合适的结构，另外若要调用另外一个对象，就必须要知道它的名称，而且随着继承引起的复杂度，会产生连锁反应。
与之形成对立的可以参考管道-过滤器风格，过滤器无需知道其他过滤器的任何信息
4、独立构件风格
4.1、进程通信体系结构风格
构件：独立的进程
连接件：消息传递
典型案例： 客户-服务器架构，其中服务器通常用来为一个或多个客户端提供数据服务，客户端则用来向服务器发出请求，针对这些请求服务器通过同步或异步方式进行请求响应。
4.2、基于事件的隐式调用风格
构件：对象或者过程
连接件：事件-过程绑定
原理图：
特点： 事件的触发这并不知道那些构件会被这些事件影响到，相互保持独立，这样就不能假定构件的处理顺序，甚至不知道哪些过程会被调用，并且哥哥构建彼此之间没有连接关系，各自独立存在，通过对事件的发布和注册实现关联。
典型案例：
MVC
事件调度策略：当事件发生时，已经向此事件注册过的过程被激发并执行，那么事件管理器该如何向这些过程分发相关的事件？
两种策略：
1、没有独立派遣模块的事件管理器
在没有独立派遣模块的事件系统中，每一个模块都被成为：被观察者/观察者，每一个模块都允许其他模块向自己所能发送的某些信息表明兴趣，党某一模块发出某一事件时，它自动将这些时间发布给哪些曾经向自己注册过此事件的模块。
2、带有独立派遣模块的事件管理器
再有独立调度模块的时间系统中，事件派遣模块负责接收到来的事件并派遣它们到其它模块，但是派遣器怎么样派遣又存在两种策略
一种是广播式：派遣模块将事件广播到所有的模块，但只有感兴趣的模块才去取事件并触发自身的行为；
一种是选择广播式：派遣模块将事件送到那些已经注册了的模块中。
选择广播式又有两种策略，点对点模式：基于消息队列，发布-订阅模式
点对点模式： 系统会配置一个队列管理器，定义一个命名的消息队列，某个应用向消息队列注册，以监听并处理被放置在队列里的事件，其他的应用连接到该队列并向其中发布事件，队列管理器管理存储这些消息，直到接收端的应用连接到队列，取回这些消息并加以处理，
注意： 消息只能够被唯一的消费者所消费，消费之后立即从队列中删除。
发布-订阅模式： 事件发布者向“主题”发布事件，订阅者向“主题”订阅事件
• 一个事件可以被多个订阅者消费；
• 事件在发送给订阅者之后，并不会马上从topic中删除，topic会在事件过期之后自动将其删除。
集成案例：股票交易市场
典型案例：
调试器
工作原理：其中编译器既是监听者又是处理者，先向调试器进行注册，表示对断点事件感兴趣，调试器一旦产生断点事件，断点事件就会被送到这三个已经表明兴趣的部分，然后文本编辑器会滚动屏幕到断点处，变量监视器会刷新变量的当前值，编译器会启动编译
事件系统优点： 能够很好地支持交互式系统，系统中的操作可以异步执行，不必同步等待执行结果，为软件复用提供了强大的支持，当需要将一个构件加入现存系统中时，只需要将它注册到系统的事件中，为系统的动态演化带来了方便，构件独立存在，当用一个构件代替另一个构件时，不会影响到其他构建的接口，对事件的并发处理将提高系统性能，另外，系统的健壮性也很好，一个构件出错不会影响其他构件。
缺点： 分布式的控制方式使得系统的同步、验证和调试变得异常困难。
构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其他构件是否会影响它。而且即使它知道事件注册了哪些构件的构成，它也不能保证这些过程被调用的顺序。
既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理存在问题。
5、层次风格
构件：各层次内部包含的构件
连接件：层间的交互协议
拓扑结构：分层
拓扑约束：对相邻层间交互的约束
规则：一般来说，一个子层只能与相邻的层进行交互，不能跨层交互。
分层风格与主程序-子过程风格的不同：
主程序-子过程风格 中的各个层次模块的功能具有同样的类型，主程序可以调用子程序，但是不能逆向调用，子程序只能通过上层转移来获得子子程序控制权。
分层风格 中各层模块具有不同类型的功能，各层模块之间存在回调的情况，上层模块调用下层模块不需要上上层模块赋予控制权
5.1、分层模式
严格分层/松散分层
严格分层： 严格分层系统要求严格遵循分层原则，限制一层中的构件只能与对等实体以及与它紧邻的下面一层进行交互。
严格分层优点：修改时相对简单
缺点：效率低
松散分层： 松散的分层应用程序放宽了此限制，它允许构件与位于它下面的任意层中的组件进行交互（注意:交互的方向依旧未变）
优点： 松散方法可以改善效率，因为系统不必将简单调用从一层转发到下一层。
缺点： 松散方法在层之间不提供相同的隔离级别，这使得在不影响较高层的情况下换出较低层变得更困难。
逻辑分层/物理分层
逻辑分层： 把软件中的相关工嗯呢该和组件分成独立的逻辑分组，一般是将一组相互协作的组件分组成逻辑层，每一个逻辑层都包含许多独立的组件类型并可以分组成子层，每一个子层执行特定类型的任务。
常见的逻辑分层：
物理分层：物理层描述的却是如何把功能和组件从物理上部署到独立服务器、计算机、网络或远程位置。
一般情况下，一个独立运行的服务器就是一个物理层。也有几个服务器组成一个层的情况，如集群服务器就可看作是同一个层。
逻辑层和物理层之间的映射存在如下三种情况：
1对1，即一个逻辑层运行在一个物理层；
1对多，即一个逻辑层运行在多个物理层；
多对1，多个逻辑层运行在一个物理层。
案例： 一个简单的用户信息查询程序三层逻辑架构
关于逻辑层与物理层的对应关系，目前逻辑分层是三层：表示层，业务逻辑层，数据访问层。若调用三台电脑分别运行以上三层，则物理分层也为三层，逻辑分层：物理分层=1:1
其余几个案例也可以适当的记一下：
DBMS中的“三级模式-两层映像”，
ISO/OSI网络分层模型：
5.2、层次风格优缺点
优点：
抽象。 层次风格把系统当作一个抽象整体来看的同时，提供了足够的细节来理解每一层的角色和职责以及层之间的关系。分层使设计者可以把一个复杂系统按自上而下抽象程度递增的步骤进行分解。
隔离。 不需要在设计阶段作有关数据类型、方法、属性和实现的假设，因为这些特性不会跨越层边界暴露。可以对单独的层进行技术升级，通过封装可以减少风险并且使得对整个系统的影响减少到最低程度。
可扩展性。 层次系统每一层最多和上下两层交互，对任一层功能的改变，最多只影响其他两层。
可管理性。核心关注点的分离有助于找到依赖，并将代码组织得更加易于管理。
性能。通过把逻辑层分布到多个物理层中，可以提高可伸缩性、容错性（fault tolerance）和性能。
可重用性。每一层提供的功能都是独立的和定义良好的。不同层之间有明确的接口，在解决一个新的问题时，使开发人员更容易地重用一个已有的层。
可测试性。由于有了明确定义的接口，以及可以在层接口的不同实现之间实现按需切换，可测试性明显增强了。
标准化。清晰定义并且广泛接受的抽象层次能够促进实现标准化的任务和接口开发，同样接口的不同实现能够互换使用。
缺点：
并不是每个系统都可以很容易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的功能综合起来；
效率的降低：
由分层风格构成的系统，运行效率往往低于整体结构。
在上层中的服务如果有很多依赖于最底层，则相关的数据必须通过一些中间层的若干次转化，才能传到；
很难找到合适的、正确的层次抽象方法：
层数太少，分层不能完全发挥这种风格的可复用性、可修改性和可移植性上的潜力。
层数过多，则引入不必要的复杂性和层间隔离冗余以及层间传输开销。
6、虚拟机风格
注意，虚拟机风格又是也称为解释器风格，解释器系统的核心也是虚拟机。
构件：虚拟机风格包括三个被动数据组件和一个主动组件，他们分别是被解释执行的程序，用于保存程序当前执行状态的数据组件，用于保存当前解释引擎状态的组件，以及虚拟机解释器引擎。也可以记作：存储区和解释引擎。
连接件：过程调用和直接存储访问。
6.1、解释器风格
从功能角度划分，解释器通常由微程序和解释器引擎和存储区，从基本构建角度看，包括模拟解释引擎和存储器
解释器风格的连接可以看做对存储区的数据访问。
解释器有三种策略：传统解释器（纯粹的解释执行），基于字节码的解释器（先编译后解释执行），JIT编译器（西安部分编译后解释执行）
传统解释器：
基于字节码的解释器
在该类解释器下，源代码首先被“编译”为高度压缩和优化的字节码，但并不是真正的机器目标代码，因而与硬件平台无关；
编译后得到的字节码然后被解释器加以解释
JIT解释器
在运行时，JIT会把翻译过来的机器码保存起来，以备下次使用。但是JIT只会对经常执行的字节码进行编译。如循环，高频度使用的方法等，它会以整个方法为单位，一次性将整个方法的字节码编译为本地机器码，然后直接运行编译后的机器码。
6.2、基于规则的系统
构件：工作存储区，知识库，规则解释器，规则与数据元素选择器。
连接件：对存储区的数据访问。
核心思想：将业务逻辑中可能频繁发生变化的代码从源代码中分离出来
优点： 降低了修改业务逻辑的成本，缩短了开发时间，将规则外部化，可在多个应用之间共享，对规则的改变将非常迅速并且具有较低的风险
6.3、二者的不同
解释器风格：在高级语言程序源代码和OS/硬件平台之间建立虚拟机环境；
基于规则的系统：在自然语言/XML的规则和高级语言的程序源代码之间建立虚拟机环境。
7、客户机/服务器风格
构件：客户机软件和服务器软件
连接件：一系列网络协议
7.1、胖瘦客户端
胖客户端：客户端执行大部分的数据处理操作
特点：
较低的服务器需求。与瘦客户端对应的服务器相比，胖客户端对应的服务器不需要达到同样高的性能（因为胖客户端自己就可以完成很多业务处理）。因此，可以使用非常便宜的服务器。
离线工作。胖客户端通常不需要和服务器之间维持长久的连接。
更好的多媒体性能。在网络带宽比较敏感的时候，胖客户端更擅长运行丰富的多媒体应用，例如，胖客户端非常适合于电子游戏。
更灵活。在某些个人电脑的操作系统上，软件产品都有它们自己的本地资源。在瘦客户端环境运行这类软件可能比较困难。
充分利用已有设备资源。现在很多人都拥有非常快速的个人电脑，他们已经不需要额外的花费就可以运行胖客户端软件了。
更高的服务器容量。客户端执行的工作越多，服务器所需要的工作就越少，这可以增加服务器支持的用户数量。
瘦客户端：客户端具有很少或没有业务逻辑
特点：
单点故障。服务器承担了大部分的业务处理，安全问题主要集中于服务器，易于维护，但服务器一旦崩溃，所有数据都会丢失。
廉价的客户端硬件。对客户端硬件的内存、硬盘容量以及CPU等要求不高，这也降低了客户端的功耗。
有限的显示性能。瘦客户端往往使用简单的直线、曲线和文字来优化显示性能，或通过缓存的位图数据来进行显示，很难支持复杂的交互式图形操作。
7.2、两层C/S结构
构件：数据库服务器，客户机应用程序
连接件：经由网络的调用返回机制或者事件机制
优点： 适合于轻量级事务，当业务逻辑较少变化以及用户数少于100时，两层C/S架构的性能较好
缺点：系统伸缩性差：当用户数超过100，性能急剧恶化，互操作性差：使用DBMS所提供的私有的数据编程语言来开发业务逻辑，降低了DBMS选择的灵活性，系统管理与配置成本高：当系统升级时，每个客户端都需要随之改变
7.3、三层C/S结构
优点： 在用户数目较多的情况下，三层C/S结构将极大改善性能与灵活性(通常可支持数百个甚至更多用户)；允许合理地划分三层结构的功能，使之在逻辑上保持
相对独立性，能提高系统和软件的可维护性和可扩展性；UI、BL、DB可以分别加以复用
允许更灵活有效地选用相应的平台和硬件系统，并且这些平台和各个组成部分可以具有良好的可升级性和开放性。
应用的各层可以并行开发，可以选择各自最适合的开发平台和开发语言。
利用功能层有效地隔离开表示层与数据层，未授权的用户难以绕过功能层而非法的访问数据层，为严格的安全管理奠定了坚实的基础。
将遗留系统移植到三层C/S下将非常容易；
缺点：三层C/S结构各层间的通信效率若不高，即使分配给各层的硬件能力很强，其作为整体来说也达不到所要求的性能。
设计时必须慎重考虑三层间的通信方法、通信频度及数据量，这和提高各层的独立性一样是三层C/S结构的关键问题。——分层风格的固有缺点
7.4、B/S模式
浏览器/服务器(B/S)是三层C/S风格的一种实现方式
优点： 基于B/S体系结构的软件，系统安装、修改和维护全在服务器端解决，系统维护成本低：
• 客户端无任何业务逻辑，用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级。
• 良好的灵活性和可扩展性：对于环境和应用条件经常变动的情况，只要对业务逻辑层实施相应的改变，就能够达到目的。
• 较好的安全性：在这种结构中，客户应用程序不能直接访问数据，应用服务器不仅可控制哪些数据被改变和被访问，而且还可控制数据的改变和访问方式 。
• 三层模式成为真正意义上的“瘦客户端”，从而具备了很高的稳定性、延展性和执行效率。
• 三层模式可以将服务集中在一起管理，统一服务于户端，从而具备了良好的容错能力和负载平衡能力。
缺点：客户端浏览器一般情况下以同步的请求/响应模式交换数据，每请求一次服务器就要刷新一次页面；
• 受HTTP协议“基于文本的数据交换”的限制，在数据查询等响应速度上，要远远低于C/S体系结构；
• 数据提交一般以页面为单位，数据的动态交互性不强，不利于在线事务处理(OLTP)应用；
• 受限于HTML的表达能力，难以支持复杂GUI (如报表等)