单独的微服务仅仅用于微服务编排？

Question

我有一些微服务，其中每个微服务都有用于CRUD操作的REST端点。可以对这些REST API进行一些同步和异步调用。

我已经寻找了一些工作流引擎，但我不认为我可以在不编写任何java代码的情况下创建工作流。

我应该只为微服务编排编写一个单独的微服务吗？此编排微服务将知道确切的工作流，并且可以针对启动工作流所需的输入进行配置，它还可以使用Camunda等第三方工作流引擎来存储工作流的定义。

将单独的微服务仅用于微服务编排，这是正确的想法吗？到目前为止，现有的微服务并不了解其他微服务。在用作其他微服务的输入之前，可能需要对来自一个微服务的输出进行消息处理。

Answer 1

我已经寻找了一些工作流引擎，但我不认为我可以在不编写java代码的情况下创建我的工作流。

这取决于您的业务流程和工作流程的复杂性。通常是的，你需要写一些代码来实现它。

我应该只为微服务编排编写一个单独的微服务吗？此编排微服务将知道确切的工作流，并且可以针对启动工作流所需的输入进行配置，它还可以使用Camunda等第三方工作流引擎来存储工作流的定义。

是的，你能做到。我在一个使用微服务的系统上做了类似的事情。从长远来看，这将是一个非常好的想法，因为您也可以基于环境来配置您的工作流。例如，在您的开发机器上，您可能会有一些不同的工作流/配置。这对于开发人员或QA测试他们的解决方案是实用的。另一方面，在试运行/生产阶段，您可以预定义客户设置/编排，如果获得新客户或用户，您可以随时重用这些设置/编排。

将单独的微服务仅用于微服务编排，这是正确的想法吗？到目前为止，现有的微服务并不了解其他微服务。在用作其他微服务的输入之前，可能需要对来自一个微服务的输出进行消息处理。

是的，你可以这样做，没有问题，尽管我会小心地使用名称编排，因为这在微服务架构(Docker，Docker-Swarm，Kubernetes)的上下文中有另一个含义。类似的例子可能是某种类型的EndToEndTest或交叉微服务测试微服务。这将测试跨微服务业务操作并断言结果。通常，业务操作涉及多个微服务，因此为了测试您是否可以使用此方法。此微服务将调用来自多个微服务的API，并根据您的业务规则测试结果和场景。另一个例子是类似于种子微服务的东西(看起来和你在这里要做的非常相似)。这个种子微服务将负责将测试数据播种(创建)到您的微服务。此测试数据是一些基本的设置/配置数据，您需要这些数据才能使微服务业务流程正常工作。这对于开发机器或一些需要快速设置环境的测试环境非常方便。使用这个种子微服务，您可以轻松地设置、执行工作或测试，并在需要时处置环境(数据)。这对于开发机器设置特别有用，但它也可以用于共享测试环境等。这两个示例都是微服务，可以满足您的需求，并使您的生活更容易与您的系统一起工作。

关于这一点，最后一点是：

到目前为止，现有的微服务对其他微服务一无所知。

它们应该以一种不知道内部实现或数据(独立的数据库)的方式相互抽象，但它们应该相互通信，以便执行有时是跨微服务的业务操作。例如来自在线商店示例的支付微服务和订单微服务的典型示例。因此，他们相互了解并进行交流是很好的，但这种交流必须非常仔细地设计，以避免一些常见的陷阱。它们通常通过直接调用，通过超文本传输协议或其他协议，或通过一些消息队列，如Apache Kafka或RabbitMq或其他。您可以在此answer中了解更多信息。

Answer 2

是的，您应该在单独的服务中涵盖编排部分。而且，是的，使用BPMN 2流程引擎作为协调器，正如您已经怀疑的那样。是的，这可能包括编写一些代码，主要用于数据映射或连接器。好处包括，例如，ootb支持：

用于data

• versioning (！)的
• 状态管理和长时间运行的进程/持久性
• 重试和错误handling
• tooling，以便在发生wrong
• timeouts，时修改状态和日期并行执行(如果在基于BPMN 2 model
• ability的监控工具中使用necessary)
• scalability
• graphical process model
• audit trail
• 和端到端可见性，以包括业务规则任务(DMN)，以实现更复杂的推拉通信模式的推送和拉入通信模式，以及通过BPMN 2
• 对各种BPMN 2 events
• standardization (技能、安全性、软件质量、特性)的支持实现同步communication
• business-IT对齐) ...

这是一篇很棒的相关文章，介绍了为什么使用机票预订作为示例：https://blog.bernd-ruecker.com/3-common-pitfalls-in-microservice-integration-and-how-to-avoid-them-3f27a442cd07

这是关于使用流程引擎时的重要设计考虑因素：https://blog.bernd-ruecker.com/the-microservice-workflow-automation-cheat-sheet-fc0a80dc25aa

Answer 3

我遇到了与原问题类似的问题。我使用了一些需要管理的具有简单依赖关系的微服务，并且确实采用了编写自己的微服务https://github.com/pedro-r-marques/workflow来管理依赖关系和进行编排的方法。它使用yaml定义文件来描述消息传递的依赖关系和rabbitmq。还可以用负载均衡器前端的REST API调用替换rabbitmq的用法。