某大型银行深化系统技术方案之八：核心层之异步流程控制机制

传送门☞Android兵器谱☞转载请注明☞http://blog.csdn.net/leverage_1229

核心层

核心层主要提供后台业务集中处理中最基本、共性的信息处理、流程调度和相关的管理功能，如任务调度、路由确定、事务一致性管理、任务拆解合并、优先级管理等。核心层对业务处理中的各项工作进行高度的抽象，只管理共性的属性和操作，功能相对简单，具有较高稳定性和处理效率，并对外部服务提供基础调用接口。

异步流程控制机制
把当前工作项的提交动作和下一个工作项的生成动作分开，成为两个原子操作；当用户提交一个工作项时，只返回当前该工作项数据提交成功与否的结果，而不继续实时计算生成下一个工作项，下一个工作项的生成由后台引擎异步处理，这样避免了两个操作的串行，以获得更高的吞吐量、效率。
当用户提交给流程引擎一个工作项时，将不需要经过流程引擎计算经历长时间的等待，而是立即返回给用户提交成功与否的结果；流程引擎将通过后台的引擎来处理提交，从而产生新的工作项。异步流程引擎方式是典型的流水线、工厂化模式，他通过释放系统等待资源，获取了高吞吐量、高效率。
流程引擎支持异步处理。异步处理中，当用户提交给一个工作项时，立即返回给用户提交的成功与否结果而不是引擎的处理结果，也就是说提交后并不马上交给引擎处理，而是放入一个待解析队列中，由引擎自动检查该队列，一旦发现有待解析流程后，取出该流程解析。异步申请的好处是，在服务器压力较大时，异步处理的用户体验较好。在用户提交后马上离开该页面，以避免在等待引擎解析时，页面长时间无反应，这样对用户来说，他可以马上进行其他操作，在数秒之后，即可以追寻表单，查看流程行进状况；其次，异步机制提供了用来提出负载平衡请求的简单方式、提供了容错能力、支持断续连接的系统等，其中的每个优点都是通过异步模式对应用程序中不同部分进行去耦处理的结果。要让某个处理具有异步特点，就必须建立某种形式的队列来保存挂起的请求，该处理中的每一个步骤都只能与这些中间队列进行通信，而不能直接与其上一步或下一步进行通信。

一、响应时间更快

在同步系统中，用户在整个操作结束之后才得到响应。在异步系统中，提交节点之后，客户的延迟时间仅仅是将该工作项传递给处理中的下一步所花费的时间。在某种程度上，这样的更快响应时间只是一种假象，因为客户收到响应时该处理并未真正完成，但客户不需要再等待了，这是重要的优点。

二、负载均衡
异步处理所要求的基础体系结构能够在不增加额外软件的情况下轻松地提供灵活的负载平衡能力。在异步系统中，需要某种形式的中间存储或队列来存储步骤之间的请求。当一份工作项完成了某步骤中的处理工作时，它就被放到队列中等待进行下一步处理。当下一个步骤准备好处理另一份工作项时，它就从这种挂起请求列表中抓取一份工作项。要完成这样的系统中负载平衡的实施，只需要增加计算机的数量，由它们处理挂起列表中对步骤B的请求。

采用中间队列之后，在负载平衡和可伸缩性方面都获得了很大的灵活性。在该系统的前端或后端都可以放置任意数量的计算机，而且这种灵活性适应于任何一个处理步骤。可以在每一个步骤中使用适当数量的硬件对系统的性能进行微调，也可以在一台计算机上将多个步骤结合在一起进行处理。

三、容错能力
对灵活的负载平衡提供支持的功能同时也就是对容错能力提供支持的功能。如果某个软件或硬件故障删除了某个处理步骤，请求执行该步骤的那些挂起请求就在队列中等候直至该服务被恢复。这对处理中先前的步骤并不产生什么实际的影响，尽管总体处理时间可能由于故障而延长。如果遵循了上一节关于负载平衡所讨论的技术，很可能仅仅减缓某一步骤的处理，但并不会停止。同样的功能也可以通过使用群集方式来提供；群集可以在不进行任何负载平衡工作的情况下提供故障转移能力。

在负载平衡的系统中，处理同一步骤的其他服务器可以继续从队列中截获请求；如果各服务器都已经以接近峰值的状态运行，整个系统的性能将下降。

四、通知或轮训状态

在同步系统中，调用处理要等待调用返回之后才继续向下执行，即将完成工作项提交给流程引擎时，同时引擎将计算下一个节点，产生新的工作项，并插入数据库生成的新工作项ID。如果对流程引擎进行同步调用，可以立即返回处理结果，也可以表明该工作项是否已经成功地添加到数据库中。但在异步系统中，虽然发出了提交完成工作项的请求，但是实际的计算和插入动作却未同时发生，此时无法返回实际的计算结果，系统也不知道流程是否成功。在这种情况下，将在对请求的提交进行处理时同步生成 ID，由此获得 ID 并在随后以异步方式将该请求传递给处理的其余部分，这个ID可以使由引擎产生也可以根据UUID由客户端产生，只要保证提交时拥有唯一的ID即可。调用者可以使用某种形式的轮询机制使自己负责查询状态。

五、超时处理
异步处理方式让您不必等待每一步都完成；但仍需要考虑整个处理需要多长时间才能结束的问题。为了保证工作项或者正在处理的任何形式的请求最终不会等待过长时间才能处理完毕，需要一种方法来指定每个异步请求允许花费的最长时间。实施超时机制是防止订单在系统中耽搁好几天的唯一办法。
六、补偿逻辑
补偿逻辑与数据库中的事务回滚概念相关，它在处理彻底失败时撤销任何已经完成的操作。在同步系统中已经提供了一些技术来处理此问题，例如数据库事务处理及分布式事务处理中间件。根据这些事务处理技术的任一种，程序员可以明确地声明某处理的所有步骤都是某项事务的一部分；如果出现错误，数据库或事务中间件提供的服务将撤销错误出现前已完成的所有工作。但在异步系统中，不可能采用这些事务处理技术来管理处理中的所有步骤，因为这些步骤被不确定的时间所分割。因此异步流程控制需要单独的处理机制才能撤销处理失败时已经完成的任何工作，即采取开发补偿逻辑来完成。

某大型银行深化系统技术方案之八：核心层之异步流程控制机制相关推荐

某大型银行深化系统技术方案之七：核心层之流程控制引擎
传送门☞Android兵器谱☞转载请注明☞http://blog.csdn.net/leverage_1229 核心层核心层主要提供后台业务集中处理中最基本.共性的信息处理.流程调度和相关的管理功能 ...
某大型银行深化系统技术方案之六：系统架构之运作流程
传送门☞Android兵器谱☞转载请注明☞http://blog.csdn.net/leverage_1229 系统的运作流程中,用户登陆.各服务组件之间都是在单点登录(SSO)认证体系下,用户只需登 ...
某大型银行深化系统技术方案之十七：技术架构
传送门☞Android兵器谱☞转载请注明☞http://blog.csdn.net/leverage_1229 在上述功能架构中,除了核心层外,应用层及服务层都包括了用户UI界面,因此服务中包括了Ma ...
某大型银行深化系统技术方案之十四：服务层之服务调度机制
传送门☞Android兵器谱☞转载请注明☞http://blog.csdn.net/leverage_1229 服务层服务层主要体现了SOA体系下的组件复用和业务复用机制.服务的边界定义决定于粒度和 ...
某大型银行深化系统技术方案之十三：服务层之服务接口模式
传送门☞Android兵器谱☞转载请注明☞http://blog.csdn.net/leverage_1229 服务层服务层主要体现了SOA体系下的组件复用和业务复用机制.服务的边界定义决定于粒度和 ...
某大型银行深化系统技术方案之十二：服务层之服务分类
传送门☞Android兵器谱☞转载请注明☞http://blog.csdn.net/leverage_1229 服务层服务层主要体现了SOA体系下的组件复用和业务复用机制.服务的边界定义决定于粒度和 ...
[置顶] 某大型银行深化系统技术方案之二十：代码结构
传送门 ☞ Android兵器谱 ☞ 转载请注明 ☞ http://blog.csdn.net/leverage_1229 架构代码部分主要的包结构是Backing.Entity.Dao.Servic ...
某大型银行深化系统技术方案之十六：业务应用层
传送门☞Android兵器谱☞转载请注明☞http://blog.csdn.net/leverage_1229 面向完整的业务应用处理.对于不同类型的业务应用,定制其特有的处理流程和不同基础服务的组合 ...
某大型银行深化系统技术方案之十五：服务层之服务调用
传送门☞Android兵器谱☞转载请注明☞http://blog.csdn.net/leverage_1229 服务层服务层主要体现了SOA体系下的组件复用和业务复用机制.服务的边界定义决定于粒度和 ...

某大型银行深化系统技术方案之八：核心层之异步流程控制机制

某大型银行深化系统技术方案之八：核心层之异步流程控制机制相关推荐

最新文章

热门文章