Camunda微服务编排思路

本文重点讲解下怎么使用Camunda框架进行微服务的编排。Camunda工作流引擎支持轻量级微服务编排，包括业务流程的end-to-end（ 端点到端点）监控。

 

如何处理微服务混乱编排？

      近年来，微服务架构越来越受欢迎，并且有充分的理由去使用微服务的一些优秀架构思想：团队可以在使用他们选择的技术栈时快速独立地提供一些很好的价值，而不会受制于单服务所带来的一组共同技术约束问题。

      端点到端点（End-to-end ）业务流程通常会涉及到众多的微服务，并且我们必须组织它们之间的的交互逻辑。通常我们会有一个类似的调用流程，比如a服务调用B,B服务调用C,C服务去调用其他的微服务。这种方式可能是硬编码，最终导致各种服务蜘蛛网似的交互，盘根错节，一发而动全身。 解决这个服务调用问题的最优解决方案就是编排模型（choreography model），其中微服务之间直接相互调用（请求/响应模式 Request / Reponse）或仅通过在中央消息或事件总线（发布/订阅模式Publish / Subscribe）上发布的事件间接地通信。这样就可以最大程度上的解耦，附带的好处就是微服务之间的调用更加的透明化，更加的编排化，更加的扩展化，替代了直接在各个微服务中硬编码方式进行服务的预定义调用逻辑。

     特别是发布/订阅模式非常适合于各个微服务的独立性概念 - 微服务不需要彼此了解，因此可以自主地开发，操作和缩放。

    然而，随着业务流程中涉及的微服务数量的增加，可能会出现严重的问题。

1.      在一组微服务中，流程的整体流程将变得难以监控和故障排除。 这里特别麻烦的是，当首次使用微服务架构时，这个问题可能不明显，但随着微服务数量的增加，它随着时间的推移逐渐变得更糟。 在最糟糕的情况下，由于无法预料的死锁和其他问题，端到端（End-to-end ）业务流程的成功不再得到保证。
2. 默认情况下，编排方法不提供处理错误或超时的解决方案，而是将这些问题传递给客户端，让开发人员预料到一些问题，然后去进行处理。 这使得我们难以防止整体流程中的故障，并且在最坏的情况下可能导致负面的客户体验 - 例如，当网站在没有提供相应的情况下显示错误消息。

使用Camunda框架，开发人员可以避免上述的两个问题，并且不会影响微服务的松散耦合。

松散耦合和受控制的流程

    Camunda支持端到端（End-to-end ）流程的跨服务监控和管理，而不会违反微服务背后的核心范例

    使用ISO标准BPMN，可以根据技术上易于理解的方式根据其逻辑顺序显示流程，并且还可以对来自运行流程的事件进行建模。这个也是camunda框架的魅力所在，支持链式方式创建一个流程定义并部署，及时没有专业BPMN开发背景的同学也可以轻松上手，比如现在小白同学要创建一个微服务编排的流程只需要下面几部操作：

Bpmn.createExecutableProcess(PROCESS_KEY)

.camundaHistoryTimeToLive(5)

.startEvent()

.userTask()

.endEvent().done();

     作为第一步，微服务发布的事件可以在Camunda中记录（例如，通过订阅事件总线），从而可以跟踪整个流程。 BPMN模型可用于检查事件是否按预期顺序和定义的SLA限制（例如，电子商务订单的发货周转时间）进行。

    作为下一步，Camunda本身可以发布使用事件命令模式的事件，以表示业务流程中的某个活动应该发生。 这可以通过订阅相关上游事件的自主Camunda驱动的微服务来完成，结果命令也可以作为事件发布 - 这意味着Camunda协调业务流程而不违反松耦合原则。

    Camunda不一定扮演“控制”层的角色，本身就是另一种具有明确定义范围的服务：具体而言，是端到端流程的监控（也可能是管理）。

   其中Camunda部分地通过发布/订阅模式与（其他）微服务交互，并且在一些情况下通过请求/响应直接编排附加服务。 例如，在将整体件逐渐迁移到微服务架构的背景下，这可能是有用的。 必要时，如果某些遗留应用程序不提供API，Camunda可以与其他技术（如机器人过程自动化（RPA））结合使用。

目前camunda为了迎合微服务的编排，很特性的推出了一个外部任务，这个是flowable activiti jbpm三个框架没有的。flowable6.4.1版本推出了一个可触发节点的概念，类似camunda框架的外部任务概念，但还是不完善。camunda外部任务只是发布事件，第三个应用可以订阅该事件，并进行抓起、锁定处理以及完成操作。