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

事件驱动架构模式是一个很是流行的异步分布模式，可生成高可扩展性应用。并且它也具备强适应能力，可被用于小程序或者大型复杂程序。事件驱动架构是由高耦合度、单一目的的事件处理模块构成，这些模块异步接收、处理事件。

事件驱动架构模式有两种主要拓扑结构，“调度员”（mediator）和“经纪人”（broker）拓扑结构。“调度员”拓扑结构一般用在一个事件中由多个步骤组成，而你须要经过中央“调度员”模块去调度这些步骤。然而“经纪人”结构是当须要执行一系列事件链，而不须要中央“调度员”模块。因为这两种结构的特征和执行策略不一样，深刻理解二者的用法能帮助你在本身的案例中作出正确的判断。

调度员拓扑(Mediator Topology)

若是应用中的事件由多个步骤组成，而且要求必定程度的调度去执行事件，对于这样的状况，“调度员”拓扑颇有帮助。例如，一个处理股票交易的单独事件可能须要如下步骤，首先验证交易，而后检查股票交易是否符合不一样的监管条例，指派交易给一个经纪人，计算佣金，最后把交易放置给指定的经纪人。全部这些步骤要求有必定的事件调度机制去决定步骤的顺序以及哪些步骤要顺序或者并行执行。

结构上，该拓扑结构由4个主要部分组成：事件队列，事件调度员（event mediator）,事件通道，事件处理器。事件流程按照：客户发送初始事件到事件队列，事件队列传递初始事件给事件调度员，事件调度员在收到初始事件后，把初始事件转化为多个小事件，而后经过异步发送这些小事件给事件通道，实现调度。每一个小事件都是执行业务的一个步骤，其对应的每一个事件处理器监听事件通道，当收到事件后，执行指定的业务逻辑来处理业务。图2-1描述了大致的调度员拓扑结构模式。

在一个事件触发结构，一般会有一打到几百的事件队列。这种拓扑模式没有指明事件队列模块具体实现方式，它能够是消息队列，网络服务终端或者任何组合。

在这种拓扑结构中，它有两种事件：初始事件和处理中的事件。初始事件是原始事件调度员收到的事件，而处理中的事件是由调度员产生的，由事件处理模块监听接收的事件。

事件调度员模块负责调度安排全部包含在一个初始事件的子步骤。对于每一个包含的步骤，调度员会发出指定的处理事件给事件通道。事件通道收到后，由事件处理模块进行处理。重要的一点是，事件调度员实际不进行任何业务逻辑的处理，但它清楚全部处理的步骤。

事件调度员利用事件通道去异步传输特定的处理事件。事件通道能够是消息队列或者消息主题(message topics)，尽管消息主题更普遍使用在调度拓扑结构，以致于处理事件过程能够被多个事件处理模块处理（每一个模块处理不一样的工做，根据接收的处理事件）。

事件处理模块包含应用的业务逻辑去处理事件。事件处理器是闭环的、独立的、高耦合度的模块，在应用和系统中执行指定的任务。然而事件处理模块的细致程度（granularity）既能够设计成细粒度（如计算订单销售税）或者粗粒度（如处理保险索赔）。整体而言，从设计上来讲，事件处理模块须要处理一个单一业务任务，不能依赖于其余模块。

事件调度员能够以多种方式实现。做为架构师，你须要理解不一样的实现选项，从而找出最符合你的须要和要求的一种。

事件调度员最简单和最广泛的实现方式是经过开源集成中心，好比Spring Integration, Apache Camel, 或者 Mule ESB。这些开源集成中心的事件流一般由JAVA或者DSL执行。对于更负责的调度和编排，可使用BPEL（业务处理执行语言），并结合BPEL引擎，例如开源Apache ODE。BPEL是一个标准的类XML语言，它描述了处理初始事件的数据和步骤。对于大的要求更多复杂调度的应用，你可使用BPM例如jBPM去实现事件调度员。

理解你的需求和找到匹配的事件调度模块实现方式是很重要的。利用开源集成环境中心去作复杂的业务处理管理是典型的失败范例，就如使用BPM方案去执行简单的业务逻辑。

举例描述调度员拓扑结构如何工做，假设你经过保险公司投保同时你决定搬家。在这个案例中，初始事件能够被称为重定位事件（relocation event）。处理定位事件中涉及到每一个事件调度员使用的处理事件，如图2-2所示。对于每一个初始事件步骤，事件调度员建立一个处理事件（如改变地址，从新计算报价等），发送处理事件给事件通道，并等待相应的事件处理模块处理完事件（如用户处理，报价处理）。处理工做持续到整个包含的处理事件执行完毕。图中，在重计算报价和更新声明两个步骤中的单一进度条说明，这些步骤是能够同时进行的。

(全文完)