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

Question

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

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

Answer 1

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

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

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

仅仅为了微服务编排而拥有一个单独的微服务，这种想法是正确的吗？到目前为止，现有的微服务还不了解其他的微服务。在将一个微服务的输出用作其他微服务的输入之前，可能需要对其进行修改。

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

关于这一点的最后一点说明：

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