[译文] 实现类Web应用灵活性的RESTful核心——第2部分——微内核

原文：A RESTful Core for Web-like Application Flexibility - Part 2 - Microkernel

作者：Jim Ladd

出处：http://www.theserverside.com/news/1363811/A-RESTful-Core-for-Web-like-Application-Flexibility-Part-2-Microkernel

 

引言

 

许多的IT体系架构依仗多个系统来成功完成复杂的事务，这些系统必须协调和同步他们的动作，以便能够顺利地兑现预期要共同实现的功能。随着需要协调的活动的复杂性的增加，监控每个系统的必要性也提升了。跨系统的事务监控使得能够洞察每个原子事务的状态、原子事务在复杂过程中的贡献以及整个系统的性能。

监控和勘漏程序对总的计算负荷的贡献加大意味着可以通过提升监控解决方案的能力来提高业务的性能。只要监控解决方案在事务失败时能够快速地采取行动，在需要人工干预时通知支持人员，以及预报即将会发生的系统运转问题的话，那么整个系统的性能就会得到增强。

监控简单的事务过程很容易，但是要监控复杂的过程则是很难的。当复杂的过程跨越了多个几乎不怎么提供互操作性支持的商用成品（Commercial-Off-The-Shelf ，COTS）系统时，监控任务会变得非常、非常的困难。本文介绍了XML事务监控器（XML Transaction Monitor，XTM）是如何对付这些与跨系统事务监控相关的挑战的，以及Physhun框架是如何证明自己是整个解决方案中的一个不可或缺的部分的。

我们的公司Wazee Group是Physhun项目的发起人之一，几年前，我们就注意到有限状态机（finite state machine，FSM）技术在开源界还是一个空白，一开始我们的工作人员使用二十年前的FSM作为替代，但却发觉那是一种被错误理解了而且是还未被充分利用的技术。结合我们在FSM方面的专业知识以及回馈开源社区的愿望，我们的同事Justin McCarter发起了Physhun项目，虽然XTM是第一个部署到24/7环境中的Physhun项目，但是我们相信该框架能够应用到许多其他的项目和问题领域中。

 

背景

 

用于订单录入和履行的IT体系结构由四个主要的系统组成，外部客户端（External Client）是一个属于并由业务交易伙伴来操作的系统，贸易伙伴希望通过基于XML的请求来发送信息以提交和管理订单，并通过基于XML的通知来接收订单状态的更新。

对于企业的内部来说则是两个面向业务的系统，订单录入（Order Entry，OE）系统是一个COTS包，其允许一般人作为用户录入并管理订单，一旦订单被录入且通过了各种业务过程的确认，订单就会被发送给订单履行（Order Fulfillment，OF）系统以完成交易。订单履行系统是另一个COTS包，当OF完成它的内部处理时，就有通知被发送回订单录入系统；同样，一旦订单录入系统完成订单处理时，就有通知被发送到外部客户端，下面展示了一个高层面的示意图。

 

 图1：高层面的逻辑体系结构

 

第三个内部的组成部分是XML事务路由器（XML Transaction Router），这一系统把XML请求和通知发送给适当的系统，该路由器由一个带有自定义配置的商业应用组成。

监控解决方案的基本高层面需求包括：

1.         记录请求和通知。

2.         当事务超时时发送告警信息。

3.         当事务处理速度变慢时发送告警信息。

4.         允许用户查阅失败的事务。

5.         允许用户重新提交失败的请求和通知。

 

事务过程建模

 

我们首先分析应用需求方面的事务模型，以便能够确定被建模过程的复杂性。虽然高层面的体系结构非常简单，但事务的过程模型却值得仔细地研究。以下是对处理一个新订单过程的一个初步研究，这是对“适当路径（happy path）”的描述，并没有包含任何的失败分支。

1.         路由器收到来自外部客户端的新订单请求。

2.         生成作为请求/回复（request/reply）协议的一部分的响应。

3.         路由器确定处理该请求的适当的内部系统，在本例中是订单管理（Order Management，OM）系统。

4.         路由器把请求转发给OM系统并接收来自OM系统的答复。

5.         OM系统创建了一个内部订单，开始处理包括了自动的和人工的作业两者。

6.         在内部处理的适当时刻，OM系统向订单履行系统发出一个XML请求，该请求经由XML路由器发送给OF系统。

7.         OF开始了它的内部处理过程，该过程也包括了自动的和人工的步骤。

8.         当订单处理完成时，OF系统向OM系统发送通知，通知包括订单中的单项的完成和订单本身的完成。通知通过XML路由器系统来路由。

9.         相应于每个通知的响应作为通知/响应（notification/response）协议的一部分被返回给OF。

10.     一旦OM收齐所有的单项的通知和最后的整个订单的通知，其就会经由XML路由器发送一个通知给外部客户端。

11.     路由器接收通知并发送一个响应回给OM。

 

在对所有场景进行分析之后，建模过程变得相当的复杂，例如，在取消订单这一处理过程中，当OM系统接收到订单时，会有五个事件发生：

1.         请求可被立即发送给OF系统。

2.         请求可在OM中排队以人工处理。

3.         请求可被立即处理完成而无需与OF系统交互。

4.         请求在OM中可能会超时，这是指在指定时间段内应该触发某事件但实际上没有。

5.         通知可能会被客户拒绝。（项目发起人假设XML路由器总是在正常运作中的）

 

对取消订单的状态迁移图的最初的和不完整的分析如下所示：

 

 

 图2：取消订单的状态迁移图

 

很显然，取消订单的状态迁移模型并非小事一件，取消订单的过程是被监控的不同过程中复杂程度最低的。监控包括检测、记录和管理经由四个系统处理的每个订单的生命周期中的每一个XML事务。由于过程显著的复杂性和面向状态的特性，我们于是做出了使用有限状态模型技术来为生命周期建模的决定。

 

有限状态模型

 

有限状态模型（FSM）已经在各个行业广泛应用许多年了，使用了有限状态模型技术的项目例子包括通信系统、汽车行业、航空电子系统及人机交互界面等。这些问题领域有着共同的特征：他们通常规模大，复杂性高，且具有反应的特点。这些领域的一个主要挑战是难于同时以正式的、严谨的而又明确、简洁、完整的方式来描述反应的行为。

有限状态模型提供了一种描述大型复杂系统的方法，FSM把这些系统看作进出事件、条件和行动的一个组合。FSM还提供了一组评估和处理事件、条件和行动的规则，把问题分割成事件、条件和行动，结构化处理环境，以及表达处理逻辑的容易性是FSM最重要的优势。

XTM有限状态模型的基本组成部分包括：

状态（State）代表了在任一指定时刻系统的“存在模式”，状态包含了一组进入事件和退出事件，当进入该状态时，进入事件被发布或是广播；退出事件则在退出该状态时发布。

迁移（Transition）描述了从指定状态到另一状态的单个路径，所有迁移的集合描述了在定义的状态之间的所有可能路径。一个迁移包含了其认订的一个事件、一个条件及一个行动。迁移还包含了其正从中退出的状态（即 “所从”的状态）以及其正在进入的状态（即“所到”的状态）。

事件（Event）是系统用来与外部系统及本身交互的一种机制。

条件（Condition）代表了用来计算一个布尔类型结果的一套逻辑，其被用来确定是否该激活某个迁移。

行动（Action）是迁移被激活时要完成的处理过程。

 

一个典型的FSM组件示意图如下所示：

 

 

 图3：FSM组件

 

 

既然过程的建模利用了有限状态机技术，那么对于XTM项目的实现来说，使用FSM技术就是一个逻辑步骤了。从理论上来说，从分析模型过度到设计工件和实现代码应该是顺利且不需要费多大功夫的，代码库的实现要求如下：

1.         易于使用——框架必须简单，有较快的学习曲线，一个很大的好处是利用可视化过程模型的图形化开发环境。

2.         完善——框架必须完全支持包括层次和并发模型在内的FSM技术。

3.         支持持久性和事务——由于过程模型的运行时间长久，因此信息必须被持久化并且是在事务上下文内持久化，框架应该提供内置的事务功能，并支持不同的持久性选择。

4.         基于Java——由于客户端的开发标准，因此代码必须是基于Java的。

5.         廉价——由于项目是“基础建设”的初级阶段，因此获批的预算非常少，花费应尽可能地减少。

 

在考虑了几种选择，其中包括自编代码之后，我们选中了Physhun框架。Physhun是一个提供了强大的FSM引擎的开源项目，它允许在J2SE和J2EE两种环境之中建模、构建和执行FSM过程模型。Physhun支持一些先进的FSM概念，比如层次（即嵌套）状态、并发状态、长时间生命周期、持久性以及事务等，还免费提供了一个图形化的过程建模工具，作为开源软件来说，其价格是适宜的。Physhun满足了这一项目的所有要求。

 

事件的生成

 

对于任何FSM引擎来说，如果要做有意义的工作，其必须用来自外部世界的事件进行表示。虽然理论上很简单，不过在实际中实现这一做法是非常困难的。事件的生成包括了三个核心步骤：

1.         观察数据——FSM系统必须已经访问了导致事件生成的信息，这有可能是改变了对过程模型来说很重要的应用内部数据，如果数据不能被访问的话，那么相应的事件就无法生成。

2.         检测——一旦观测到信息，FSM系统就必须检测数据的相应变化（或者没有变化），这需要过滤数据领域以找出导致事件创建的模式。事件的生成并不取决于过程实例的内部状态，如果条件满足创建某个事件的根据的话，那么该事件总是会被提交给FSM引擎。因为有用事务的集合是有限的，因此过滤可能只会在该集合上进行，以便能够优化性能。在某些情况下，事件检测可能会跨越多个观察来源。

3.         关联——事件一旦被创建，其通常就会被关联到某个特定的过程实例，关联原则可以会很简单，比如使用直接映射到过程实例的唯一业务数据标识符；也可能是复杂的，需要多个跨不同数据源的数据访问。

 

就XTM这一解决方案来说，所需的观察数据由单个数据源组成。XML事件路由器则是一个可自定义配置的商业成品（COTS）包，该系统被配置成把每个事务（即请求/响应数据和通知/响应数据）加入到XML兼容的关系数据库中。

XTM项目的事件生成被委派给了一个单独的Java程序，数据库扫描器（Database Scanner）负责审查有XML事务路由器（XML Transaction Router）处理的XML事务，当扫描器检测到适当的条件时，事件被生成并提交给Physhun引擎以进行处理。一个高层面的组件示意图如下所示：

 

 

 图4：XTM的高层面组件

 

复杂事件生成的关键要求之一是，必须要维持事件的时间顺序。如果不按照顺序处理事件的话，那么事件可能会被忽略，而就建模真实世界的事件这一方面来说，过程实例实则失效了。例如，如果在接收创建事件并创建订单#45559的过程实例之前，订单#45559的这一订单录入（Order Entry）和订单履行(Order Fulfillment)之间的事件就被提交给Physhun引擎的话，那么该OE-OF事件可能会被暂时忽略，稍后再处理，又或者是被永远丢弃。

对于一个使用了FSM技术的解决方案来说，在选择事件生成策略时必须做慎重的考虑，事件数量的平衡、处理的负载、响应时间等等，都必须逐项逐项地去获取相应的数据。就XTM项目而言，由于所有的XML事务都以带时间戳的方式记录在XML事务数据库中，因此我们构想了一个这样的扫描器，它能够按照时间顺序及XML事务本身的顺序来搜索事件。如果没有可用的时间戳信息的话，那么就需要使用复杂的信息来对扫描器编程，以便让它能够正确地给事件排序。

 

运行时引擎

 

XTM解决方案的核心是基于Physhun的有限状态机引擎，该引擎负责接收来自不同扫描器的事件并处理这些事件，以及维持过程模型实例的状态，其创建并维持十一种不同的过程模型实例，每种模型由单个配置文件组成，这一XML文件包含指明了模型的状态、迁移和行动的Spring配置信息，这些信息是Physhun引擎的“执行指南”。

使用Physhun引擎所带来的最大的开发工作是制定一个用来保留过程实例信息的模式（schema），我们的客户端规定的数据库是Oracle 9，因此我们的持久性机制必须兼容这一数据库服务器。我们设计的模式（schema）基于非常简单的关系模型，如下所示：

 

 

 图5：FSM数据库模式

 

Physhun Modeler

 

对于简单的模型来说，引擎所使用的基于Spring的配置能够手工地生成，但是对于有规模的模型来说，配置的复杂性甚至有可能会令最有能力的设计者束手无措。既然使用FSM技术的目的之一是简化复杂的问题，因此我们建议使用Physhun的建模工具Modeler。Modeler支持可视化地构造和维护过程模型，并允许随着项目的发展而做快速方便的修改。Modeler的输出是基于Spring的配置文件，以及包含了Modeler所使用的可视布局信息的XML项目文件。

最初的过程模型被输入到Modeler这一工具中，然后在整个项目开的发生命周期中逐渐地发展进化。状态和迁移在主绘图区域中显示，从最初的分析模型（早前在图2中所展示的）变化而来的取消订单过程模型如下所示。

 

 

 图6：取消订单的过程

 

由于行动和条件是迁移的有机组成部分，因此他们必须在完成迁移之前就被指定，在Modeler中，有一个条件编辑器（Condition Editor）被用来维护指定条件的信息，条件的Spring类型配置也展示如下。

 

 

 图7：取消订单的条件

 

行动编辑器（Action Editor）被用来创建和维护指定行动的信息，行动编辑器如下所示。

 

 

 图8：取消订单的行动

 

一旦创建了相关的行动和条件，就可以在迁移编辑器（Transition Editor）中创建迁移，在该编辑器中，为指定的迁移输入名称、条件和行动信息，在以下对话框中，Spring类型的配置显示在文本区中。

 

 

 图9：创建迁移

 

随着对问题的理解逐渐加深，以及解决方案需求的增长，我们的过程模型会变得越来越复杂，为了保持模型图的可理解性，我们会使用层次化了的模型。虽然从数学上来说相当于单层的模型，但是嵌套模型能够简化层次内的每一个级别的处理模型，使得他们更能为一般人所理解，并能够减轻模式维护的认知负担。在之前展示的取消订单这一过程模型中，Nested_CancelOrderToOF状态就是一个嵌套的状态，它由一个更低级别的过程模型中的一个子状态组成，该更低级别的模型是CancelOrderToOF模型，如下所示。

 

 

 图10：CancelOrderToOF模型

 

同样的，CancelOrderToOF过程模型中的Nested_OFOrder状态对应OFOrder过程模型，如下所示。

 

 

 图11： OFOrder模型

 

小结

 

很显然，XTM项目所具备的功能不仅仅是本文所展示的这些，作为开发的解决方案其还包括收集和呈示基于事务的衡量指标、各种各样的汇报方法、错误的通知以及潜在的性能问题等。所有这些方面的实现都使用了有广泛知名度的技术和框架。XTM项目的基石是Physhun框架，该框架的应用使得能够由单个开发者在指定的时间表和预算内设计、开发及部署XTM项目。