单独的微服务只是为了微服务编排？

Question

我有一些微服务，其中每个微服务都有用于 CRUD 操作的 REST 端点。 我必须创建一个工作流，该工作流将从一个具有一些初始输入的微服务开始，但稍后来自微服务的输出可以用作其他微服务的输入。可以对这些 REST API 进行一些同步和异步调用。

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

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

为微服务编排单独的微服务是正确的想法吗？到目前为止，现有的微服务对其他微服务一无所知。在将一个微服务的输出用作其他微服务的输入之前，可能需要对它的输出进行处理。

Answer 1

我已经寻找了一些工作流引擎，但我不认为 我无需编写任何 Java 代码即可创建工作流。

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

我是否应该为微服务编写单独的微服务 编排？这个编排微服务将知道确切的 工作流程，并且可以配置为启动所需的输入 工作流，它也可以使用一些第三方工作流引擎，如 Camunda 来存储工作流的定义。

是的，您可以这样做。我在使用微服务的系统上做了类似的事情。从长远来看，这将是一个非常好的主意，因为您也可以根据环境配置工作流程。例如，在您的开发机器上，您的工作流程/配置会有所不同。这对于开发人员或 QA 测试他们的解决方案是实用的。另一方面，在暂存/生产方面，您可以预先定义客户设置/编排，如果您有新客户或用户，您可以随时重复使用。

拥有一个单独的微服务只是为了 微服务编排？到目前为止，现有的微服务已经 不知道其他微服务。可能有机会 在使用之前需要对一个微服务的输出进行按摩 其他微服务的输入。

是的，你可以毫无问题地做到这一点，尽管我会小心编排这个名称，因为这在微服务架构（Docker、Docker-Swarm、Kubernetes）的上下文中具有另一种含义。类似的例子是某种 EndToEndTest 或 Cross micro-service testing-micro-service。这将测试跨微服务业务操作并断言结果。通常业务运营涉及超过 1 个微服务，因此为了测试您可以使用这种方法。该微服务将从多个微服务调用 API，并根据您的业务规则测试结果和场景。另一个例子是种子微服务（这似乎与您在这里尝试做的非常相似）。这个播种机微服务将负责为您的微服务播种（创建）测试数据。该测试数据是一些基本的设置/配置数据，您需要这些数据才能让您的微服务业务流程正常工作。这对于需要快速设置环境的开发机器或某些测试环境非常方便。使用这个播种机微服务，您可以轻松设置工作或测试，并根据需要处理环境（数据）。这对于开发机器设置特别有用，但它也可以用于共享测试环境等。这两个示例都是微服务，可以满足您的需求并让您的系统更轻松地工作。

关于此的最后一点：

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

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

Answer 2

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

• 状态管理和长时间运行的进程/数据持久性
• 版本控制 (!)
• 重试和错误处理
• 在出现问题时修改状态和日期的工具
• 超时，并行执行（如有必要）
• 可扩展性
• 图形化流程模型
• 审计跟踪
• 以及基于 BPMN 2 模型的监控工具中的端到端可见性
• 能够为更复杂的规则包含业务规则任务 (DMN)
• 推拉通信模式和异步通信的结合
• 通过 BPMN 2 实现业务-IT 对齐
• 支持各种 BPMN 2 事件
• 标准化（技能、安全性、软件质量、功能） ...

这是一篇很好的相关文章，以机票预订为例，介绍了 WHY： 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。