第二次技术大战:云端BPM / Michael Poulin


 2014-12-04 02:15:01       753

作者简介:Michael Poulin,企业级解决方案架构师,他在美国及英国的金融行业工作。擅长在业务需求与技术能力之间搭建桥梁,注重业务与技术的效率、可扩展性、稳健性。他曾以独立会员的身份为OASIS SOA标准作出共享,曾在2001年被列入国际“信息技术名人录”。

 

摘要:现在我们正在攻打一场关于云的战斗。总体上这场战斗的战线与SOA时代很像

今年3月,ZapThink发表了一篇漂亮的文章,题为《云端BPM:突破性技术》。我强烈建议所有使用或计划使用云端BPM的人去读一读(似乎BPM本身没什么问题,而我们现在为了云的问题自找麻烦)。

为了让您一睹为快,这是文章的一段摘要:“有时,感觉ZapThink像是在荒野之中发出的理性而孤独的声音。尽管厂商散布大量错误信息,竭力将SOA说成是购买中间件的借口,我们很努力地将SOA宣传为一种业务驱动型架构的路径。然而,当很多组织已经开始成功实施SOA的时候,也许是正是我们自己害了自己,在很大程度上我们已经输掉了这场战斗。

而现在我们正在攻打一场关于云的战斗。总体上这场战斗的战线与SOA时代很像——ZapThink支持业务驱动型架构,而厂商殚精竭力地想把云曲解为购买更多引擎的借口。但是,正如两次世界大战的参战方基本相同一样,SOA与云也是如此。”

尽管ZapThink把竭力推广业务驱动型SOA的孤独感说的有些夸张,但这些话本质上是对的——无论过去还是现在,IT应用中的计算机科学不过是厂商雇佣能说会道的“科学家”为它们的产品说好话。因此,我宁愿与ZapThink辩论关于BPM、BPM与SOA结合以及云端BPM的观点,不想涉及那些厂商雇佣的科学家。

ZapThink将BPM与服务的第一个问题表述为“服务内在地就是无状态的”。ZapThink是怎么得出这个无状态服务的想法的?系统最佳化原则中有一条古老的原则,叫“无状态服务”——这是Thomas Erl宣扬的一个笨拙的文字游戏,他创设了这条原则,即服务必须自发管理状态;他没有说服务必须是无状态的,但在我看来,他只不过是想促进服务可扩展性的实行。在评论系统最佳化原则时,我将上述原则改为“服务状态管理”,我觉得这样表述更准确。

由此可见,如果一个服务以进程的方式实现,那么它可以自由管理其自身状态,可以是有状态的或是无状态的(如果你把服务看成是一个服务工厂,并且你可以按需要来初始化服务,那么你的限制就只会在硬件资源上,而不是服务状态)。在2008年就有关于在消息交互中携带进程状态信息的想法,但对那些通过服务接口来发送以兆计算消息字节的人来说,保持服务的无状态性给他们带来很痛苦的失败教训。

ZapThink认为:BPM与服务的第一个问题表述为“服务内在地就是无状态的”

而Michael Poulin认为:如果一个服务以进程的方式实现,那么它可以自由管理其自身状态,可以是有状态的或是无状态的

在文章的下一部分,ZapThink叙述了一些未经证明的观点,而且基于这些观点得出了战略性的结论。特别是这一段:“为了达到云为分布式应用带来的可伸缩性优势,应用层必须是无状态的……这样一来,就没有办法让传统的BPM引擎在云上正常运行。毕竟,BPM引擎存在的价值在于维护进程状态,但你不牺牲伸缩性在云实例上就做不到!换句话说,大厂商们所投入的用以构建以SOA平台为中心的BPM引擎上的全部人力物力现在都白费了。云已经改变了BPM的规则。”

我没有看到云可伸缩性与在云中运行应用的无状态性之间有任何关联。在本质上,云的可伸缩性是指按照需求为整个应用或其中某一部分扩大或减少计算资源的能力。如果一个服务/进程状态正在运行,它可以按需扩大(取决于服务进程/编排每一步的业务规则)但不应减少计算资源,因为它需要或可能需要这些资源。需求应当由应用决定,而不是由云计算规则(我们使用云的目的不是为了限制我们的做法)。也就是说,有状态行为与云之间并没有架构上或与逻辑上的矛盾。此外,有状态性的应用/服务可能会因为云的可伸缩性而希望在云端实施,比如,它可以消耗很多资源来维持所需状态,而这些资源在云上应该是很便宜的。

ZapThink认为:没有办法让传统的BPM引擎在云上正常运行,毕竟,BPM引擎存在的价值在于维护进程状态,但你不牺牲伸缩性在云实例上就做不到。

而Michael Poulin认为,云可伸缩性与在云中运行应用的无状态性之间没有任何关联,在本质上,云的可伸缩性是指按照需求为整个应用或其中某一部分扩大或减少计算资源的能力。

_ueditor_page_break_tag_

另一段陈述是宣言性的:“云可能需要产生额外的实例来处理加载,并且任何特殊实例都可能崩溃。但由于云是高度可用且分区容忍的,这样的崩溃一定不能影响运行由云实例支持的进程。”是的,我们可以假设云可以依需要(或依要求)产生尽可能多的服务/进程实例,但在某一特殊实例出现故障时提供故障转移是因为服务/进程设计的缘故,而不是云本身的特征。多亏了云的高可用性,故障转移过程变得难以察觉,但是这一点怎么会与可伸缩性矛盾?而且怎么就可以得出以下结论:“如此一来,就没有办法让传统的BPM引擎在云上正常运行。毕竟,BPM引擎存在的价值在于维护进程状态,但你不牺牲伸缩性在云实例上就做不到!换句话说,大厂商们所投入的用以构建以SOA平台为中心的BPM引擎上的全部人力物力现在都白费了。云已经改变了BPM的规则”?我已经解释过,服务的无状态性与云的可伸缩性没有关联,我同意ZapThink所说的“用以构建以SOA平台为中心的BPM引擎上的全部人力物力现在都白费”,但我的理由不一样。

大多数自动化BPM解决方案运行在ESB平台上。这一平台支持公司的核心业务交易,同时也在市场中竞争。战士们赤身裸体战斗的历史案例我只能想起一个——臭名昭著的亚马逊事件:将你的“业务血管系统”暴露在已知或未知的威胁之下并非最好的竞争形式。实际上,问题不是如何让BPM系统在云中运行,而是它为什么要在云中运行,它可以为BPM带来什么益处(难道云和BPM是锤子和钉子的关系吗)?有时候我觉得“向云端迈进”运动与以前流行的海外外包潮流很相似——即使根本没有什么商业价值,人们还是随大流这样做,最后以重大损失告终(很奇怪的是无人因此受到责罚)。在此种情况下,我经常引用著名的彼得•德鲁克的一句话:“没有什么比有效地做那些根本不需要做的事更无用的了。”

因为执着于状态性,ZapThink试图为现在云中的BPM引擎找到一个合适的解决方案,但最终总是回到相同的携带状态的信息。这里所说的“信息”是指“进程行为体所使用的在服务器端和客户端之间交互的资源,是我们在REST语境下所说的‘表征’(representations)”。也就是说,有必要将应用状态转化为表征再传递给客户端。这就是为什么REST是“表征状态转移”。对于那些不熟悉REST是“表征状态转移”的人,我解释一下这个概念,因为这对于理解ZapThink所说的那些思想很重要。

想象一个在服务型生态系统中的过程(自动服务过程),有过程消费者/客户端,一个进程/编排执行实体或者导体,一套编排规则以及一套为导体提供中间媒介结果的其它服务。哪些资源在哪些服务器上(在云上)?ZapThink所指的“过程行为体使用的”客户端是什么?对于我来说,这听起来像一堆华丽的词藻堆砌在一起。是的,导体所使用的其它服务是它的资源,就像导体也是过程消费者/客户端的资源一样,但这根本听起来不像ZapThink描述的那样。如果HTTP是REST传输协议中的一种,你见过REST传输100KB或1M状态信息吗?OK,如果REST是一个表征状态,而不是状态本身,那为什么它不可以使用像HTTP这样通行的协议来表述状态?还是HTTP不适合REST?)ZapThink说:“你认为REST是专为HTTP而存在的吗?不,不是这样的。它与抽象的超文本协议有关,HTTP只是大家最熟悉的一种。REST提倡包含GET、POST、PUT、DELETE的统一界面吗?也不是的。”

ZapThink认为:用以构建以SOA平台为中心的BPM引擎上的全部人力物力现在都白费。

Michael Poulin同意该观点,但理由并非服务的无状态性与云的可伸缩性之间的矛盾,而是需要重新考虑BPM在云中运行的必要性。

顺便说一句,ZapThink发现“是开发者群体错将REST说成是建立统一的API资源的方式。但那不是REST。REST是指建立超媒体应用。实际上,REST根本不是资源导向型架构。你可以说它是超媒体导向架构。”那么,根据维基百科,“超媒体是指一种基于计算机的信息检索系统,它可以使用户获得或为用户提供获取有关某一特定主题的文本、音频、视频、图像、计算机绘图的路径。”当我们谈论自动化BPM时,为什么我们要关心BPM引擎是不是超媒体应用呢?为什么一个熟悉的ESB不能通过移动线路接受信息或将视频/音频技术传出呢?据我所知,这个领域并无技术限制。

ZapThink所指的技术是“超媒体可作为应用状态引擎”。有了HATEOAS(超媒体即应用状态引擎),超链接可在运行时以工作流的形式动态描述客户端与服务器端之间的协议”。好吧,假设我们不做过程处理,而只用链接。比如,我们使用HTTP的GET和PUT方法启动一个进程,这符合“无需进程引擎”的说法:当进程被触发,一个链接指向规则引擎,并期望返回一个下一步该做什么的说明。那这个说明返回何处呢?规则的请求者是“无状态的”进程,执行响应客户端请求;那么,该说明可能只会返回客户端(记住,进程可能并不维护其状态),并且在这种情况下,返回的说明字节数要足够短,以满足GET/PUT方法的要求。接下来,客户端再调用同一个进程(可能不同实例),并把说明传递回(到云中?)“进程”继续执行,以此类推。如果你能够这样就把它推销出去并做成生意,拜托,告诉我一下,让我们来庆祝这桩生意是多么的愚蠢。

不要忘记“魔鬼藏在细节里”。在绝大多数情况下,“无状态进程”的客户端是云中的另一个服务/客户端。换言之,根据ZapThink,一个运行的服务/进程可能没有状态而消费的服务/进程可能有状态……这就是执着于状态性带给我们的后果。

在最后,ZapThink列出了“构建一个分区容忍的、应用REST的BPM应用的几个关键点”:

1)“将建立进程应用的资源与资源的表述分开。”我们对云中的进程应用感兴趣,而不是对哪些资源建立了进程应用感兴趣,是不是?“……持久层并不能植入进程引擎,它只有模型驱动的资源,可以产生在可伸缩应用层运行的无状态进程应用”——也许ZapThink应该回想一下,“进程”这个术语是指一个步骤相互连接的逻辑链。如果一个进程的客户必须频繁地通过状态来到达“进程”,它就变成了进程的一部分,这和进程的定义存在根本性矛盾,是完全不可接受的。

2)“应用层充当过程表述的客户,也充当支持过程客户的服务器。”等一下,到此为止我们只知道过程应用和资源表述——哪里冒出来一个“过程表征”?为什么过程应用要支持过程客户端?客户端应该是独立的、可自给自足的实体。

3)“将UI表述与应用状态表述分开。”我希望这是一个印刷错误,否则我很乐意看到云中有UI。我觉得这里的UI指的是客户界面。

4)“用一个轻量级的、分布式排列机制来处理客户端正常运行问题。”——那么,如果客户端不是轻量级的,就不能用云/基于REST的BPM了?……是这样吗?

5)“对于要求在多个行为体间进行大量交互的进程来说,应采用点对点模式。”——这里,我们回到了未来:点对点模式,而不是间接主观的对轻量级/重量级交互的判断。

在最后一部分,ZapThink以基于Web服务的SOA反对基于REST的SOA。如果REST是表征状态转移,没有机制可将要素/资源组成架构,即REST是一个背后有丰富原理的具体技术,那什么是基于REST的SOA?面向服务的架构是一种无需支持的、独立于传输机制与内容的技术,至少,在我2007年被ZapThink认证为SOA架构师时,ZapThink是这样教我的。可能你已经注意到了,过去几年网上关于REST与SOA的辩论基本上消失了。在任何情况下,运行一个自动化的无状态业务进程要求通过消息传送大量数据——这是状态本身以及所有进程步骤的结果;REST(无论它是什么)似乎不是大量数据传输的合适媒介,但Web服务是,尽管后者不是唯一的在云上或云之外的用于自动化BPM的传输界面。

在作出所有评述之后,我想我应该说——把基于REST的BPM放一边吧,除非它能让人们很清楚地了解它的进程如何在“乌云”中运行。

相关阅读: