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

Posted 2023-03-08

【中文标题】单独的微服务只是为了微服务编排？

【英文标题】：Separate microservice just for microservices orchestration?

【发布时间】：2021-02-16 22:25:18

【问题描述】：

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

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

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

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

【问题讨论】：

你说的“但是后来一个微服务的输出可以用作其他微服务的输入”是什么意思。您能否更具体地说明如何将一个微服务的输出用作另一个微服务的输入？这对您的场景来说究竟有多大问题？

假设一个 REST 端点为 GET 方法返回一些 JSON，并且输出用于 POST 消息到其他微服务。我的基本问题是“我是否应该创建一个单独的微服务来完成所有的编排工作，因为我没有看到工作流引擎可以解决微服务之间的所有交互问题？”

【参考方案1】：

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

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

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

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

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

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

关于此的最后一点：

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

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

【参考方案3】：

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

【讨论】：

目前有许多服务/流程编排解决方案（请参阅blog.bernd-ruecker.com/… 了解相关信息），其中一些是开源的。一些支持图形流程建模，一些在 BPMN2 标准中。许多公司早在 10 多年前就开始使用本土解决方案，现在正在用基于标准的解决方案取而代之。标准化导致标准技能要求、更低的学习曲线以及更高的代码质量和安全性。为什么要重新发明***？

您的解决方案如何处理更复杂的类型，包括循环、并行执行、错误处理、计时器或条件事件……？审计和报告要求的持久性如何？

并非所有场景都具有相同级别的复杂性。在我遇到的场景中，我需要简单的至少一次语义，它比 BPMN2 提供的要简单一个数量级。对于简单的语义，能够使用简单的 yaml 文件配置工作流并使用任何可以与消息总线对话的语言是相对于复杂解决方案的显着优势。