编排微服务的标准模式是什么?
如果一个微服务只知道它自己的域，但是有一个数据流要求多个服务以某种方式交互，那么该怎么做呢?
假设我们有这样的东西:
发票 装运
为了便于讨论，让我们假设订单发出后，应该创建发票。
在某个地方，有人按下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 将事件发送到状态机
请参阅文档页以获得完整的代码
关于这个话题，我写过几篇文章:
也许这些帖子也能有所帮助:
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).
如果需要管理状态，那么使用CQRS的事件源是理想的通信方式。除此之外，异步消息传递系统(AMQP)可以用于微服务之间的通信。
从你的问题可以看出，ES和CQRS应该是正确的组合。如果使用java，可以看看Axon框架。或者使用Kafka或RabbitMQ构建自定义解决方案。
原来问题的答案是SAGA模式。
那么，微服务的编排与非“微”的旧SOA服务的编排有什么不同呢?一点也不多。
微服务通常使用http (REST)或消息/事件进行通信。业务流程通常与业务流程平台相关联，这些平台允许您在服务之间创建脚本化的交互，以使工作流自动化。在旧的SOA时代，这些平台使用WS-BPEL。今天的工具不使用BPEL。现代编配产品的例子:Netflix Conductor, Camunda, Zeebe, Azure Logic Apps, Baker。
请记住，编排是一种复合模式，它提供多种功能来创建复杂的服务组合。微服务通常被视为不应该参与复杂组合的服务，而是更自治的服务。
我可以看到在编排工作流中调用微服务来做一些简单的处理，但我没有看到微服务是编排服务，它通常使用补偿事务和状态存储库(脱水)等机制。
