介绍

#Software Architecture Patterns翻译

最近再看阮一峰的一篇博客提到了一本书《Software Architecture Patterns》（PDF） ,写的不错,虽然英语很屎,试着翻(gu)译(ge)一下。以下为翻译的内容，祝我能够翻译完，并借此机会能够加深对架构的认识。

ps:建议看英文原著. ps:[ ]中的话是我说的. ps:好吧,我找到已经有一个翻译版本了(https://github.com/hehonghui/android-tech-frontier/tree/master/software-architecture-patterns) 早看到就不翻译了......

参考: 阮一峰的博客鸟窝的博客

介绍

开发人员在没有合适架构的情况下开始编写程序是非常普遍的情况. 在这种情况下,大多数开发人员和架构师会采用传统分层架构模式（也称为n层架构),通过将源码模块分成各种包来表示抽象层。不幸的是，这种做法经常导致的是一个混乱的源码结构，它们缺乏明确的角色，职责和彼此之间的关系。这通常被称为反模式的大泥球。

没有通过架构设计的应用程序通常紧密耦合，脆弱，难以改变，没有清晰结构。如果没有完全理解系统中的每个组件和模块的内部工作原理的情况下，确定程序的架构特性会是非常困难的事情。关于程序部署和维护的基本问题也会很难回答：架构是否具有可扩展性？应用程序的性能如何？程序是否能够应对变化？程序如何部署？架构的响应能力如何？

架构模式有助于定义应用程序的基本特征和行为。例如，一些架构模式非常适合需要高可扩展性的应用程序，一些架构模式则适用于非常灵活的应用程序。只有了解各种架构模式的优势和弱点，才能够选择出满足自己业务特点和目标的架构模式。

作为一个架构师，你必须证明你的架构决策，特别是当涉及到选择一个特定的架构模式或方法。这篇文正的目的是为您提供足够的信息，以证明你的选择是OK的。

1.分层架构(Layered Architecture)

分层架构是最常见的架构，也是javaee应用程序的标准模式，并被多数开发人员了解。这种架构适合于传统IT通信和组织结构，成为大多数业务应用程序开发工作的自然选择。

模式描述(Pattern Description)

该架构中每一层都包含多个组件并且拥有具体的职责(例如显示逻辑、业务逻辑)。该架构并不严格规定层的类型和层数，多数分层架构包含视图层、业务层、持久化层和数据库层(图1-1)。有时，业务层和持久层被合并为单个业务层，特别是当持久性逻辑（例如，生成SQL或HSQL）嵌入到业务层组件中。因此，较小的应用可以仅具有三个层，而大的应用可以包含五个或更多个层[对于多数应用四层足以]。分层架构模式的每一层在应用程序中都有特定的角色和职责。例如，表示层将负责处理所有的用户界面逻辑，而业务层负责响应表示层的请求并执行相应的业务逻辑。架构中的每一层都围绕需要完成的工作形成抽象，以满足特定的业务请求。例如，表示层不需要知道或担心如何获得客户数据;它只需要在特定格式的屏幕上显示该信息。类似地，业务层不需要关心如何格式化客户数据以在屏幕上显示或者甚至在客户数据来自哪里;它只需要从持久层获得数据，对数据执行业务逻辑（例如，计算值或聚合数据），并将该信息传递到表示层。

分层架构模式的一个强大的功能是组件之间的关注点分离(separation of concerns)。特定层中的组件仅处理与该层相关的逻辑。例如，表示层中的组件只处理表示逻辑，而业务层的组件只处理业务逻辑。这种组件分类方式使您可以轻松地在您的架构中构建有用的模型，并且由于定义明确的组件接口和有限的组件范围，还可以轻松地使用此架构模式开发，测试，管理和维护应用程序。

关键概念(Pattern Description)

在图1-2中，架构中的每个层都标记为封闭。这是分层架构模式中非常重要的概念。关闭意味着当请求从一个层移动到另一个层时，它必须经过它的下层，才能到达目的层。例如，一个请求从表示层要到数据库层就必须经过业务层和持久层。

那么为什么不允许表示层直接访问持久层或数据库层？毕竟，从表示层的直接数据库访问比通过一堆不必要的层来检索或保存数据库信息要快得多。这个问题的答案在于一个被称为隔离层(layers of isolation)的关键概念。

隔离层意味着在一个层的变化通常不会影响到其它层的组件。如果你允许表示层直接访问持久层，那么持久层的变化将会同时影响业务层和表示层，从而产生了非常紧密耦合和组件之间的依赖性。当需求发生变化时，这种架构将会付出较大的代价。

隔离概念的层还意味着每个层独立于其他层，并且不需要知道其它层是如何工作的。为了理解这个概念的重要性，考虑一个大规模的重构，将展示框架从JSP（Java服务器页面）修改为JSF（Java服务器面。假设在表示层和业务层之间使用的契约(contracts)（例如，模型）保持相同，则业务层不受重构的影响并且完全和表示层保持独立。

虽然封闭的层有助于层次之间的隔离，从而提高了架构的低耦合设计，但有时候某些层被打开是有意义的。例如，假设您要增加一个共享服务层向业务层的组件提供服务（例如，数据和字符串实用程序类或审计和日志记录类）。在这种情况下创建服务层通常是一个好主意，因为在体系结构上，它将对共享服务的访问限制为业务层（而不是表示层）。没有单独的层，在架构上没有限制表示层访问这些公共服务，使得难以管理该访问限制[这句话没看懂，回头再看]。

在该示例中，新服务层可能驻留在业务层之下，同时表明该服务层中的组件不能被表示层访问。然而，这衍生出一个新的问题，业务层需要经过服务层以到达持久层，但这根本没有意义。这是分层架构的一个古老的问题，需要通过在架构内创建开放层来解决。

如图1-3所示，在这种情况下，服务层被标记为打开，意味着改层可以被绕过。在以下示例中，由于服务层是打开的，因此业务层现在允许绕过它，并直接转到持久层，这是完全合理的。

利用开放层和封闭层的概念有助于定义层次和请求流之间的关系，并且向设计者和开发者提供理解架构内的各种层访问限制的必要信息。如果不能确定架构中的哪些层是开放和封闭的（以及为什么）通常会导致架构难以测试，维护和部署的紧密耦合和脆弱。

架构例子(Pattern Example)

为了说明分层架构的工作原理，考虑一个来自用户检索客户信息的请求，如图1-4所示。黑色箭头显示请求流向数据库以检索客户数据，红色箭头显示响应返回到屏幕以显示数据。在该示例中，客户信息包括客户数据和订单数据（由客户下达的订单)。

如图所示，customer screen模块负责接受用户请求并显示客户信息，它不知道数据在哪里，如何检索，也不了解数据库，该模块收到查询客户信息的请求后，将该请求转发到customer delegate模块，该模块负责了解业务层中哪些模块可以处理该请求，以及如何获取该模块需要的数据（例如合同数据）。业务层中的custom object负责收集(aggregating)业务请求所需的所有信息（该例子中是指客户信息）。该模块调用customer dao(数据访问对象)模块在持久层中获取客户数据，并且还通过order dao模块获取订单信息。这些模块又执行SQL语句来检索相应的数据，并将其传回给业务层中的customer object模块。一旦customer object接收到数据，它整合数据并将该信息传递回customer delegate，然后将该数据传递到customer screen以呈现给用户。

从技术的角度来看，这些模块可以有很多实现方式。例如，在Java平台中，customer screen模块可以是(JSF) Java Server Faces screen，它和customer delegage可以作为被管理的bean组件。业务层中的customer object可以是本地Spring bean对象或远程EJB3 bean对象。之前示例中的客户和订单数据可以由POJO，MyBatis XML Mapper，甚至可以是JDBC调用或Hibernate查询返回的数据封装。在Microsoft平台中，customer screen可以是基于.net技术体系ASP（活动服务器页面）模块，客户和订单数据可以由为ADO（ActiveX数据对象）实现。

注意事项(Considerations)

分层架构是比较实用并且通用的模式，对于多数程序是一个良好起点，尤其是当您不确定哪种架构模式最适合您的应用程序时。当选择这种模式时，你需要从架构的角度来考虑一下几点。

要注意的第一件事是所谓的污水池反模式(architecture sinkhole anti-pattern)[谁能解释一下这是啥意思]。这个反模式是这样的，请求流简单的穿过几个层，每层里面基本没有做任何业务逻辑，或者做了很少的业务逻辑。例如，假设表示层响应来自用户的检索客户数据的请求。表示层将请求传递给业务层，业务层简单地将请求传递给持久层，然后对数据库层进行简单的SQL调用以检索客户数据。然后，数据一路返回，没有用于聚集(aggregate)，计算或变换数据的额外处理或逻辑。

每个分层架构将具有至少一些落入反模式(architecture sinkhole anti-pattern)的情况。这里面的关键是分析出属于此类别的请求的百分比。 80-20规则通常是一个良好的做法，以确定是否正在经历这种情况。通常将大约20％的请求作为简单传递处理，80％的请求具有与请求相关联的某些业务逻辑。但是，如果您发现此比例相反，并且大多数请求是简单的直通处理，您可能需要考虑使一些架构层打开，需要注意的是这样会让层次的耦合度提高，使软件变得不易改变。

分层体系结构模式需要注意的另一个问题是，它会使得应用程序变得monolithic[这个词不知道怎么翻译合适]，即使你将表示层和业务层分成单独的可部署单元。虽然某些应用程序不在乎这些问题[规模小的程序]，但它的确会带来部署，通用鲁棒性和可靠性，性能和可扩展性等方面的一些潜在问题。

模式分析(Pattern Analysis)

以下内容包含分层架构模式的常见架构特性的评级和分析。每个特性的评级基于适用于该模式的普通场景。对于此模式与本报告中其他模式如何相关的并行比较，请参见本报告末尾的附录A.

灵活性(Overall agility)

级别:低
分析:灵活性是针对不断变化的环境做出快速反应的能力。虽然可以通过该模式的层次隔离特点来应对变化，但是由于monolithic性质和这种模式带来的组件间紧耦合的特性，在该体系结构模式中进行改变仍然是繁琐和耗时的。

可部署性(Ease of deployment)

级别:低
分析:对于由该模式实现的大型应用程序来讲，部署可能会是一个问题。对组件的一个小改变可能需要重新部署整个应用程序（或应用程序的大部分），导致需要加班进行规划，调度和执行的部署。因此，此模式不适合进行可持续部署，进一步降低了部署的总体评级。

可测试性(Testability)

级别:高
分析:因为组件都隶属于某层，而且其他层可以被插桩或者模拟，所以该模式相对容易测试。开发人员可以通过模拟展示层中的组件中进行业务层中组件的测试，或者模拟业务层以测试某些展示层组件的功能。

性能(Performance)

级别:低分析:虽然一些分层架构可以很好地执行，但是由于必须经历架构的多个层以满足业务请求，效率较低，所以该模式不适用于高性能应用.

可扩展性(Scalability)

级别:低
分析:由于这种模式的紧密耦合和monolithic特点，使用此架构模式的应用程序构建通常难以扩展。您可以通过将层拆分为单独的物理部署或将整个应用程序复制到多个节点来扩展分层体系结构，但总体来说，粒度太分散，这使其扩展成本昂贵。

开发容易度(Ease of development)

级别:高
分析:易于开发获得相对高的分数，主要是因为这种模式是如此众所周知的，并且实现起来不太复杂。因为大多数公司通过分层（界面，业务，数据库）分离技能集来开发应用程序，所以这种模式成为大多数业务应用程序开发的自然选择。公司的沟通和组织结构之间的联系以及开发软件的方式被概述了所谓的 Conway’s law。

2.事件驱动架构(Event-Driven Architecture)

事件驱动架构模式是一个构建高扩展性程序的分布式异步架构模式。它还具有高度适应性，可用于小型应用和大型大型应用或者是复杂的应用。事件驱动架构由异步接收、处理事件的组件构成，这些组件是高度解耦和职责单一的。

事件驱动的架构模式由两种拓扑(topology)方式，即mediator和broker。当你想要在事件内编排一些步骤时需要mediator拓扑[wtf这句话]，而当您想要将事件链接在一起而不使用中央mediator时，你需要broker拓扑。因为这两种拓扑结构的架构特性和实现策略不同，所以了解每一种拓扑结构最适合您的特定情况是非常重要的。

Mediator拓扑(Mediator Topology)

Mediator拓扑适用于事件需要经过多个步骤处理的情况。例如，进行股票交易的一个事件可能需要您首先验证交易，然后检查该股票交易是否符合各种合规规则，将交易分配给经纪人，计算佣金，最后完成交易。所有这些步骤需要进行精心的安排,从而可以顺序的执行.

在Mediator拓扑又四部分组成:事件队列,事件mediator,事件通道和事件处理器.事件流从客户端向事件队列发送事件开始，事件队列用于将事件传输到事件mediator.事件mediator接收事件后,通过向事件通道发送异步事件来执行该事件的每个处理步骤.事件处理器监听事件通,并执行特定的业务逻辑来处理事件。图2-1说明了事件驱动架构模式的Mediator拓扑.

在事件驱动架构中，通常有十几到几百个事件队列。该模式不指定事件队列组件的实现; 它可以是消息队列，web服务端点或者其他什么东西。

该模式中有两种类型的事件：初始事件和处理事件.初始事件是由调解器接收的原始事件，而处理事件是由调解器生成并且由事件处理组件接收的事件。

事件mediator 组件负责协调初始事件中包含的步骤。对于初始事件中的每一步，事件mediator将特定的处理事件发送到事件通道，然后由事件处理器接收并处理。重要的是注意事件mediator实际上不执行处理初始事件所必需的业务逻辑; 它只知道处理初始事件所需的步骤。

事件通道被事件mediator异步地将初始事传递给事件处理模块. 事件通道可以是消息队列或消息topics，尽管消息topics和mediator拓扑通常放在一起使用的更多一些，使得处理事件可以由多个事件处理器（每个事件处理器基于接收到的处理事件执行不同的任务）来处理[我感觉这里消息队列和消息topics是两个并列的概念,消息topics是指的是每个事件都能被处理模块得到,有点像pub/sub,而消息队列指的是每个事件只能又一个处理模块得到,有点像pipeline]。

事件处理器组件包含处理处理事件所需的业务逻辑代码。事件处理器是在应用或系统中执行特定任务的自包含的(self-contained)，独立的，低耦合的架构组件[就是指业务模块]。尽管事件处理器组件的粒度可以从细粒度（例如，计算订单上的销售税）到粗粒度（例如，处理保险索赔）,重要的是每个事件处理器组件应该执行单个业务任务，而不依赖于其他事件处理器完成其特定任务[业务模块之间不应该产生相互依赖]。

事件mediator可以以多种方式实现. 作为架构师，您应该了解每个细节，以确保该模式的解决方案符合您的需求。

事件mediator的最简单和最常见的实现是通过开源框架，例如Spring Integration，Apache Camel或Mule ESB.这些开源集成中心中的事件流通常通过Java代码或DSL（领域专用语言）实现。对于更复杂的中介和编排，您可以使用BPEL（domain-specific language）以及BPEL引擎（如开放源代码Apache ODE）。 BPEL是一种标准的类似XML的语言，它描述了处理初始事件所需的数据和步骤。对于需要更复杂的编排（包括涉及人员交互的步骤）的非常大的应用程序，您可以使用业务流程管理器（BPM）（如jBPM）实现事件仲裁器。

理解您的需求并选择合适的事件mediator实现，对使用此拓扑的任何事件驱动成功至关重要。使用开源集成中心来执行非常复杂的业务流程管理编排是不正确的，就像实施一个BPM解决方案来执行简单的路由逻辑一样[宰牛不能用杀鸡刀,杀鸡不能用宰牛刀]。

为了说明mediator拓扑是如何工作的，假设你通过保险公司投保，并决定修改。在这种情况下，初始事件可能被称为重定位事件(relocation event)。处理重定位事件涉及的步骤包含在事件mediator中，如图2-2所示。对于每个初始事件步骤，事件中介器创建处理事件（例如，改变地址，重新计算报价等），将该处理事件发送到事件信道，并等待由相应的事件处理器处理的处理事件（例如，客户过程，报价过程等）。该过程继续，直到初始事件中的所有步骤都已被处理。在Event Mediator中,Recalc Quate和Update Claims上面的箭头代表这两个步骤可同时进行。

Broker拓扑架构[broker就是代理的意思]

Broker拓扑不同于mediator拓扑，因为没有中心事件mediator,消息通过轻量级消息代理（例如，ActiveMQ，HornetQ等)[Rabbitmq,zeromq]发布给业务组件。当您具有相对简单的事件处理流，并且您不需要中心mediator去安排更上层的业务流程，此拓扑非常有用[适合多数业务不太复杂的系统]。

该拓扑中有两种主要类型的架构组件：代理组件和事件处理器组件。代理组件可以是一个或者好几个(centralized or federated)，并且包含了所有的事件通道,这些通道涵盖在事件流内。代理组件中包含的事件通道可以是消息队列，消息主题发布或两者的组合。

此拓扑如图2-3所示。从图中可以看出，没有event-mediator组件来控制和编排初始事件; 相反，每个事件处理器组件负责处理事件并发布事件处理结果。例如，平衡股票投资组合的事件处理器可以接收称为股票分割的初始事件。基于该初始事件，事件处理器可以进行一些组合重新平衡，然后向代理发布称为重新平衡组合的新事件，其然后将由不同的事件处理器拾取。注意，可能存在事件由事件处理器发布但是没有别的处理器接受的情况出现。这是常见的,尤其是当您正在开发应用程序或提供未来的功能和扩展。为了说明代理拓扑如何工作，我们将使用与mediator拓扑中相同的示例。由于没有中央事件mediator来接收代理拓扑中的初始事件，客户过程组件直接接收事件，改变客户地址，并且发出该地址改变事件。在此示例中,有两个对更改地址事件感兴趣的事件处理器：报价过程和声明过程。报价处理器组件根据地址更改重新计算新的自动保险率，并向系统的其余部分发布事件指示它做的事情（例如，重新计算报价事件）。另一方面，声明处理组件接收相同的改变地址事件，但是在这种情况下，它更新未完成的保险声明并且向系统发布事件作为更新声明事件。这些新事件随后被其他事件处理器组件拾取，并且事件链继续通过系统，直到不再有针对该特定启动事件发布的事件.[这不就是pr系统的设计嘛] 从图2-4中可以看出，代理拓扑结构都是关于执行业务功能的事件总线。理解代理拓扑的最好方法是将其视为中继竞赛。在接力赛中，跑步者持有接力棒并运行一定距离，然后将指挥棒交给下一个跑步者，依此类推直到最后一个运动员穿过终点线。在接力赛中，一旦运动员交出指挥棒，她就完成了比赛。这对于代理拓扑也是如此：一旦事件处理器切换事件，它不再参与该特定事件的处理。

注意事项(Considerations)

事件驱动的架构模式是一个相对复杂的模式实现，主要是由于它的异步的特点。当实现这种模式时，您必须解决各种分布式架构问题，如远程进程可用性，缺乏响应性和代理重新连接逻辑事件代理或mediator失败。

这种架构模式适用于缺少原子性事务的业务流程。因为事件处理器组件是高度去耦合和分布式的，所以很难跨越多个业务组件的同时去维护业务的事务特点[ACID]。因此，在使用此模式设计应用程序时，必须不断考虑哪些事件可以独立运行或者不单独运行，并相应地计划事件处理器的粒度。如果您发现由多个事件处理器构成一个工作单元，换句话说,如果您使用分散的处理器来处理不可分割的事务，在这种情况下,该模式可能不适合您的应用程序。

事件驱动的架构模式的最困难的方面之一可能是事件处理器组件之间契约(contracts)的创建，维护和管理。每个事件通常具有与它相关联的契约形式（例如，数据值和数据格式).使用此模式来建立标准数据格式（例如，XML，JSON，Java对象等）并从一开始就建立契约的版本控制策略至关重要[业务模块之间的接口很重要,也非常容易发生变化!!!]。