软件架构模式 mark Richards - 读后总结 2 事件驱动架构

事件驱动架构模式是一种主流的异步分发事件架构模式，常用于设计高度可拓展的应⽤用。当然了，它有很高的适应性，使得它在小型应用、大型应用、复杂应用中都能表现得很好。事件驱动架构模式由高度解耦、

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

中介 ( Mediator )拓扑结构

代理 (Broker) 拓扑结构

中介 ( Mediator )拓扑结构

中介拓扑结构适合用于拥有多个步骤，并需要在处理事件时能通过某种程度的协调将事件分层的场景，

举例(股票交易) ：

1.首先需要证券所批准交易，检查这次交易是否违反了股票交易的某种规定，
2.检查完成后将它交给一个经纪人，计算佣金，最后与经纪人确认交易。

以上所有步骤都需要通过中介进⾏行某种程度的分配和协调，以决定各个步骤的执行顺序，判断哪些步骤可以并行，哪些步骤可以串行。
在中介拓扑结构中主要有四种组件：
事件队列（event queue）, 事件中介, 事件通道（event channel）, 和事件处理器（event processor）。
当事件流需要被处理，客户端将一个事件发送到某个事件队列中，由消息队列将其运输给事件中介进⾏行处理和分发。事件中介接收到该消息后，并通过将额外的异步事件发送给事件通道，
让事件通道执行该异步事件中的每一个步骤，使得事件中介能够对事件进行分配、协调。同时，⼜又因为事件处理器是事件通道的监听器，
所以事件通道对异步事件的处理会触发事件处理器的监听事件，使事件处理器能够接收来⾃自事件中介的事件，执⾏行事件中具体的业务逻辑，从而完成对传入事件的处理。事件驱动

中介拓扑模式结构大体如下图：

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

初始事件: 是中介所接收到的最原始的事件，没有经过其他组件的处理；

待处理事件: 是由事件中介生成，由事件处理器接收的组件，不能把待处理事件看作初始事件经过处理后得到的事件;

事件中介负责分配、协调初始事件中的各个待执行步骤，事件中介需要为每一个初始事件中的步骤发送一个特定的待处理事件到事件通道中，触发事件处理器接收和处理该待处理事件。
这里需要注意的是：事件中介没有真正参与到对初始事件必须处理的业务逻辑的实现之中；相反，事件中介只是知道初始事件中有哪些步骤需要被处理。
事件中介通过事件通道将与初始事件每一个执行步骤相关联的特定待处理事件传递给事件处理器。尽管我们通常在待处理事件能被多个事件处理器处理时才会在中介拓扑结构中使用消息主题，
但事件通道仍可以是消息队列或消息主题。（但需要注意的是，尽管在使用消息主题时待处理事件能被多个事件处理器处理，由于接收到的待处理事件各异，所以对其处理的操作也各不相同）

代理 (Broker) 拓扑结构

代理拓扑结构与中介拓扑结构不同之处在于：

代理拓扑结构中没有核心的事件中介；相反，事件流在代理拓扑结构中通过一个轻量的消息代理（例如：ActiveMQ, HornetQ，等等……）将消息串联成链状，

分发至事件处理器组件中进行处理。代理扑结构适用的使用场景大致上具有以下特征：你的事件处理流相对来说⽐比较简单，而且你不想（不需要）使用核心的事件分配、调节机制以提高你处理事件的效率。

在代理拓扑结构中主要包括两种组件：

代理和事件处理器。代理可被集中或相互关联在一起使用，

此外，代理中还可以包含所有事件流中使⽤用的事件通道。存在于代理组件中的事件通道可以是消息队列，消息主题,或者是两者的组合。代理拓扑结构大致如下图，如你所见，

在这其中没有一个核心的事件中介组件控制和分发初始事件；相反，每一个事件处理器只负责处理一个事件，并向外发送一个事件，以标明其刚刚执行的动作。

例如，

假如一个事件处理器用于平衡证券交易，那么事件处理器可能会接受一个拆分股票的初始事件，为了处理这项初始事件，事件处理器则需要重新平衡股票的投资金额，而这个重新平衡的事件将由另一个事件处理器接收、

处理。在这其中一个细节需要注意：处理初始事件后，由事件处理器发出的事件不被其他事件处理器接收、处理的情况时常会发生，尤其是你在为应用添加功能和进行功能拓展时，这种情况更为常见。

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

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

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

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

易于开发：低

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

中介和代理似乎没什么区别，尤其是了解 proxy 的读者会更加困惑，这三者之间到底是什么关系？它们的概念是互通的吗？为了解决这种混淆，译者将在此阐述三者间的区别：

mediator：将把事件流交给 mediator，会把事件分解为多个步骤，并分析其中的执行逻辑，调整和分发事件（例如判断哪些事件可以并行，哪些事件可以串行），
然后根据 mediator 分解、调节的结果去执行事件中的每一个步骤，把所有步骤完成后，就能把需要处理的事件处理好。

broker：把事件交给 broker，broker 获得事件后会把事件发出去（在本文中为：通知架构中所有可用的事件处理器），
事件处理器们接收到事件以后，判断处理这个事件是否为自己的职责之一，如果不是则无视，与自己有关则把需要完成的工作完成，完成后如果事件还有后续需要处理的事件，
则通过 broker 再次发布，再由相关的事件处理器接收、处理。以这样的方式将事件不断分解，沿着事件链一级一级地向下处理子事件，直到事件链中的所有事件被完成，我的事件也就处理好了。

proxy：自己对需要处理的事件进行了分解，然后把不同的子事件委托给不同的proxy，由被委托的proxy 帮我完成子事件，从而完成我要做的事件