《软件架构模式》-第二章事件驱动架构(下)
原文地址 译者:克里斯托刘
经纪人拓扑结构(Broker Topology)
经纪人拓扑结构和调度员拓扑结构不同点在于,没有中央事件调度员,而是:消息执行流程沿着类似链条连接的各个事件处理模块,通过轻量级的消息经纪人(比如AcitveMQ, HornetQ)实现。这样的拓扑结构,在你只需要处理一个相对简单的事件处理流程,同时不想要中央事件调度员时候,特别适用。
在经纪人拓扑结构中,有两种主要的模块:经纪人模块和事件处理模块。经纪人模块可以是集中的,包含所有的用于事件处理流程的事件通道(event channel),该事件通道可以做成消息队列或者消息主题(message topics),或者两种的结合。
该拓扑结构如图2-3所示。从图中,你可看到,它没有中央事件调度员控制和编排初始事件。每个事件处理模块负责响应一个事件并会发布出新的小事件(该小事件就是它执行过的事件)。例如,一个负责平衡股票投资组合的事件处理模块可能会收到一个股票分离的初始事件消息。基于这个初始事件,该事件处理模块会做一些平衡股票投资组合的操作,然后发布一个新的称为重新平衡投资组合的事件消息给经纪人,这个事件消息又会被其他事件处理模块所执行。注意也会有新的事件消息被发布出来,却没有事件处理模块处理的情况。这在当扩展你的应用和为开发未来的功能的时候常见。
我们用在调度员拓扑结构的同样的例子来说明经纪人拓扑结构如何工作。由于没有中央事件调度员去接收初始事件,因此客户处理模块直接接收事件,改变客户地址,发送一个事件说明它改变了客户地址。在这个例子里,有两个事件处理模块对改变地址这一事件感兴趣的:报价处理模块和声明处理模块。报价处理模块基于改变的地址重计算新的保险汇率,并且对剩下的系统发布事件告知它做了什么。另一方面,声明处理模块接收到地址更改的消息,更新保险声明并发布声明更新的事件消息。这些新事件又会被其他的事件处理模块接收,事件链会继续贯穿整个系统直到没有更多得事件被发布位置。
从图2-4,你可以看出,经纪人拓扑结构是关于执行一个业务功能的事件链。可以想象它是一个接力比赛。在接力比赛中,运动员拿起跑步棒,跑过一段路程,然后就递交给下一名运动员,按照这样的流程,一直到最后一名运动员跑完整个路程。经纪人拓扑结构即是这样的。
考量
事件驱动结构模式实施起来是相对复杂的,这主要归于它异步分布的特征。当实施这个模式的时候,你必须解决不同的分布架构的问题,比如远程进程的可能性,回复的缺失性,问题发生时经纪人重新联结的逻辑。
当选择此结构模式需要考虑的另一个是问题是缺少原子量级上的执行操作。因为事件处理模块是高耦合度和分布的,所以维持一个单一的执行交易单元很难。因此,当用这个模型设计你的系统,你需要持续地思考哪些事件可以或者不可以独立运行,以此计划你的事件处理模块的粒子度。如果你发现你需要分散一个作业的单元到不同的事件处理模块—即,如果你需要把一个不可分割的交易分散到独立的处理模块—这说明你选用的是不对的模式。
也许一个最难的方面是创建、维持、管理事件处理模块的协议。每个事件通常有与它联系的独立协议(比如传递的数据和数据格式)。当使用这个模式,解决标准数据格式(XML, JSON, java实例等),并从一开始建立协议版本管控政策是很重要的。
模式分析
下面的表格包含各项平常架构特征的评分和分析。
整体敏捷度
评分:高
分析:整体敏捷度是反映是否能快速适应变化环境的能力。由于事件处理模块是单一用途并完全的和其他事件处理模块接触耦合,改变通常只在于一个或几个事件处理模块,并可以被快速执行而不影响其他模块。
部署容易性
评分:高
分析:总的来说,这个模式是相对容易部署,这由于事件处理模块间解耦的关系。经纪人结构比起调度员结构更易于部署,主要由于事件调度员模块和具体执行事件的处理模块是耦合的,所以事件处理模块上出现的改动,可能要求事件调度员模块上也有相应的改动,这需要改动双方都需要重新部署。
测试容易性
评分:低
分析:虽然独立事件处理模块的单元测试不艰难,但这需要一些专门的测试客户端或测试工具去产生事件。同时异步性也增加测试难度。
表现
评分:高
分析:虽然也有实施的事件驱动模型运行表现不好的情况(这可能关系消息结构),通常,该模型能达到更好的效果,通过它的异步执行能力。换句话说,解耦同时异步操作优点远远掩盖了接发消息开销的弱点。
扩展性
评分:高
分析:扩展性是该模式的高独立性及解耦的事件处理模块两个特征,所自然达成的。每个事件处理模块可被单独扩展。
开发容易性
评分:低
分析:由于异步的特征、契约创建、更高级的错误处理机制使得开发过程会相对更复杂。
原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: 《软件架构模式》-第二章事件驱动架构(下)
很不错的架构模式