您可以通过使用spring状态机模型来实现编排。

步骤

将以下依赖项添加到您的项目中(如果您使用Maven) <依赖> < groupId > org.springframework.statemachine < / groupId > < artifactId > spring-statemachine-core < / artifactId > <版本> 2.2.0.RELEASE > < /版本 < / >的依赖 定义状态和事件，例如状态1，状态2和事件1和事件2

在buildMachine()方法中提供状态机实现。 configureStates configureTransitions 将事件发送到状态机

请参阅文档页以获得完整的代码

那么，微服务的编排与非“微”的旧SOA服务的编排有什么不同呢?一点也不多。

微服务通常使用http (REST)或消息/事件进行通信。业务流程通常与业务流程平台相关联，这些平台允许您在服务之间创建脚本化的交互，以使工作流自动化。在旧的SOA时代，这些平台使用WS-BPEL。今天的工具不使用BPEL。现代编配产品的例子:Netflix Conductor, Camunda, Zeebe, Azure Logic Apps, Baker。

请记住，编排是一种复合模式，它提供多种功能来创建复杂的服务组合。微服务通常被视为不应该参与复杂组合的服务，而是更自治的服务。

我可以看到在编排工作流中调用微服务来做一些简单的处理，但我没有看到微服务是编排服务，它通常使用补偿事务和状态存储库(脱水)等机制。

所以你有两个服务:

发票微服务 货运微服务

在现实生活中，你会有一些保持有序状态的东西。我们称它为顺序服务。接下来是订单处理用例，它知道当订单从一种状态转换到另一种状态时该做什么。所有这些服务都包含一组特定的数据，现在您需要其他的东西来进行所有的协调。这可能是:

了解所有服务和实现用例的简单GUI(“我完成了”调用发货服务) 一个等待“I'm done”事件的业务流程引擎。这个引擎实现了用例和流程。 一个编配微服务，比如说订单处理服务本身，它知道你的领域的流程/用例 还有其他我没想过的吗

The main point with this is that the control is external. This is because all your application components are individual building blocks, loosely coupled. If your use cases change, you have to alter one component in one place, which is the orchestration component. If you add a different order flow, you can easily add another orchestrator that does not interfere with the first one. The micro service thinking is not only about scalability and doing fancy REST API's but also about a clear structure, reduced dependencies between components and reuse of common data and functionality that are shared throughout your business.

HTH,马克

如果需要管理状态，那么使用CQRS的事件源是理想的通信方式。除此之外，异步消息传递系统(AMQP)可以用于微服务之间的通信。

从你的问题可以看出，ES和CQRS应该是正确的组合。如果使用java，可以看看Axon框架。或者使用Kafka或RabbitMQ构建自定义解决方案。

关于这个话题，我写过几篇文章:

也许这些帖子也能有所帮助:

API网关模式——粗粒度API vs细粒度API

https://www.linkedin.com/pulse/api-gateway-pattern-ronen-hamias/ https://www.linkedin.com/pulse/successfulapi-ronen-hamias/

粗粒度服务API与细粒度服务API

By definition a coarse-grained service operation has broader scope than a fine-grained service, although the terms are relative. coarse-grained increased design complexity but can reduce the number of calls required to complete a task. at micro-services architecture coarse-grained may reside at the API Gateway layer and orchestrate several micro-services to complete specific business operation. coarse-grained APIs needs to be carefully designed as involving several micro-services that managing different domain of expertise has a risk to mix-concerns in single API and breaking the rules described above. coarse-grained APIs may suggest new level of granularity for business functions that where not exist otherwise. for example hire employee may involve two microservices calls to HR system to create employee ID and another call to LDAP system to create a user account. alternatively client may have performed two fine-grained API calls to achieve the same task. while coarse-grained represents business use-case create user account, fine-grained API represent the capabilities involved in such task. further more fine-grained API may involve different technologies and communication protocols while coarse-grained abstract them into unified flow. when designing a system consider both as again there is no golden approach that solve everything and there is trad-off for each. Coarse-grained are particularly suited as services to be consumed in other Business contexts, such as other applications, line of business or even by other organizations across the own Enterprise boundaries (typical B2B scenarios).

试着把不同的方法聚合在一起。

域的事件

主要的方法似乎是使用域事件，其中每个服务发布关于已发生事件的事件，其他服务可以订阅这些事件。 这似乎与Martin Fowler所描述的智能端点和哑管道的概念密切相关:http://martinfowler.com/articles/microservices.html#SmartEndpointsAndDumbPipes

代理

另一种常见的方法是将业务流包装在自己的服务中。 代理协调微服务之间的交互，如下图所示:

.

其他组合模式

该页包含各种组合模式。