模式与策略

目录

一、什么是模式

二、模式

1、模块模式

1）分层模式（Layered Pattern） 

 2、组件和连接器模式

1）代理模式（Broker Pattern） 

2）MVC模式（Model-View-Controller Pattern） 

3）管道和过滤器模式（Pipe and Filter Pattern） 

4）客户端服务器（Client-Server Pattern） 

5）对等模式（Peer-to-Peer Pattern） 

6）面向服务架构模式（Service Oriented Architecture Pattern） 

7）发布-订阅模式（Publish-Subscribe Pattern） 

8）共享数据模式（Shared-Data Pattern）

3、分配模式

1）映射-减少模式（Map-Reduce Pattern）

2）多层模式（Multi-Tier Pattern）

三、策略和模式的关系

四、策略增加模式 

---

一、什么是模式

架构模式是一个在实践中反复发现的设计决策包，它具有已知的允许重用的属性，并且描述了一类架构。

架构模式可在以下对象之间建立一种关系：

• 背景（Context）：世界上反复出现的常见情况引发了一个问题。
• 问题（Problem）：在给定的背景中出现的被适当泛化的问题。
• 解决方案（Solution）：问题的适当抽象的成功架构解决方案。模式的解决方案的确定和描述如下：

        1、一组元素类型（例如，数据存储库、进程和对象）

        2、一组交互机制或连接器（例如，方法调用、事件或消息总线）

        3、组件的拓扑布局

        4、一组涵盖拓扑、元素行为和交互机制的语义约束

二、模式

1、模块模式

1）分层模式（Layered Pattern） 

Context	所有复杂的系统都需要独立地开发和发展系统的某些部分。因此，系统的开发人员需要一个清晰和文档良好的问题分离，以便系统的模块可以独立开发和维护。
Problem	软件需要以这样一种方式进行分割，即模块可以单独开发和进化，而各部件之间很少有交互，支持可移植性、可修改性和重用性。
Solution	为了实现这种关注点的分离，分层模式将软件划分为称为层的单元。每一层都是一组模块，它们提供了一组内聚的服务。使用必须是单向的。层完全划分了一组软件，每个分区都通过一个公共接口公开。
Overview	分层模式定义了层（提供一组内聚服务的模块的分组）和层之间的单向允许使用的关系。
Elements	层，一种模块。对一个层的描述应该定义该层所包含的模块。
Relations	允许使用。设计应该定义什么是层使用规则和任何允许的例外。
Constraints	a）每个软件都只分配到一个层。 b）至少有两层（但通常有三层或更多）。 c）允许使用的关系不应该是圆形的（即，较低的层不能使用上面的层）。
Weaknesses	a）添加层增加了系统的前期成本和复杂性。 b）层会造成性能损失。

 2、组件和连接器模式

1）代理模式（Broker Pattern） 

Context	许多系统都是由分布在多个服务器上的服务集合构建的。实现这些系统很复杂，因为您需要担心系统将如何互操作——它们将如何相互连接，以及它们将如何交换信息——以及组件服务的可用性。
Problem	我们如何构建分布式软件，使服务用户不需要知道服务提供商的性质和位置，从而可以很容易地动态更改用户和提供商之间的绑定？
Solution	代理模式通过插入一个称为代理的中介，将服务用户（客户机）与服务提供者（服务器）分开。当客户端需要服务时，它会通过服务接口查询代理。然后，代理将客户端的服务请求转发给处理该请求的服务器。
Overview	代理模式定义了一个运行时组件，它调节许多客户端和服务器之间的通信。
Elements	a）客户端、服务请求者 b）服务器、服务提供者 c）代理、中介，找到适当的服务器以满足客户端请求，将请求转发给服务器，d）并将结果返回给客户端 e）客户端代理，管理与代理的实际通信的中介，包括封送、发送和解除消息 f）服务器端代理，管理与代理的实际通信的中介，包括封送、发送和解封消息
Relations	附加关系将客户端（也可能还有客户端代理）和服务器（也可能还有服务器端代理）与代理关联。
Constraints	客户端只能依附代理（可能通过客户端代理）。服务器只能依附代理（可能通过服务器端代理）。
Weaknesses	a）代理在客户端和服务器之间增加了一层间接的层，因此也增加了延迟，该层可能是一个通信瓶颈。 b）代理可以是单点故障。 c）代理增加了前期的复杂性。 e）代理可能是安全攻击的目标。 f）可能很难进行测试代理。

2）MVC模式（Model-View-Controller Pattern） 

Context	用户界面软件通常是交互式应用程序中最频繁被修改的部分。用户通常希望从不同的角度来查看数据，比如条形图或饼状图。这些表示方式都应该反映数据的当前状态。
Problem	如何将用户界面功能与应用程序功能分开，同时仍然对用户输入或底层应用程序数据的变化做出响应？当底层应用程序数据发生更改时，如何创建、维护和协调用户界面的多个视图呢？
Solution	模型-视图控制器（MVC）模式将应用程序功能分为三种组件： a）一个模型，包含应用程序数据 b）一个视图，显示部分底层数据并与用户交互 c）一个控制器，在模型和视图之间进行中介，并管理状态更改的通知
Overview	MVC模式将系统功能分为三个组件：模型、视图和在模型和视图之间进行中介的控制器。
Elements	a）模型是应用程序数据或状态的表示，它包含（或提供接口）应用程序逻辑 b）视图是一个用户界面组件，它可以为用户生成模型的表示，或者允许某种形式的用户输入，或者两者都允许 c）控制器管理模型和视图之间的交互，将用户操作转换为对模型的更改或对视图的更改
Relations	附加关系将客户端（也可能还有客户端代理）和服务器（也可能还有服务器端代理）与代理关联。
Constraints	a）每个模型、视图和控制器都必须至少有一个实例 b）模型组件不应直接与控制器交互
Weaknesses	a）对于简单的用户界面来说，复杂性可能不值得。 b）模型、视图和控制器抽象可能不太适合某些用户界面工具包。

3）管道和过滤器模式（Pipe and Filter Pattern） 

Context	许多系统需要将离散的数据项流从输入转换到输出。许多类型的转换在实践中反复发生，因此希望将这些转换创建为独立的、可重用的部分。
Problem	这样的系统需要被划分为可重用的、松散耦合的组件，它们具有简单的、通用的交互机制。这样，它们就可以彼此灵活地结合在一起。这些组件是通用的和松散耦合的，易于重用。这些组件是独立的，因此可以并行执行。
Solution	管道和过滤器模式中的交互模式的特征是数据流的连续转换。数据到达过滤器的输入端口，然后进行转换，然后通过其输出端口通过管道传递到下一个过滤器。单个筛选器可以从一个或多个端口消耗数据，或生成数据。
Overview	数据通过其由管道连接的过滤器执行的一系列转换，从系统的外部输入转换到其外部输出。
Elements	a）过滤器，它是一个组件，可以将输入端口上读取的数据转换为输出端口上写入的数据 b）管道，它是一种将数据从过滤器的输出端口传输到另一个过滤器的输入端口的连接器。管道的输入有一个源，输出有一个目标。管道会保存数据项的顺序，并且不会更改传递的数据
Relations	附着关系将过滤器的输出与管道的输入关联起来，反之亦然
Constraints	a）管道将过滤器输出端口连接到过滤器输入端口 b）已连接的过滤器必须同意沿着连接管道传递的数据类型
Weaknesses	/

4）客户端服务器（Client-Server Pattern） 

Context	有大量分布式客户端希望访问的共享资源和服务，我们希望为此控制访问或服务质量。
Problem	通过管理一组共享的资源和服务，我们可以通过分解公共服务，并必须在一个位置或少量位置中修改这些服务，从而促进可修改性和重用性。我们希望通过集中对这些资源和服务的控制来提高可扩展性和可用性，同时将资源本身分布到多个物理服务器上。
Solution	客户端通过请求服务器的服务来进行交互，这些服务器提供了一组服务。某些组件可以同时充当客户端和服务器。可能有一个中央服务器或多个分布式服务器。
Overview	客户端启动与服务器的交互，根据需要从这些服务器调用服务，并等待这些请求的结果。
Elements	a）客户端，一个调用服务器组件的服务的组件。客户端有描述他们所需的服务的端口 b）服务器：向客户端提供服务的组件。服务器上有描述它们所提供的服务的端口 c）请求/应答连接器：一种使用请求/应答协议的数据连接器，由客户端用于调用服务器上的服务。重要的特征包括这些呼叫是本地的还是远程的，以及数据是否被加密。
Relations	附着关系将客户端与服务器关联起来。
Constraints	a）客户端通过请求/应答连接器连接到服务器 b）服务器组件可以是其他服务器的客户机
Weaknesses	a）服务器可能会成为一个性能瓶颈 b）服务器可能单点故障 c）在系统构建后，决定在哪里定位功能（在客户端或服务器中）通常是复杂的，而且在更改时代价高昂

5）对等模式（Peer-to-Peer Pattern） 

Context	分布式计算实体——每个实体在启动交互方面都被认为同样重要，每个实体都提供自己的资源——需要合作和协作，以向分布式用户社区提供服务。
Problem	如何将一组“相同的”的分布式计算实体通过公共协议相互连接，以便它们能够以高可用性和可伸缩性组织和共享它们的服务。
Solution	在对等（P2P）模式中，组件作为对等体直接交互。所有的对等方都是“平等的”，没有一个同伴或群体对系统的健康至关重要。对等通信通常是一种请求/回复交互，没有在客户机-服务器模式中发现的不对称性。
Overview	计算是通过协作的对等点请求跨网络的服务并相互提供服务来实现的。
Elements	a）对等点，它是运行在网络节点上的独立组件。特殊的对等组件可以提供路由、索引和对等搜索功能 b）请求/应答连接器，用于连接到对等网络、搜索其他对等点以及调用来自其他对等点的服务。在某些情况下，对回复的需要就被消除了
Relations	该关系将对等点与其连接器联系起来。附着关系可能会在运行时发生更改。
Constraints	a）任何给定对等带点的允许的依附数量 b）用于搜索对等点的跳数 c）对等点知道哪些对等点 d）一些P2P网络采用星形拓扑结构进行组织，其中对等点只连接到超节点
Weaknesses	a）管理安全性、数据一致性、数据/服务可用性、备份和恢复都更为复杂 b）小型点对点系统可能无法一致地实现质量目标，如性能和可用性

6）面向服务架构模式（Service Oriented Architecture Pattern） 

Context	许多服务是由服务提供者提供（和描述）的，并由服务消费者消费。服务消费者需要能够理解和使用这些服务，而不需要详细了解它们的实现。
Problem	我们如何支持运行在不同平台上并以不同实现语言编写的由不同的组织提供的分布式组件的互操作性，并在互联网上分布？
Solution	面向服务的体系结构（SOA）模式描述了提供和/或使用服务的分布式组件的集合。
Overview	计算是通过一组通过网络提供和/或使用服务的协作组件来实现的。
Elements	a）组件：         a1）服务提供商，它通过已发布的接口提供一个或多个服务         a2）服务消费者，它直接或通过中介调用服务         a3）服务提供商也可能是服务的消费者 b）ESB，它是一个中介元素，可以在服务提供者和消费者之间路由和转换消息 c）服务注册，供应商可使用它注册服务，消费者可在运行时发现服务 d）编排服务器，它基于业务流程和工作流的语言来协调服务使用者和提供者之间的交互 d）连接器         d1）SOAP连接器，它使用SOAP协议进行web服务之间的同步通信，通            常通过HTTP         d2）REST连接器，它依赖于HTTP协议的基本请求/应答操作         d3）异步消息传递连接器，它使用消息传递系统提供点对点或发布-订阅            异步消息交换
Relations	连接的不同类型的组件可用到各自的连接器
Constraints	服务使用者被连接到服务提供者，但可以使用中间组件（例如，ESB、注册表、编排服务器）
Weaknesses	a）基于SOA的系统构建通常很复杂 b）您无法控制独立服务的发展 c）存在与中间件相关联的性能开销，而服务可能是性能瓶颈，并且通常不能提供性能保证

7）发布-订阅模式（Publish-Subscribe Pattern） 

Context	有许多独立的数据生产者和消费者必须相互作用。数据生产者和消费者的确切数量和性质不是预先确定的或固定的，他们共享的数据也不是。
Problem	我们如何创建集成机制，支持在生产者和消费者之间传输信息的能力，使他们不知道彼此的身份，甚至可能不知道他们的存在？
Solution	在发布-订阅模式中，组件通过已宣布的消息或事件进行交互。组件可以订阅一组事件。发布服务器组件通过宣布事件将事件放置在总线上，然后连接器将这些事件传递给已对这些事件感兴趣的订阅者组件。
Overview	组件将发布和订阅事件。当组件发布事件时，连接器基础设施将事件分派给所有注册的订阅者。
Elements	a）至少有一个发布或订阅端口的任何C&C组件 b）发布-订阅连接器，将为希望发布和订阅事件的组件提供发布和侦听的角色
Relations	依附关系通过规定哪些组件发布事件，以及哪些组件被注册以接收事件，从而将组件与发布-订阅连接器关联起来
Constraints	所有组件都连接到可以视为总线连接器或组件的事件分发器。发布端口附加到发布角色，而订阅端口附加到侦听角色
Weaknesses	a）通常会增加延迟，并对消息传递时间的可伸缩性和可预测性产生负面影响。 b）对消息排序的控制减少，也不能保证消息的传递

8）共享数据模式（Shared-Data Pattern）

Context	各种计算组件需要共享和操作大量的数据。这些数据并不仅仅属于这些组件中的任何一个。
Problem	系统如何存储和操作由多个独立组件访问的持久性数据？
Solution	在共享数据模式中，交互主要是由多个数据访问器和至少一个共享数据存储之间的持久数据交换组成的。交换可以由访问器或数据存储器发起。连接器类型是数据读写。
Overview	数据访问器之间的通信是由一个共享的数据存储器进行中介的。控制可以由数据访问器或数据存储器启动。数据由数据存储器保持持久化。
Elements	a）共享数据存储。关注点包括存储的数据类型、面向数据性能的属性、数据分布和允许的访问器数量 b）数据访问器组件 c）数据读写接口
Relations	依附关系决定哪些数据存储器连接到哪些数据访问器
Constraints	数据访问器仅与数据存储器进行交互
Weaknesses	a）共享数据存储可能是一个性能瓶颈 b）共享数据存储可能造成单点故障 c）数据的生产者和消费者可能是紧密耦合的

3、分配模式

1）映射-减少模式（Map-Reduce Pattern）

Context	企业迫切需要以PB的规模快速分析他们产生或访问的大量数据。
Problem	对于许多具有超大数据集的应用程序，对数据进行排序，然后对分组的数据进行分析就足够了。映射减少模式解决的问题是有效地执行分布式和并行的大型数据集，并为程序员提供一个简单的方法来指定要完成的分析。
Solution	需要3部分： a）专门的基础设施负责在大规模并行计算环境中将软件分配给硬件节点，并根据需要对数据进行排序。 b）一个程序员指定的组件（称为map），用来过滤数据以检索要组合的项。 c）一个程序员指定的组件（成为reduce），它组合了映射的结果。
Overview	映射-减少模式提供了一个框架，用于分析将在一组处理器上并行执行的大型分布式数据集。这种并行化允许实现低延迟和高可用性。映射执行分析的提取和转换部分，而减少执行结果的加载。
Elements	a）Map是一个跨多个处理器部署了多个实例的函数，它执行分析的提取和转换部分 b）Reduce可以作为单个实例或跨处理器部署为多个实例，以执行提取-转换-负载的负载部分 c）基础设施是负责部署映射和减少实例、引导它们之间的数据以及检测并从故障中恢复的框架
Relations	a）deploy on是映射或简化功能的实例与安装它的处理器之间的关系 b）实例化、监视和控制是基础设施和映射和减少的实例之间的关系
Constraints	a）要分析的数据必须作为一组文件存在 b）映射函数是无状态的，彼此之间不进行通信 c）映射减少实例之间的唯一通信是从映射实例发出的数据作为<键，值>对
Weaknesses	a）如果你没有大的数据集，映射-减少的开销是不合理的 b）如果您不能将数据集划分为类似大小的子集，那么并行性的优势就会消失 c）需要多次reduce的操作是复杂的

2）多层模式（Multi-Tier Pattern）

Context	在分布式部署中，通常需要将系统的基础设施分发到不同的子集中
Problem	我们如何将系统分割成一些计算上独立的执行结构——由一些通信媒体连接的软件和硬件组？
Solution	许多系统的执行结构被组织为一组组件的逻辑分组。每个分组都被称为一层。
Overview	许多系统的执行结构被组织为一组组件的逻辑分组。每个分组都被称为一层。
Elements	层，它是一个软件组件的逻辑分组
Relations	a）is a part of，将组件分组为层 b）Communicates with，来显示层和它们所包含的组件是如何相互交互 c）Allocate to，在层映射到计算平台的情况
Constraints	一个软件组件只属于一层
Weaknesses	大量的前期成本和复杂性

三、策略和模式的关系

• 模式是由策略组建的；如果一个模式是分子，一个策略就是原子。
• 策略比模式更简单

例子：MVC模式利用了以下策略：

• Increase semantic coherence  
• Encapsulation
• Use an intermediary
• Use run time binding

四、策略增加模式 

问题：模式解决了一个特定的问题，但它是中立的或对其他质量有弱点。

例子：考虑代理模式：可能存在性能瓶颈和存在单点故障

解决：使用诸如“增加资源有助于性能”和“维护多个副本有助于可用性”的策略

相对于真实的系统，模式没有明确指定，因此必须用战术来增强它们。当满足特定系统的需求时，增强就结束（每一种策略的副作用都变得小到足以被忽视）。