使用BPMN和微服务进行编排 ——是好做法还是坏做法？

　　马丁（Martin Fowler）在他著名的微服务文章中建议：“敏捷的终端和愚笨的管道”。他指出：

　　微服务社区赞成另一种方法：敏捷的终端和愚笨的管道。从微服务构建的应用程序旨在尽可能地解耦和衔接——他们拥有自己的域逻辑，而更多地在经典的Unix意义上扮演过滤器的角色——接收一个请求、适当地应用逻辑并产生响应。这些都是精心设计的，使用了简单的RESTish协议而不是诸如WS-Choreography或BPEL或由中央工具编配的复杂协议。

　　我并不赞同！我认为即使——或者可以说尤其是！—— 有了微服务，你有了编排的需要。在本文我想解释下其中的原因。我完全同意不使用WS-Choreography或BPEL ——在2015年,你毫无疑问应当使用BPMN。

　　微服务是什么？

　　微服务的理念是构建自给自足的服务，集中于一个业务功能之中，包括该软件的所有方面(操作系统和编程语言、持久性、容器，业务逻辑,用户界面，……)。这些都是由一个跨职能团队进行开发和管理，他们彼此独立部署——整个系统不是由一个整体部署构成，而是由一群微服务组成，他们之间互相通信。

　　微服务架构中的业务流程

　　让我们来假设一个典型订单流程中的三个简单的步骤：

• 储备货物

• 付款流程

• 准备装运

　　我希望我们至少有三个服务：

• 库存服务

• 支付服务

• 运输服务

　　问题是订单流程是如何实现的。如果你遵循“敏捷的终端和愚笨的管道”，我主要看三种可能性：

• 服务了解这个流程，并且做相应的路由。这意味着初始订单首先被库存服务接受以便储备货物。然后，该服务调用支付服务以便进行付款。由于管道是愚蠢的——服务必须知道下一个服务是哪一个。

• 服务听从中央事件总线，接受它们感兴趣的消息。TThan最初的消息是一个“订单”事件,这是库存服务所感兴趣的消息。经过处理之后，生产了一个“货物保留”事件，由“支付服务”所接听，以此类推。

• 一个自己的“订单服务”介绍了谁负责整个流程。

　　选项1和2都意味着一些问题有待解决：

• 流程流的知识遍布于各种服务之间。

• 流程流的变化将影响不同的服务。

• 一个订单/流程实例的当前状态很难找到——因为各种服务必须收到请求。

　　对于这些问题有一些解决办法，比如你可以建立一个中央数据存储，知道所有的事件，就可以回答关于状态的问题。但我的感觉仍然是这smeels太多！举一个简单的例子：我们需要实现取消订单，这只能是在货物没有准备好的情况下才成为可能。如果已经完成了，那么你需要补偿支付和释放预订。为了做到这一点，你需要知道你的流程实例的状态！同时你需要改变每一个服务来实现这个要求！

　　因此，让我们来看一看选项# 3：

　　编排为王！

　　如果我们构建一个自己的“订单服务”来实现我们所做的订单流程编排！而我想这样做——因为这里是整个流程实现的地方。有了微服务，我们可以为一个服务自由选择技术——那么显然，我们想选择一个BPMN流程引擎来进行编排（我不想在这个博客中再重复为什么要这样做，希望每个人都得到了这个消息：你不应该硬编码流程，你不应该编写自己的引擎。重复一遍：不要硬编码流程或编写自己的引擎！）。

　　然后，我们就可以模拟这个流程：

　　这个BPMN模型很容易理解，在诸如来自camunda的开源BPM平台（这非常轻便,并且可以通过如docker进行运行)等引擎上是可执行的。它有助于保持流程流向底层服务。流程引擎跟踪所有的流程实例、它们的状态、甚至审计信息/数据。添加取消相当简单，而补偿机制开箱即用。使用的微服务仍然是微型的，并且根据通信的类型，可能没有时间耦合等——因为我们可以使用转储管道来进行引擎和服务之间的通信。或者我们可以把任务从引擎中拉出来而不是把它推进去，因为它在类似云或olyglott环境中非常有趣(这在微服务架构中可能确实如此)。

　　命名“BPM”比“编排”更好？

　　我可以想象马丁建议编排在一个微服务世界中的主要原因之一，是编排仍然听起来像“老”SOA范式。范式中有分层服务，通过ESB-like组件彼此调用。但是BPM是关于透明度和业务——信息技术——相契合的。现代BPM平台如果带着过去十年的沉重而复杂的BPM套件则无事可为——所以你绝对有理由，应该在你的微服架构中使用BPM /流程引擎。

​

　　本文由寄云科技编译，未经授权谢绝转载。欢迎关注寄云科技订阅号（neuclouddy），这里有最新云服务行业资讯，更有与PaaS、运维相关的技术干货！欢迎加入PaaS行业交流QQ群（421312857），关于PaaS的一切您都可以在这里与其他小伙伴共同探讨学习，小伙伴们等你哦~