编排微服务的标准模式是什么?
如果一个微服务只知道它自己的域，但是有一个数据流要求多个服务以某种方式交互，那么该怎么做呢?
假设我们有这样的东西:
发票 装运
为了便于讨论，让我们假设订单发出后，应该创建发票。
在某个地方，有人按下GUI中的一个按钮，“我完成了，让我们开始吧!” 在经典的整体服务体系结构中，我认为要么有ESB处理这个问题，要么发货服务了解发票服务并直接调用它。
但是，在这个勇敢的微服务新世界中，人们是如何处理这些问题的呢?
我知道这可能被认为是高度基于观点的。但它也有具体的一面，因为微服务不应该做上述事情。 因此，必须有一个“根据定义，它应该做什么”，而不是基于意见。
开枪。
当前回答
如果需要管理状态，那么使用CQRS的事件源是理想的通信方式。除此之外，异步消息传递系统(AMQP)可以用于微服务之间的通信。
从你的问题可以看出，ES和CQRS应该是正确的组合。如果使用java，可以看看Axon框架。或者使用Kafka或RabbitMQ构建自定义解决方案。
其他回答
您可以通过使用spring状态机模型来实现编排。
步骤
将以下依赖项添加到您的项目中(如果您使用Maven) <依赖> < groupId > org.springframework.statemachine < / groupId > < artifactId > spring-statemachine-core < / artifactId > <版本> 2.2.0.RELEASE > < /版本 < / >的依赖 定义状态和事件，例如状态1，状态2和事件1和事件2
在buildMachine()方法中提供状态机实现。 configureStates configureTransitions 将事件发送到状态机
请参阅文档页以获得完整的代码
如果需要管理状态，那么使用CQRS的事件源是理想的通信方式。除此之外，异步消息传递系统(AMQP)可以用于微服务之间的通信。
从你的问题可以看出，ES和CQRS应该是正确的组合。如果使用java，可以看看Axon框架。或者使用Kafka或RabbitMQ构建自定义解决方案。
所以你有两个服务:
发票微服务 货运微服务
在现实生活中，你会有一些保持有序状态的东西。我们称它为顺序服务。接下来是订单处理用例，它知道当订单从一种状态转换到另一种状态时该做什么。所有这些服务都包含一组特定的数据，现在您需要其他的东西来进行所有的协调。这可能是:
了解所有服务和实现用例的简单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,马克
那么，微服务的编排与非“微”的旧SOA服务的编排有什么不同呢?一点也不多。
微服务通常使用http (REST)或消息/事件进行通信。业务流程通常与业务流程平台相关联，这些平台允许您在服务之间创建脚本化的交互，以使工作流自动化。在旧的SOA时代，这些平台使用WS-BPEL。今天的工具不使用BPEL。现代编配产品的例子:Netflix Conductor, Camunda, Zeebe, Azure Logic Apps, Baker。
请记住，编排是一种复合模式，它提供多种功能来创建复杂的服务组合。微服务通常被视为不应该参与复杂组合的服务，而是更自治的服务。
我可以看到在编排工作流中调用微服务来做一些简单的处理，但我没有看到微服务是编排服务，它通常使用补偿事务和状态存储库(脱水)等机制。
试着把不同的方法聚合在一起。
域的事件
主要的方法似乎是使用域事件，其中每个服务发布关于已发生事件的事件，其他服务可以订阅这些事件。 这似乎与Martin Fowler所描述的智能端点和哑管道的概念密切相关:http://martinfowler.com/articles/microservices.html#SmartEndpointsAndDumbPipes
代理
另一种常见的方法是将业务流包装在自己的服务中。 代理协调微服务之间的交互，如下图所示:
.
其他组合模式
该页包含各种组合模式。
