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

原文地址  译者：克里斯托刘

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

事件驱动架构模式有两种主要拓扑结构，“调度员”（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所示。对于每个初始事件步骤，事件调度员创建一个处理事件（如改变地址，重新计算报价等），发送处理事件给事件通道，并等待相应的事件处理模块处理完事件（如用户处理，报价处理）。处理工作持续到整个包含的处理事件执行完毕。图中，在重计算报价和更新声明两个步骤中的单一进度条说明，这些步骤是可以同时进行的。