微服务、垂直面以及业务流程管理？

　　假如你考虑过现代体系结构，你可能会发现（目前）最好的解决方案就是微服务架构。微服务跟我们过去遵循的方法大相径庭，以往我们通常设计整体的企业应用。在整体应用环境中，单一的软件系统压缩了业务逻辑、数据库层次和用户界面组件。Java平台企业版架构提供了完美的框架来构建这种应用，在可扩展的事物型应用程序服务器环境中部署和执行。

　　然而整体企业应用有时难以维护，即使是细微的变更也需要在组件中进行更改。这也是这一想法等同于把整体应用块分成若干微服务架构的原因之一。

　　其中一个问题就是如何把架构从整体状态变成现代化的基于服务的体系结构。 Christians Posta的博客对上述意思作出了很好的概述。

　　垂直化服务

　　起先，把业务逻辑分成单个的服务似乎很简单。然而最后这种方法要产生紧密间隔的微服务集，它们事实上并非松散耦合。其中一个原因就是数据库层作为一个整体块在所有新的微服务架构背后继续存在。我们想着数据库对象之间相互联系，就这么发生了。这仅仅是我们真实商业世界中的一个非常真实的画面。但这却在我们所有的服务和团队之间创建了复杂的同步点，你得在数据库层中协调这些变化。通常，由一项服务导致的数据库变化也影响了其他服务。

　　解决这个问题的一种方案就是把功能分成紧密结合的“垂直化服务”，不受技术或者组织方面驱动。每个垂直面有自身的“业务逻辑”、“数据库”以及可选的“用户界面组件”。有了这个方法，当我们要对单个的数据库对象或者其中一个垂直面的某个功能进行变动时，就不需要重新部署全部的整体业务服务。理论上，单个的团队也能拥有并操作每个垂直面。

　　我们通常建议通过发送事件来控制各项服务之间的同步性。这个想法背后的方法就是“响应式编程”法。各项服务之间的通信以异步方式实现。所以一个服务层的业务逻辑不会依赖于另一个服务层的结果。服务可能会或者可能不会对特定事件产生影响。这就是松散耦合的理念。

　　但是，这适合你的业务要求吗？

　　“业务流程服务架构”

　　将业务逻辑分为单独的服务会有这样的问题，所有这些服务的背后仍存在着“整体业务逻辑”，这被称为“业务流程”。假如在上述的例子中，订单服务、发票服务和物流服务作为单独的构建模块来执行，那么在界定国家和商业规则的背景中还存在着“订购-管理”这样的总体业务流程。比如说，一位客户订购产品（订单-服务），在发票送达客户（发票-服务）之前，产品不会进行运送（物流-服务）。所以，发票-服务和物流-服务在发生由订单-服务引发的新事件后不同时做出反应，这是不够的，没有反映业务流程。

　　现在我们能做的就是定义单独的事件，明确显示订单-管理-流程中的每个阶段。例如，订单-服务能发出“订单-准备-发票-事件”，表示需要发送发票。而发票-服务能触发新的“订单-准备-运送-事件”，表明订单发票已发送给客户，可以运送产品。然而又引发了与以前通用数据库同样的问题，通过反映业务流程的特定事件类型来连接服务。当前，业务流程遍布各种服务。

　　为避免紧密耦合服务的影响，可以把业务流程本身作为一项服务进行分解。这就意味着把整体-服务-逻辑从服务中分离开来，提供了仅仅反映业务流程的单独的新服务层。

　　我把这个称为“业务-流程-服务-架构”，在这架构形式中，每个服务层都依赖于业务-流程-服务。事件仅在垂直面和业务-流程-服务层之间发送。订单-服务、发票-服务和物流-服务可能会或者可能不会对这些流程事件产生影响。该架构的优势在于我们具有一种服务，能控制订购管理流程并反映每个流程实例的状态。每个垂直面能调用业务-服务层来查询整体-业务-流程的状态，并将工作流信息用于进一步处理。我们还能改变独立于垂直服务层的业务流程。

　　业务流程建模标记法2.0和工作流引擎

　　描述业务流程最常用的技术之一就是“业务流程建模标记法”—BPMN2.0标准版。业务流程建模标记法最初用于描述业务流程，没有软件系统的所有技术细节。业务流程建模标记法的图表易于理解，是与技术员或管理人员谈论业务流程的好起点。除了对业务流程进行总体描述外，业务流程建模标记法还能由流程或工作流引擎来执行。工作流管理系统从头到尾控制每项任务。因此，工作流引擎能基于模型描述来控制业务流程的生命周期。工作流引擎能被整合到业务流程服务架构中的一个例子就是开放源项目Imixs工作流。

　　除了能对业务流程进行总体控制，我们的新服务还能从垂直面收集各种元信息。服务成为我们微服务架构中的核心信息点。我们现在可以改变业务流程模型，整合新垂直面，而不会影响现有的执行情况。这是你用这种架构形式能实现的最重要的效果之一。我将在以后的文章中我会举出例子，说明如何基于RESTful服务界面整合业务流程服务。

　　欢迎关注寄云科技订阅号（neuclouddy），这里有最新云服务行业资讯，更有与PaaS、运维相关的技术干货！