软件架构模式笔记

本文内容整理自Mark Richards所著书籍《软件架构模式》(Software Architecture Patterns)。

分层架构
模式特点

模式分析

事件驱动架构
中介Mediator拓扑结构

代理Broker拓扑结构

模式分析

补充

微内核架构
模式分析

分层架构

模式特点

分层架构模式中的组件被分成几个平行的层次，每一层都代表了应用的一个功能，它们是具体工作的高度抽象，能够实现某种特定的业务逻辑。大多数的分层架构都被从上到下分为四层：展示层、业务层、持久层和数据库层。

分层架构的一个突出特点是组件间关注点分离，一个层中的组件只会处理本层的逻辑。架构中的每一层都是封闭的，业务请求需要一层一层的传递，但当系统中大部分的请求都只是通过层传递，而层不对请求做任何处理时，可以适当开放一些层。

模式分析：

当不确定项目中使用什么架构时，可以使用分层架构

容易开发，适合大多数的商业商业项目

可测试性高，各个层之间不相互依赖，易于测试

整体灵活性低，经常出现组件间的紧耦合

不易部署，对组件的小改动可能影响整个程序的发布

性能低，业务请求要穿越所有层

伸缩性低，分层架构构建的应用都难以扩展

事件驱动架构

事件驱动架构是一种主流的异步分发事件架构模式，由高度解耦、单一目的的事件处理组件组成，这些组件负责异步接收和处理事件。事件驱动架构常用于设计高度可拓展的应用，使用这种架构模式架构应用时，必须不断地考虑哪些事件能被单独处理，哪些事件不能被单独处理，并为此设计相应事件处理器的处理粒度。

中介（Mediator）拓扑结构

在中介拓扑结构中主要有四种组件：事件队列（event queue）、事件中介（event mediator）、事件通道（event channel）和事件处理器（event processor）。

在事件驱动架构中主要有两种事件：初始事件和待处理事件。初始事件是事件中介所接收到的最原始的事件，没有经过其他组件的处理；待处理事件是有事件中介生成，由事件处理器接收的事件。不能把待处理事件看做初始事件经过处理后得到的事件。

事件中介通过事件通道将与初始事件的每一个执行步骤相关的特定待处理事件传递给事件处理器。事件队列将队列中的事件发送给事件中介，事件中介为每一个初始事件中的步骤发送一个特定的待处理事件到事件通道中，触发事件处理器接收和处理该待处理事件。需要注意的是：事件中介只知道初始事件中有哪些步骤需要被处理，而不会参与到对初始事件的必须处理的业务逻辑的实现之中。

一般来说，每个事件处理器组件都只完成一项唯一的任务，并且事件处理器在完成其特定的业务工作时不能依赖其他事件处理器。

代理（Broker）拓扑结构

在代理拓扑结构中主要包括两种组件：代理和事件处理器。代理可以被集中或者关联在一起使用，此外，代理中还可以包含所有事件流中使用的事件通道。存在于代理组件中的事件通道可以是消息队列、消息主题或者是两者的组合。代理拓扑结构适用于具有以下特征的场景：事件处理流相对比较简单，不需要使用核心的事件分配和调节机制以提高处理事件的效率。

代理模式中没有核心的事件中介，事件流在代理拓扑结构中通过一个轻量的消息代理将消息串联成链状分发至事件处理器组件中进行处理。每一个事件处理器只负责处理一个事件，并向外发送一个事件，以标明其刚刚执行的动作。在这其中有一个细节需要注意：处理初始事件后，由事件处理器发出的事件不被其他事件处理器接受、处理的情况时有发生，尤其是在为应用添加功能和进行功能扩展时。

代理拓扑结构的设计思想就是将对事件流的处理转换为对事件链的业务功能处理。在代理拓扑结构中，一旦某个事件处理器将事件传递给另一个事件处理器，那个这个事件处理器就不会与该事件的后续处理产生任何联系。

模式分析

整体灵活性高，能在不断改变的使用场景下快速响应

易于部署，其中代理拓扑结构比中介拓扑结构更易进行事件调度

可测试性低需要特定的测试工具来产生事件，其异步处理的特性也为单元测试带来了一定困难

性能高，高度解耦、异步并行操作大大减少了消息传递过程的时间开销

伸缩性高，事件处理器能够单独进行细粒度的扩展而不会影响其他事件处理器

不易开发，需要考虑异步处理机制、协议创建流程和错误环境控制

补充（？）

中介（Mediator）拓扑架构会统一管理所有事件，将事件拆分并分发给事件处理器；

代理（Broker）拓扑架构不拆分事件，直接将事件发送给事件处理器，事件处理器指处理自己能够处理的部分，忽略自己无法处理的部分，然后将事件继续传递给其他事件处理器处理；

另外Proxy模式需要开发者手动拆分事件然后交给Proxy。

微内核架构

微内核架构模式（也称为插件化架构模式）是基于产品的应用程序的第一选择，也可以将其嵌入到其他架构模式中。微内核应用模式可以通过插件的形式添加额外的特性到核心系统中，这提供了良好的扩展性，也使得新特性与核心系统隔离开来。

微内核架构主要需要考虑两个方面：核心系统和插件模块。应用逻辑被划分为独立的插件模块和核心系统，核心系统通常是为特定的条件定义了通用的业务逻辑，而插件模块根据这些规则实现了具体的业务逻辑。微内核本身没有指定任何的实现方式，唯一的规定就是插件模块之间不要产生依赖。

核心系统需要了解插件模块的可用性以及如何获取它们。一个通用的方法是使用插件注册表，这个注册表中含有每个插件模块的信息，包括它们的名字、数据规约以及远程访问协议。

插件和核心系统的通信规范包含标准规范和自定义规范。自定义规范的典型使用场景是插件组件是被第三方构建的。在这种情况下，通常是在第三方插件规约和核心系统的标准规约间创建一个Adapter来使核心系统不需要知道插件模块的具体细节。当创建标准规范时，从一开始就创建一个版本策略是非常重要的。

模式分析

整体灵活性高，能够快速适应不断变化的环境

易于部署，插件可以在运行时被动态的添加到核心系统中

可测试性高，插件模块能够独立的进行测试

性能高，可以只加载需要的模块，移除消耗资源但是没用的功能

伸缩性低，微内核架构的系统通常都比较小

不易于开发，需要考虑设计和规约管理