我正在设计开发一个基于http://microservices.io/规范的微服务平台
整个框架通过套接字集成，从而消除了多个 HTTP 请求的开销(如大多数 REST API)。
一个服务注册中心主机接收多个微服务主机的注册中心，每个微服务负责业务的一个域。我们称为路由器(或 API 网关)的另一个主机负责公开微服务以供第三方使用。
我们将使用Sagas的结构(编排风格)来分发请求，所以我们有一些疑问:
- 微服务应该在任何流程管理器中发出事件，还是应该将其直接传递到负责事件链的下一个微服务？ (回滚也是同样的逻辑)
- 谁应该知道如何构建 Saga 事件链？第一个接收某项工作的微服务还是路由器？
- 如果一个事件需要将大量数据传递给下一个 Saga 事件，那么在请求结构方面如何完成？例如，它是否分为多个 Sagas(作为结果分页类型)？
我认为重点是，在这个路由器和微服务结构中，谁负责构建 Sagas 并传播它们的事件。
最佳答案
文章Patterns for Microservices — Sync vs. Async很好地定义了这里使用的许多术语，并且有动画 gif 展示了同步与异步、编排与编排以及混合设置。
我知道OP answered his own question for his use case ，但我想尝试更普遍地解决提出的问题，以代替链接的文章。
Should a microservice issue the event in any process manager or should it be passed directly to the next microservice responsible for the chain of events?
用一个更通用的术语来说，流程管理器是一个协调器。其具体实现可能涉及一个有状态的参与者，它编排工作流程，以某种方式跟踪进度。由于 saga 本身就是工作流(由转发操作和补偿操作组成)，因此流程管理器的工作就是跟踪 saga 的状态直到完成(成功或失败)。这通常涉及参与者向服务发送同步*调用，等待某些结果，然后再进入下一步。当然可以引入并行操作，但关键是这个 Actor 决定了传奇的进展。
这与编排模型有着根本的不同。在这个模型中，没有中央参与者来跟踪传奇的状态，而是传奇通过每个步骤发出的事件隐式地进展。可以说，这是一个更纯粹事件驱动模型的情况，因为没有协调。
也就是说，该模型的挑战是观察任何给定时间点的状态。通过上面的编排模型，理论上，可以向每个参与者查询传奇的状态。在这个精心设计的模型中，我们没有这种奢侈，因此在实践中，关联 ID 被添加到与(在本例中)传奇对应的每条消息中。如果消息可以某种方式查询(事件总线支持它或通过某些其他存储方式)，则可以查询与 saga 相对应的消息，并且可以重建 saga 状态..(有效地对事件源进行建模)。
Who should know how to build the Saga chain of events? The first microservice that receives a certain work or the router?
这本身就是一个有趣的问题，也是我一直在思考的一个问题。最简单和默认的答案是..对传奇计划进行硬编码，并将它们映射到传入的消息类型。例如。消息A触发计划X，消息B触发计划Y，等等。
但是，我一直在思考控制平面可能是什么样子来管理这些计划并提供动态地将更改推送到消息处理程序和/或编排器的机制。考虑到的两个具体用例是授权策略的更改或向计划动态添加新步骤。
If an event needs to pass a very large volume of data to the next Saga event, how is this done in terms of the request structure? Is it divided into multiple Sagas for example (as a result pagination type)?
我解决这个问题的方法是包含对大数据的引用(如果这些是文件或其他东西之类的对象)。对于本身就是流的数据，可以引用并行 channel ，消费者在收到消息后可以从中读取数据。我认为这里的重要区别是将驱动工作流的消息的思考与数据物理具体化的地方分开，这取决于数据表示。
关于events - Saga Choreography实现问题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/48487098/