软件架构模式-第二章 事件驱动架构

第二章 事件驱动架构


译者注:文章中 mediator 及 broker 的概念很容易混淆,在文章的结尾处译者对两者的区别(还有 proxy)进行了一定的阐述

事件驱动架构模式是一种主流的异步分发事件架构模式,常用于设计高度可拓展的应用。当然了,它有很高的适应性,使得它在小型应用、大型应用、复杂应用中都能表现得很好。事件驱动架构模式由高度解耦、单一目的的事件处理组件构成,这些组件负责异步接收和处理事件。

事件驱动架构模式包含了两种主要的拓扑结构:中介(mediator)拓扑结构和代理(broker)拓扑结构。 mediator 拓扑结构通常在你需要在事件内使用一个核心中介分配、协调多个步骤间的关系、执行顺序时使用;而代理拓扑结构则在你想要不通过一个核心中介将多个事件串联在一起时使用。由于这两种结构在结构特征和实现策略上有很大的差别,所以如果你想要在你的应用中使用它们的话,一定要深入理解两者的技术实现细节,从而为你的实际使用场景选择最合理的结构。

中介 ( Mediator )拓扑结构

中介拓扑结构适合用于拥有多个步骤,并需要在处理事件时能通过某种程度的协调将事件分层的场景,举例来说吧:假设你现在需要进行股票交易,那你首先需要证券所批准你进行交易,然后检查进行这次交易是否违反了股票交易的某种规定,检查完成后将它交给一个经纪人,计算佣金,最后与经纪人确认交易。以上所有步骤都需要通过中介进行某种程度的分配和协调,以决定各个步骤的执行顺序,判断哪些步骤可以并行,哪些步骤可以串行。

在中介拓扑结构中主要有四种组件:事件队列(event queue), 事件中介, 事件通道(event channel), 和 事件处理器(event processor)。当事件流需要被处理,客户端将一个事件发送到某个事件队列中,由消息队列将其运输给事件中介进行处理和分发。事件中介接收到该消息后,并通过将额外的异步事件发送给事件通道,让事件通道执行该异步事件中的每一个步骤,使得事件中介能够对事件进行分配、协调。同时,又因为事件处理器是事件通道的监听器,所以事件通道对异步事件的处理会触发事件处理器的监听事件,使事件处理器能够接收来自事件中介的事件,执行事件中具体的业务逻辑,从而完成对传入事件的处理。事件驱动架构模式中的中介拓扑模式结构大体如下图:

在事件驱动架构中拥有十几个,甚至几百个事件队列是很常见的情况,该模式并没有对事件队列的实现有明确的要求,这就意味着事件队列可以是消息队列,Web 服务端,或者其它类似的东西。

在事件驱动架构模式中主要有两种事件:初始事件和待处理事件。初始事件是中介所接收到的最原始的事件,没有经过其他组件的处理;而待处理事件是由事件中介生成,由事件处理器接收的组件,不能把待处理事件看作初始事件经过处理后得到的事件,两者是完全不同的概念。

事件中介负责分配、协调初始事件中的各个待执行步骤,事件中介需要为每一个初始事件中的步骤发送一个特定的待处理事件到事件通道中,触发事件处理器接收和处理该待处理事件。这里需要注意的是:事件 中介没有真正参与到对初始事件必须处理的业务逻辑的实现之中;相反,事件中介只是知道初始事件中有哪些步骤需要被处理。

事件中介通过事件通道将与初始事件每一个执行步骤相关联的特定待处理事件传递给事件处理器。尽管我们通常在待处理事件能被多个事件处理器处理时才会在中介拓扑结构中使用 消息主题,但事件通道仍可以是消息队列或 消息主题。(但需要注意的是,尽管在使用 消息主题 时待处理事件能被多个事件处理器处理,但由于接收到的待处理事件各异,所以对其处理的操作也各不相同)

为了能顺利处理待处理事件,事件处理器组件中包含了应用的业务逻辑。此外,事件处理器作为事件驱动架构中的组件,不依赖于其他组件,独立运作,高度解耦,在应用或系统中完成特定的任务。当事件处理器需要处理的事件从细粒度(例如:计算订单的营业税)变为粗粒度(例如:处理一项保险索赔事务),必须要注意的是:一般来说,每一个事件处理器组件都只完成一项唯一的业务工作,并且事件处理器在完成其特定的业务工作时不能依赖其他事件处理器。

虽然事件中介有许多方法可以实现,但作为一名架构工程师,你应该了解所有实现方式,以确保你能为你的实际需求选择了最合适的事件中介。

事件中介最简单、常见的实现就是使用开源框架,例如:Spring Integration,Apache Camel,或 Mule ESB。事件流在这些开源框架中通常用 Java 或 域特定语言(domain-specific language)。在调节过程和业务流程都很复杂的使用场景下,你可以使用业务流程执行语言(BPEL – business process execution language)结合类似开源框架 Apache ODE 的 BPEL 引擎进行开发。BPEL 是一种基于 XML 的服务编制编程语言,它为处理初始事件时需要描述的数据和步骤提供了描述。对每一个拥有复杂业务流程(包括与用户交互的执行步骤)的大型应用来说,你可以使用类似 jBPM 的业务处理管理系统(business process manager)实现事件中介。

如果你需要使用中介拓扑结构,那么理解你的需求,并为其匹配恰当的事件中介实现是构建事件驱动架构过程中至关重要的一环。使用开源框架去解决非常复杂的业务处理、管理、调节事件,注定会失败,因为开源框架只是用 BPM 的方式解决了一些简单的事件分发逻辑,比起你的业务逻辑,其中的事件分发逻辑简直是九牛一毛。

为了解释清楚中介拓扑结构是怎么运作的,我假设你在某家保险公司买了保险,成为了受保人,然后你打算搬家。在这种情况下,初始事件就是重定位事件,或者其他类似的事件。与重定位事件相关的处理步骤就像下图展示的那样,处于事件中介之中。对每一个初始事件的传入,事件中介都会创建一个待处理事件(例如:改变地址,重新计算保险报价,等等……),并将它发送给事件通道,等待发出响应的事件处理器处理待处理事件(例如:客户改变地址的操作流程、报价计算流程,等等……)。直到初始事件中的每一个需要处理的步骤完成了,这项处理才会继续(例如:把所有手续都完成之后,保险公司才会帮你改变地址)。事件中介中,重新报价和更新理赔步骤上面的直线表示这些步骤可以并行处理。

代理 (Broker) 拓扑结构

代理拓扑结构与中介拓扑结构不同之处在于:代理拓扑结构中没有核心的事件中介;相反,事件流在代理拓扑结构中通过一个轻量的消息代理(例如:ActiveMQ, HornetQ,等等……)将消息串联成链状,分发至事件处理器组件中进行处理。代理扑结构适用的使用场景大致上具有以下特征:你的事件处理流相对来说比较简单,而且你不想(不需要)使用核心的事件分配、调节机制以提高你处理事件的效率。

在代理拓扑结构中主要包括两种组件:代理和事件处理器。代理可被集中或相互关联在一起使用,此外,代理中还可以包含所有事件流中使用的事件通道。

存在于代理组件中的事件通道可以是消息队列,消息主题,或者是两者的组合。

代理拓扑结构大致如下图,如你所见,在这其中没有一个核心的事件中介组件控制和分发初始事件;相反,每一个事件处理器只负责处理一个事件,并向外发送一个事件,以标明其刚刚执行的动作。例如,假设存在一个事件处理器用于平衡证券交易,那么事件处理器可能会接受一个拆分股票的初始事件,为了处理这项初始事件,事件处理器则需要重新平衡股票的投资金额,而这个重新平衡的事件将由另一个事件处理器接收、处理。在这其中有一个细节需要注意:处理初始事件后,由事件处理器发出的事件不被其他事件处理器接收、处理的情况时常会发生,尤其是你在为应用添加功能和进行功能拓展时,这种情况更为常见。

为了阐明代理拓扑结构的运行机制,我会用一个与讲解中介拓扑结构时类似的例子(受保人旅行的例子)进行解释。因为在代理拓扑结构中没有核心事件中介接收初始事件,那么事件将由客户处理组件直接接收,改变客户的地址,并发出一个事件告知系统客户的地址被其进行了改变(例如:改变地址的事件)。在这个例子中:有两个事件处理器会与改变地址的事件产生关联:报价处理和索赔处理。报价事件处理器将根据受保人的新地址重新计算保险的金额,并发出事件告知系统该受保人的保险金额被其改变。而索赔事件处理器将接受到相同的改变地址事件,不同的是,它将更新保险的赔偿金额,并发出一个更新索赔金额事件告知系统该受保人的赔偿金额被其改变。当这些新的事件被其他事件处理器接收、处理,使事件链一环扣一环地交由系统处理,直到事件链上的所有事件都被处理完,初始事件的处理才算完成。

如上图所示,代理拓扑结构的设计思想就是将对事件流的处理转换为对事件链的业务功能处理,把代理拓扑结构看作是接力比赛是最好的理解方式:在一场4*100的接力比赛中,每一位运动员都需要拿着一根接力棒跑100米,运动员跑完自己的100米后需要将接力棒传递给下一位运动员,直到最后一位运动员拿着接力棒跑过终点线,整场接力比赛才算结束。根据这样的逻辑我们还可以知道:在代理拓扑结构中,一旦某个事件处理器将事件传递给另一个事件处理器,那么这个事件处理器不会与该事件的后续处理产生任何联系。

顾虑

实现事件驱动架构模式相对于实现其他架构模式会更困难一些,因为它通过异步处理进行事件分发。当你需要在你的应用中使用这种架构模式,你必须处理各种由事件分发处理带来的问题,例如:远程操作功能的可用性,缺少权限,以及在代理或中介中处理事件失败时,用于处理这种情况的重连逻辑。如果你不能很好地解决这些问题,那你的应用一定会出现各种 Bug,让开发团队痛苦不已。

在选择事件驱动架构时还有一点需要注意:在处理单个业务逻辑时,这种架构模式不能处理细粒度的事务。因为事件处理器都高度解耦、并且广泛分布,这使得在这些事件处理器中维持一个业务单元变得非常困难。因此,当你使用这种架构模式架构你的应用时,你必须不断地考虑哪些事件能单独被处理,哪些不能,并为此设计相应事件处理器的处理粒度。如果你发现你需要将一个业务单元切割成许多子单元,并一一匹配相应的事件处理器,那你就要为此进行代码设计;如果你发现你用多个不同的事件处理器处理的哪些业务其实是可以合并到一个业务事件之中的,那么这种模式可能并不适合你的应用,又或者是你的设计出了问题。

使用事件驱动架构模式最困难的地方就在于架构的创建、维护、以及对事件处理器的管理。通常每一个事件都拥有其指定的事件处理协议(例如:传递给事件处理器的数据类型、数据格式),这就使得设下标准的数据格式成为使用事件驱动架构模式中至关重要的一环(例如:XML,JSON,Java 对象,等等……),并在架构创建之初就为这些数据格式授权,以便处理。

模式分析

下面是基于对常见的架构模式特征进行评价的标准,对事件驱动架构模式所作的实际分析,评价是以常见的架构模式的相似实现作为标准进行的,如果你想知道进行对比的其他架构模式对应的特征,可以结尾处查看 附录A 的汇总表。

整体灵活性

评价:高 分析:整体灵活性用于评价架构能否在不断改变的使用场景下快速响应,因为事件处理器组件使用目的单一、高度解耦、与其他事件处理器组件相互独立,不相关联,那么发生的改变对一个或多个事件处理器来说普遍都是独立的,使得对改变的反馈非常迅速,不需要依赖其他事件处理器的响应作出处理。

易于部署

评价:高 分析:总的来看,事件驱动架构模式由于其高度解耦的事件处理器组件的存在,对事件的部署相对来说比较容易,而使用代理拓扑结构比使用中介拓扑结构进行事件调度会更容易一些,主要是因为在 中介拓扑结构中事件处理器与事件中介紧密地耦合在一起:事件处理器中发生改变后,事件中介也随之改变,如果我们需要改变某个被处理的事件,那么我们需要同时调度事件处理器和事件中介。

可测试性

评价:低 分析:虽然在事件驱动架构模式中进行单元测试并不困难,但如果我们要进行单元测试,我们就需要某种特定的测试客户端或者是测试工具产生事件,为单元测试提供初始值。此外,由于事件驱动架构模式是异步进行事件分发的,其异步处理的特性也为单元测试带来了一定的困难。

Performance 性能

评价:高 分析:对消息传递的架构可能会让设计出来的事件驱动架构的表现不如我们的期望,但通常来说,该模式都能通过其异步处理的特性展示优秀的性能表现;换句话来说,高度解耦,异步并行操作大大减少了传递消息过程中带来的时间开销。

伸缩性

评价:高 分析:事件驱动架构中的高度解耦、相互独立的事件处理器组件的存在,使得可拓展性成为该架构与生俱来的优点。架构的这些特定使得事件处理器能够进行细粒度的拓展,使得每一个事件处理器都能单独被拓展,而不影响其他事件处理器。

易于开发

评价:低 分析:由于使用事件驱动架构进行开发需要考虑其异步处理机制、协议创建流程,并且开发者需要用代码为事件处理器和操作失败的代理提供优秀的错误控制环境,无疑使得用事件驱动架构进行开发会比使用其他架构进行开发要困难一些。

译者注

读完整篇文章,我相信大家对 mediator 与 broker 这两个概念有一个大致的印象,但就两者的译文来看,中介和代理似乎没什么区别,尤其是了解 proxy 的读者会更加困惑,这三者之间到底是什么关系?它们的概念是互通的吗?为了解决这种混淆,译者将在此阐述三者间的区别:

假如现在我有一个事件/事件流需要被处理,那么使用 mediator、broker、proxy 处理事件的区别在哪里呢?

  • 如果我们使用 mediator,那就意味着我将把事件流交给 mediator,mediator 会帮我把事件分解为多个步骤,并分析其中的执行逻辑,调整和分发事件(例如判断哪些事件可以并行,哪些事件可以串行),然后根据 mediator 分解、调节的结果去执行事件中的每一个步骤,把所有步骤完成后,就能把需要处理的事件处理好。
  • 如果我们使用 broker,那就意味着我将把事件交给 broker,broker 获得事件后会把事件发出去(在本文中为:通知架构中所有可用的事件处理器),事件处理器们接收到事件以后,判断处理这个事件是否为自己的职责之一,如果不是则无视,与自己有关则把需要完成的工作完成,完成后如果事件还有后续需要处理的事件,则通过 broker 再次发布,再由相关的事件处理器接收、处理。以这样的方式将事件不断分解,沿着事件链一级一级地向下处理子事件,直到事件链中的所有事件被完成,我的事件也就处理好了。
  • 如果我们使用 proxy,那就意味着我自己对需要处理的事件进行了分解,然后把不同的子事件一一委托给不同的 proxy,由被委托的 proxy 帮我完成子事件,从而完成我要做的事件。

软件架构模式-第一章 分层架构

第一章 分层架构


分层架构是一种很常见的架构模式,它也叫N层架构。这种架构是大多数Jave EE应用的实际标准,因此很多的架构师,设计师,还有程序员都知道它。许多传统IT公司的组织架构和分层模式十分的相似。所以它很自然的成为大多数应用的架构模式。

模式分析

分层架构模式里的组件被分成几个平行的层次,每一层都代表了应用的一个功能(展示逻辑或者业务逻辑)。尽管分层架构没有规定自身要分成几层几种,大多数的结构都分成四个层次:展示层,业务层,持久层,和数据库层。如表1-1,有时候,业务层和持久层会合并成单独的一个业务层,尤其是持久层的逻辑绑定在业务层的组件当中。因此,有一些小的应用可能只有3层,一些有着更复杂的业务的大应用可能有5层或者更多的分层。

分层架构中的每一层都着特定的角色和职能。举个例子,展示层负责处理所有的界面展示以及交互逻辑,业务层负责处理请求对应的业务。架构里的层次是具体工作的高度抽象,它们都是为了实现某种特定的业务请求。比如说展示层并不需要关心怎样得到用户数据,它只需在屏幕上以特定的格式展示信息。业务层并不关心要展示在屏幕上的用户数据格式,也不关心这些用户数据从哪里来。它只需要从持久层得到数据,执行与数据有关的相应业务逻辑,然后把这些信息传递给展示层。

分层架构的一个突出特性是组件间关注点分离 (separation of concerns)。一个层中的组件只会处理本层的逻辑。比如说,展示层的组件只会处理展示逻辑,业务层中的组件只会去处理业务逻辑。多亏了组件分离,让我们更容易构造有效的角色和强力的模型。这样应用变的更好开发,测试,管理和维护。

关键概念

注意表1-2中每一层都是封闭的。这是分层架构中非常重要的特点。这意味request必须一层一层的传递。举个例子,从展示层传递来的请求首先会传递到业务层,然后传递到持久层,最后才传递到数据层。

那么为什么不允许展示层直接访问数据层呢。如果只是获得以及读取数据,展示层直接访问数据层,比穿过一层一层来得到数据来的快多了。这涉及到一个概念:层隔离。

层隔离就是说架构中的某一层的改变不会影响到其他层:这些变化的影响范围限于当前层次。如果展示层能够直接访问持久层了,假如持久层中的SQL变化了,这对业务层和展示层都有一定的影响。这只会让应用变得紧耦合,组件之间互相依赖。这种架构会非常的难以维护。

从另外一个方面来说,分层隔离使得层与层之间都是相互独立的,架构中的每一层的互相了解都很少。为了说明这个概念的牛逼之处,想象一个超级重构,把展示层从JSP换成JSF。假设展示层和业务层的之间的联系保持一致,业务层不会受到重构的影响,它和展示层所使用的界面架构完全独立。

然而封闭的架构层次也有不便之处,有时候也应该开放某一层。如果想往包含了一些由业务层的组件调用的普通服务组件的架构中添加一个分享服务层。在这个例子里,新建一个服务层通常是一个好主意,因为从架构上来说,它限制了分享服务访问业务层(也不允许访问展示层)。如果没有隔离层,就没有任何架构来限制展示层访问普通服务,难以进行权限管理。

在这个例子中,新的服务层是处于业务层之下的,展示层不能直接访问这个服务层中的组件。但是现在业务层还要通过服务层才能访问到持久层,这一点也不合理。这是分层架构中的老问题了,解决的办法是开放某些层。如表1-3所示,服务层现在是开放的了。请求可以绕过这一层,直接访问这一层下面的层。既然服务层是开放的,业务层可以绕过服务层,直接访问数据持久层。这样就非常合理。

开放和封闭层的概念确定了架构层和请求流之间的关系,并且给设计师和开发人员提供了必要的信息理解架构里各种层之间的访问限制。如果随意的开放或者封闭架构里的层,整个项目可能都是紧耦合,一团糟的。以后也难以测试,维护和部署。

示例

为了演示分层架构是如何工作的,想象一个场景,如表1-4,用户发出了一个请求要获得客户的信息。黑色的箭头是从数据库中获得用户数据的请求流,红色箭头显示用户数据的返回流的方向。在这个例子中,用户信息由客户数据和订单数组组成(客户下的订单)。

用户界面只管接受请求以及显示客户信息。它不管怎么得到数据的,或者说得到这些数据要用到哪些数据表。如果用户界面接到了一个查询客户信息的请求,它就会转发这个请求给用户委托(Customer Delegate)模块。这个模块能找到业务层里对应的模块处理对应数据(约束关系)。业务层里的customer object聚合了业务请求需要的所有信息(在这个例子里获取客户信息)。这个模块调用持久层中的 customer dao 来得到客户信息,调用order dao来得到订单信息。这些模块会执行SQL语句,然后返回相应的数据给业务层。当 customer object收到数据以后,它就会聚合这些数据然后传递给 customer delegate,然后传递这些数据到customer screen 展示在用户面前。

从技术的角度来说,有很多的方式能够实现这些模块。比如说在Java平台中,customer screen 对应的是 (JSF) Java Server Faces ,用 bean 组件来实现 customer delegate。用本地的Spring bean或者远程的EJB3 bean 来实现业务层中的customer object。上例中的数据访问可以用简单的POJP’s(Plain Old Java Objects),或者可以用MyBatis,还可以用JDBC或者Hibernate 查询。Microsoft平台上,customer screen能用 .NET 库的ASP模块来访问业务层中的C#模块,用ADO来实现用户和订单数据的访问模块。

注意事项

分层架构是一个很可靠的架构模式。它适合大多数的应用。如果你不确定在项目中使用什么架构,分层架构是再好不过的了。然后,从架构的角度上来说,选择这个模式还要考虑很多的东西。

第一个要注意的就是 污水池反模式(architecture sinkhole anti-pattern)。 在这个模式中,请求流只是简单的穿过层次,不留一点云彩,或者说只留下一阵青烟。比如说界面层响应了一个获得数据的请求。响应层把这个请求传递给了业务层,业务层也只是传递了这个请求到持久层,持久层对数据库做简单的SQL查询获得用户的数据。这个数据按照原理返回,不会有任何的二次处理,返回到界面上。

每个分层架构或多或少都可能遇到这种场景。关键在于这样的请求有多少。80-20原则可以帮助你确定架构是否处于反污水模式。大概有百分之二十的请求仅仅是做简单的穿越,百分之八十的请求会做一些业务逻辑操作。然而,如果这个比例反过来,大部分的请求都是仅仅穿过层,不做逻辑操作。那么开放一些架构层会比较好。不过由于缺少了层次隔离,项目会变得难以控制。

模式分析

下面的的表里分析了分层架构的各个方面。

整体灵活性

评级:低 分析:总体灵活性是响应环境变化的能力。尽管分层模式中的变化可以隔绝起来,想在这种架构中做一些也改变也是并且费时费力的。分层模式的笨重以及经常出现的组件之间的紧耦合是导致灵活性降低的原因。

易于部署

评级:低 分析:这取决于你怎么发布这种模式,发布程序可能比较麻烦,尤其是很大的项目。一个组件的小小改动可能会影响到整个程序的发布(或者程序的大部分)。发布必须是按照计划,在非工作时间或者周末进行发布。因此。分层模式导致应用发布一点也不流畅,在发布上降低了灵活性。

可测试性

评级:高 分析:因为组件都处于各自的层次中,可以模拟其他的层,或者说直接去掉层,所以分层模式很容易测试。开发者可以单独模拟一个展示组件,对业务组件进行隔绝测试。还可以模拟业务层来测试某个展示功能。

性能

评级:低 分析:尽管某些分层架构的性能表现的确不错,但是这个模式的特点导致它无法带来高性能。因为一次业务请求要穿越所有的架构层,做了很多不必要的工作。

伸缩性

评级:低 分析:由于这种模式以紧密耦合的趋势在发展,规模也比较大,用分层架构构建的程序都比较难以扩展。你可以把各个层分成单独的物理模块或者干脆把整个程序分成多个节点来扩展分层架构,但是总体的关系过于紧密,这样很难扩展。

易开发性

评级:容易 分析:在开发难度上面,分层架构得到了比较高的分数。因为这种架构对大家来说很熟悉,不难实现。大部分公司在开发项目的都是通过层来区分技术的,这种模式对于大多数的商业项目开发来说都很合适。公司的组织架构和他们软件架构之间的联系被戏称为”Conway’s law”。你可以Google一下查查这个有趣的联系。

软件架构模式-概述

软件架构模式 Mark Richards 著 版权归 © 2015 O’Reilly Media, Inc. 所有.

原书发布链接为Software Architecture Patterns.

译员信息

本书的译员均来自 开发技术前线 www.devtf.cn

译者 个人简介
Mr.Simple 乐于分享,热爱开源的工程师,个人博客
chaossss 追风筝的吃货,汪~。个人博客
Allenlsy 计算机科学爱好者,Rails程序员。个人博客
BillonWang 做好玩的事情,交好玩的朋友。个人博客
dupengwei 乐于分享的移动互联网开发工程师
Charli Hu 喜欢英语,不放弃编程的菇凉。

目录

简介

对程序员来说很常见一种情况是在没有合理的程序架构时就开始编程,没有一个清晰的和定义好的架构的时候,大多数开发者和架构师通常会使用标准式的传统分层架构模式(也被称为多层架构)——通过将源码模块分割为几个不同的层到不同的包中。不幸的是,这种编码方式会导致一系列没有组织性的代码模块,这些模块缺乏明确的规则、职责和同其他模块之间的关联。这通常被称为架构大泥球。

应用程序缺乏合理的架构一般会导致程序过度耦合、容易被破坏、难以应对变化,同时很难有一个清晰的版本或者方向性。这样的结果是,如果你没有充分理解程序系统里每个组件和模块,就很难定义这个程序的结构特征。有关于程序的部署和维护的基本问题都难以回答,比如:程序架构是什么规模?应用程序有什么性能特点?应用程序有多容易应对变化?应用程序的部署特点是什么?架构是如何反应的?

架构模式帮助你定义应用程序的基本特征和行为。例如,一些架构模式会让程序自己自然而然地朝着具有良好伸缩性的方向发展,而其他架构模式会让程序朝着高度灵活的方向发展。知道了这些特点,了解架构模式的优点和缺点是非常必要的,它帮助我们选择一个适合自己特定的业务需求和目标的的程序。

作为一个架构师,你必须证明你的架构模式的决策是正确的,特别是当需要选择一个特定的体系结构模式或方法的时候。这本迷你书的目的就是给你足够的信息让你去做出正确的架构决策。


电子书下载页:

https://legacy.gitbook.com/book/bboyfeiyu/software-architecture-patterns/details

下载:https://legacy.gitbook.com/download/pdf/book/bboyfeiyu/software-architecture-patterns

软件设计模式-设计模式资源

设计模式资源

本章列出了设计模式相关的网站、书籍和文章。

设计模式相关的网站

http://design-patterns.readthedocs.io/zh_CN/latest/index.html#

Java 设计模式有用的书籍

Java Design Patterns Head First Design Patterns

软件设计模式-J2EE模式-传输对象模式

传输对象模式


传输对象模式(Transfer Object Pattern)用于从客户端向服务器一次性传递带有多个属性的数据。传输对象也被称为数值对象。传输对象是一个具有 getter/setter 方法的简单的 POJO 类,它是可序列化的,所以它可以通过网络传输。它没有任何的行为。服务器端的业务类通常从数据库读取数据,然后填充 POJO,并把它发送到客户端或按值传递它。对于客户端,传输对象是只读的。客户端可以创建自己的传输对象,并把它传递给服务器,以便一次性更新数据库中的数值。以下是这种设计模式的实体。

  • 业务对象(Business Object) – 为传输对象填充数据的业务服务。
  • 传输对象(Transfer Object) – 简单的 POJO,只有设置/获取属性的方法。
  • 客户端(Client) – 客户端可以发送请求或者发送传输对象到业务对象。

实现


我们将创建一个作为业务对象的 StudentBO 和作为传输对象的 StudentVO,它们都代表了我们的实体。

TransferObjectPatternDemo,我们的演示类在这里是作为一个客户端,将使用 StudentBO 和 Student 来演示传输对象设计模式。

步骤 1

创建传输对象。

public class StudentVO {
   private String name;
   private int rollNo;
 
   StudentVO(String name, int rollNo){
      this.name = name;
      this.rollNo = rollNo;
   }
 
   public String getName() {
      return name;
   }
 
   public void setName(String name) {
      this.name = name;
   }
 
   public int getRollNo() {
      return rollNo;
   }
 
   public void setRollNo(int rollNo) {
      this.rollNo = rollNo;
   }
}

步骤 2

创建业务对象。

import java.util.ArrayList;
import java.util.List;
 
public class StudentBO {
   
   //列表是当作一个数据库
   List<StudentVO> students;
 
   public StudentBO(){
      students = new ArrayList<StudentVO>();
      StudentVO student1 = new StudentVO("Robert",0);
      StudentVO student2 = new StudentVO("John",1);
      students.add(student1);
      students.add(student2);    
   }
   public void deleteStudent(StudentVO student) {
      students.remove(student.getRollNo());
      System.out.println("Student: Roll No " 
      + student.getRollNo() +", deleted from database");
   }
 
   //从数据库中检索学生名单
   public List<StudentVO> getAllStudents() {
      return students;
   }
 
   public StudentVO getStudent(int rollNo) {
      return students.get(rollNo);
   }
 
   public void updateStudent(StudentVO student) {
      students.get(student.getRollNo()).setName(student.getName());
      System.out.println("Student: Roll No " 
      + student.getRollNo() +", updated in the database");
   }
}

步骤 3

使用 StudentBO 来演示传输对象设计模式。

public class TransferObjectPatternDemo {
   public static void main(String[] args) {
      StudentBO studentBusinessObject = new StudentBO();
 
      //输出所有的学生
      for (StudentVO student : studentBusinessObject.getAllStudents()) {
         System.out.println("Student: [RollNo : "
         +student.getRollNo()+", Name : "+student.getName()+" ]");
      }
 
      //更新学生
      StudentVO student =studentBusinessObject.getAllStudents().get(0);
      student.setName("Michael");
      studentBusinessObject.updateStudent(student);
 
      //获取学生
      studentBusinessObject.getStudent(0);
      System.out.println("Student: [RollNo : "
      +student.getRollNo()+", Name : "+student.getName()+" ]");
   }
}

步骤 4

执行程序,输出结果:

Student: [RollNo : 0, Name : Robert ]
Student: [RollNo : 1, Name : John ]
Student: Roll No 0, updated in the database
Student: [RollNo : 0, Name : Michael ]

 

软件设计模式-J2EE模式-服务定位器模式

服务定位器模式


服务定位器模式(Service Locator Pattern)用在我们想使用 JNDI 查询定位各种服务的时候。考虑到为某个服务查找 JNDI 的代价很高,服务定位器模式充分利用了缓存技术。在首次请求某个服务时,服务定位器在 JNDI 中查找服务,并缓存该服务对象。当再次请求相同的服务时,服务定位器会在它的缓存中查找,这样可以在很大程度上提高应用程序的性能。以下是这种设计模式的实体。

  • 服务(Service) – 实际处理请求的服务。对这种服务的引用可以在 JNDI 服务器中查找到。
  • Context / 初始的 Context – JNDI Context 带有对要查找的服务的引用。
  • 服务定位器(Service Locator) – 服务定位器是通过 JNDI 查找和缓存服务来获取服务的单点接触。
  • 缓存(Cache) – 缓存存储服务的引用,以便复用它们。
  • 客户端(Client) – Client 是通过 ServiceLocator 调用服务的对象。

实现


我们将创建 ServiceLocatorInitialContextCacheService 作为表示实体的各种对象。Service1 和 Service2 表示实体服务。

ServiceLocatorPatternDemo,我们的演示类在这里是作为一个客户端,将使用 ServiceLocator 来演示服务定位器设计模式。

步骤 1

创建服务接口 Service。

public interface Service {
   public String getName();
   public void execute();
}

步骤 2

创建实体服务。

public class Service1 implements Service {
   public void execute(){
      System.out.println("Executing Service1");
   }
 
   @Override
   public String getName() {
      return "Service1";
   }
}
public class Service2 implements Service {
   public void execute(){
      System.out.println("Executing Service2");
   }
 
   @Override
   public String getName() {
      return "Service2";
   }
}

步骤 3

为 JNDI 查询创建 InitialContext。

public class InitialContext {
   public Object lookup(String jndiName){
      if(jndiName.equalsIgnoreCase("SERVICE1")){
         System.out.println("Looking up and creating a new Service1 object");
         return new Service1();
      }else if (jndiName.equalsIgnoreCase("SERVICE2")){
         System.out.println("Looking up and creating a new Service2 object");
         return new Service2();
      }
      return null;      
   }
}

步骤 4

创建缓存 Cache。

import java.util.ArrayList;
import java.util.List;
 
public class Cache {
 
   private List<Service> services;
 
   public Cache(){
      services = new ArrayList<Service>();
   }
 
   public Service getService(String serviceName){
      for (Service service : services) {
         if(service.getName().equalsIgnoreCase(serviceName)){
            System.out.println("Returning cached  "+serviceName+" object");
            return service;
         }
      }
      return null;
   }
 
   public void addService(Service newService){
      boolean exists = false;
      for (Service service : services) {
         if(service.getName().equalsIgnoreCase(newService.getName())){
            exists = true;
         }
      }
      if(!exists){
         services.add(newService);
      }
   }
}

步骤 5

创建服务定位器。

public class ServiceLocator {
   private static Cache cache;
 
   static {
      cache = new Cache();    
   }
 
   public static Service getService(String jndiName){
 
      Service service = cache.getService(jndiName);
 
      if(service != null){
         return service;
      }
 
      InitialContext context = new InitialContext();
      Service service1 = (Service)context.lookup(jndiName);
      cache.addService(service1);
      return service1;
   }
}

步骤 6

使用 ServiceLocator 来演示服务定位器设计模式。

public class ServiceLocatorPatternDemo {
   public static void main(String[] args) {
      Service service = ServiceLocator.getService("Service1");
      service.execute();
      service = ServiceLocator.getService("Service2");
      service.execute();
      service = ServiceLocator.getService("Service1");
      service.execute();
      service = ServiceLocator.getService("Service2");
      service.execute();      
   }
}

步骤 7

执行程序,输出结果:

Looking up and creating a new Service1 object
Executing Service1
Looking up and creating a new Service2 object
Executing Service2
Returning cached  Service1 object
Executing Service1
Returning cached  Service2 object
Executing Service2

 

软件设计模式-J2EE模式-拦截过滤器模式

拦截过滤器模式


拦截过滤器模式(Intercepting Filter Pattern)用于对应用程序的请求或响应做一些预处理/后处理。定义过滤器,并在把请求传给实际目标应用程序之前应用在请求上。过滤器可以做认证/授权/记录日志,或者跟踪请求,然后把请求传给相应的处理程序。以下是这种设计模式的实体。

  • 过滤器(Filter) – 过滤器在请求处理程序执行请求之前或之后,执行某些任务。
  • 过滤器链(Filter Chain) – 过滤器链带有多个过滤器,并在 Target 上按照定义的顺序执行这些过滤器。
  • Target – Target 对象是请求处理程序。
  • 过滤管理器(Filter Manager) – 过滤管理器管理过滤器和过滤器链。
  • 客户端(Client) – Client 是向 Target 对象发送请求的对象。

实现


我们将创建 FilterChainFilterManagerTargetClient 作为表示实体的各种对象。AuthenticationFilter 和 DebugFilter 表示实体过滤器。

InterceptingFilterDemo,我们的演示类使用 Client 来演示拦截过滤器设计模式。

步骤 1

创建过滤器接口 Filter。

public interface Filter {
   public void execute(String request);
}

步骤 2

创建实体过滤器。

public class AuthenticationFilter implements Filter {
   public void execute(String request){
      System.out.println("Authenticating request: " + request);
   }
}
public class DebugFilter implements Filter {
   public void execute(String request){
      System.out.println("request log: " + request);
   }
}

步骤 3

创建 Target。

public class Target {
   public void execute(String request){
      System.out.println("Executing request: " + request);
   }
}

步骤 4

创建过滤器链。

import java.util.ArrayList;
import java.util.List;
 
public class FilterChain {
   private List<Filter> filters = new ArrayList<Filter>();
   private Target target;
 
   public void addFilter(Filter filter){
      filters.add(filter);
   }
 
   public void execute(String request){
      for (Filter filter : filters) {
         filter.execute(request);
      }
      target.execute(request);
   }
 
   public void setTarget(Target target){
      this.target = target;
   }
}

步骤 5

创建过滤管理器。

public class FilterManager {
   FilterChain filterChain;
 
   public FilterManager(Target target){
      filterChain = new FilterChain();
      filterChain.setTarget(target);
   }
   public void setFilter(Filter filter){
      filterChain.addFilter(filter);
   }
 
   public void filterRequest(String request){
      filterChain.execute(request);
   }
}

步骤 6

创建客户端 Client。

public class Client {
   FilterManager filterManager;
 
   public void setFilterManager(FilterManager filterManager){
      this.filterManager = filterManager;
   }
 
   public void sendRequest(String request){
      filterManager.filterRequest(request);
   }
}

步骤 7

使用 Client 来演示拦截过滤器设计模式。

public class InterceptingFilterDemo {
   public static void main(String[] args) {
      FilterManager filterManager = new FilterManager(new Target());
      filterManager.setFilter(new AuthenticationFilter());
      filterManager.setFilter(new DebugFilter());
 
      Client client = new Client();
      client.setFilterManager(filterManager);
      client.sendRequest("HOME");
   }
}

步骤 8

执行程序,输出结果:

Authenticating request: HOME
request log: HOME
Executing request: HOME

 

软件设计模式-J2EE模式-前端控制器模式

前端控制器模式


前端控制器模式(Front Controller Pattern)是用来提供一个集中的请求处理机制,所有的请求都将由一个单一的处理程序处理。该处理程序可以做认证/授权/记录日志,或者跟踪请求,然后把请求传给相应的处理程序。以下是这种设计模式的实体。

  • 前端控制器(Front Controller) – 处理应用程序所有类型请求的单个处理程序,应用程序可以是基于 web 的应用程序,也可以是基于桌面的应用程序。
  • 调度器(Dispatcher) – 前端控制器可能使用一个调度器对象来调度请求到相应的具体处理程序。
  • 视图(View) – 视图是为请求而创建的对象。

实现


我们将创建 FrontControllerDispatcher 分别当作前端控制器和调度器。HomeView 和 StudentView 表示各种为前端控制器接收到的请求而创建的视图。

FrontControllerPatternDemo,我们的演示类使用 FrontController 来演示前端控制器设计模式。

步骤 1

创建视图。

public class HomeView {
   public void show(){
      System.out.println("Displaying Home Page");
   }
}
public class StudentView {
   public void show(){
      System.out.println("Displaying Student Page");
   }
}

步骤 2

创建调度器 Dispatcher。

public class Dispatcher {
   private StudentView studentView;
   private HomeView homeView;
   public Dispatcher(){
      studentView = new StudentView();
      homeView = new HomeView();
   }
 
   public void dispatch(String request){
      if(request.equalsIgnoreCase("STUDENT")){
         studentView.show();
      }else{
         homeView.show();
      }  
   }
}

步骤 3

创建前端控制器 FrontController。

public class FrontController {
   
   private Dispatcher dispatcher;
 
   public FrontController(){
      dispatcher = new Dispatcher();
   }
 
   private boolean isAuthenticUser(){
      System.out.println("User is authenticated successfully.");
      return true;
   }
 
   private void trackRequest(String request){
      System.out.println("Page requested: " + request);
   }
 
   public void dispatchRequest(String request){
      //记录每一个请求
      trackRequest(request);
      //对用户进行身份验证
      if(isAuthenticUser()){
         dispatcher.dispatch(request);
      }  
   }
}

步骤 4

使用 FrontController 来演示前端控制器设计模式。

public class FrontControllerPatternDemo {
   public static void main(String[] args) {
      FrontController frontController = new FrontController();
      frontController.dispatchRequest("HOME");
      frontController.dispatchRequest("STUDENT");
   }
}

步骤 5

执行程序,输出结果:

Page requested: HOME
User is authenticated successfully.
Displaying Home Page
Page requested: STUDENT
User is authenticated successfully.
Displaying Student Page

 

软件设计模式-J2EE模式-数据访问对象模式

数据访问对象模式


数据访问对象模式(Data Access Object Pattern)或 DAO 模式用于把低级的数据访问 API 或操作从高级的业务服务中分离出来。以下是数据访问对象模式的参与者。

  • 数据访问对象接口(Data Access Object Interface) – 该接口定义了在一个模型对象上要执行的标准操作。
  • 数据访问对象实体类(Data Access Object concrete class) – 该类实现了上述的接口。该类负责从数据源获取数据,数据源可以是数据库,也可以是 xml,或者是其他的存储机制。
  • 模型对象/数值对象(Model Object/Value Object) – 该对象是简单的 POJO,包含了 get/set 方法来存储通过使用 DAO 类检索到的数据。

实现


我们将创建一个作为模型对象或数值对象的 Student 对象。StudentDao 是数据访问对象接口。StudentDaoImpl 是实现了数据访问对象接口的实体类。DaoPatternDemo,我们的演示类使用 StudentDao 来演示数据访问对象模式的用法。

步骤 1

创建数值对象。

public class Student {
   private String name;
   private int rollNo;
 
   Student(String name, int rollNo){
      this.name = name;
      this.rollNo = rollNo;
   }
 
   public String getName() {
      return name;
   }
 
   public void setName(String name) {
      this.name = name;
   }
 
   public int getRollNo() {
      return rollNo;
   }
 
   public void setRollNo(int rollNo) {
      this.rollNo = rollNo;
   }
}

步骤 2

创建数据访问对象接口。

import java.util.List;
 
public interface StudentDao {
   public List<Student> getAllStudents();
   public Student getStudent(int rollNo);
   public void updateStudent(Student student);
   public void deleteStudent(Student student);
}

步骤 3

创建实现了上述接口的实体类。

import java.util.ArrayList;
import java.util.List;
 
public class StudentDaoImpl implements StudentDao {
   
   //列表是当作一个数据库
   List<Student> students;
 
   public StudentDaoImpl(){
      students = new ArrayList<Student>();
      Student student1 = new Student("Robert",0);
      Student student2 = new Student("John",1);
      students.add(student1);
      students.add(student2);    
   }
   @Override
   public void deleteStudent(Student student) {
      students.remove(student.getRollNo());
      System.out.println("Student: Roll No " + student.getRollNo() 
         +", deleted from database");
   }
 
   //从数据库中检索学生名单
   @Override
   public List<Student> getAllStudents() {
      return students;
   }
 
   @Override
   public Student getStudent(int rollNo) {
      return students.get(rollNo);
   }
 
   @Override
   public void updateStudent(Student student) {
      students.get(student.getRollNo()).setName(student.getName());
      System.out.println("Student: Roll No " + student.getRollNo() 
         +", updated in the database");
   }
}

步骤 4

使用 StudentDao 来演示数据访问对象模式的用法。

public class DaoPatternDemo {
   public static void main(String[] args) {
      StudentDao studentDao = new StudentDaoImpl();
 
      //输出所有的学生
      for (Student student : studentDao.getAllStudents()) {
         System.out.println("Student: [RollNo : "
            +student.getRollNo()+", Name : "+student.getName()+" ]");
      }
 
 
      //更新学生
      Student student =studentDao.getAllStudents().get(0);
      student.setName("Michael");
      studentDao.updateStudent(student);
 
      //获取学生
      studentDao.getStudent(0);
      System.out.println("Student: [RollNo : "
         +student.getRollNo()+", Name : "+student.getName()+" ]");      
   }
}

步骤 5

执行程序,输出结果:

Student: [RollNo : 0, Name : Robert ]
Student: [RollNo : 1, Name : John ]
Student: Roll No 0, updated in the database
Student: [RollNo : 0, Name : Michael ]

 

软件设计模式-J2EE模式-组合实体模式

组合实体模式


组合实体模式(Composite Entity Pattern)用在 EJB 持久化机制中。一个组合实体是一个 EJB 实体 bean,代表了对象的图解。当更新一个组合实体时,内部依赖对象 beans 会自动更新,因为它们是由 EJB 实体 bean 管理的。以下是组合实体 bean 的参与者。

  • 组合实体(Composite Entity) – 它是主要的实体 bean。它可以是粗粒的,或者可以包含一个粗粒度对象,用于持续生命周期。
  • 粗粒度对象(Coarse-Grained Object) – 该对象包含依赖对象。它有自己的生命周期,也能管理依赖对象的生命周期。
  • 依赖对象(Dependent Object) – 依赖对象是一个持续生命周期依赖于粗粒度对象的对象。
  • 策略(Strategies) – 策略表示如何实现组合实体。

实现


我们将创建作为组合实体的 CompositeEntity 对象。CoarseGrainedObject 是一个包含依赖对象的类。

CompositeEntityPatternDemo,我们的演示类使用 Client 类来演示组合实体模式的用法。

步骤 1

创建依赖对象。

public class DependentObject1 {
   
   private String data;
 
   public void setData(String data){
      this.data = data; 
   } 
 
   public String getData(){
      return data;
   }
}
public class DependentObject2 {
   
   private String data;
 
   public void setData(String data){
      this.data = data; 
   } 
 
   public String getData(){
      return data;
   }
}

步骤 2

创建粗粒度对象。

public class CoarseGrainedObject {
   DependentObject1 do1 = new DependentObject1();
   DependentObject2 do2 = new DependentObject2();
 
   public void setData(String data1, String data2){
      do1.setData(data1);
      do2.setData(data2);
   }
 
   public String[] getData(){
      return new String[] {do1.getData(),do2.getData()};
   }
}

步骤 3

创建组合实体。

public class CompositeEntity {
   private CoarseGrainedObject cgo = new CoarseGrainedObject();
 
   public void setData(String data1, String data2){
      cgo.setData(data1, data2);
   }
 
   public String[] getData(){
      return cgo.getData();
   }
}

步骤 4

创建使用组合实体的客户端类。

public class Client {
   private CompositeEntity compositeEntity = new CompositeEntity();
 
   public void printData(){
      for (int i = 0; i < compositeEntity.getData().length; i++) {
         System.out.println("Data: " + compositeEntity.getData()[i]);
      }
   }
 
   public void setData(String data1, String data2){
      compositeEntity.setData(data1, data2);
   }
}

步骤 5

使用 Client 来演示组合实体设计模式的用法。

public class CompositeEntityPatternDemo {
   public static void main(String[] args) {
       Client client = new Client();
       client.setData("Test", "Data");
       client.printData();
       client.setData("Second Test", "Data1");
       client.printData();
   }
}

步骤 6

执行程序,输出结果:

Data: Test
Data: Data
Data: Second Test
Data: Data1