我正在设计和开发基于http://microservices.io/
规范的微服务平台整个框架通过套接字集成，从而消除了多个HTTP请求的开销（如大多数REST API）。
服务注册表主机接收多个微服务主机的注册表，每个微服务器负责业务的域。我们称之为路由器（或API网关）的另一台主机负责公开微服务以供第三方使用。
我们将使用Sagas的结构（编排风格）来分发请购单，因此我们有一些疑问：
我认为主要的一点是，在这个路由器和微服务结构中，谁负责构建Sagas并传播他们的事件。
答案 0 :(得分：0)
文章Patterns for Microservices — Sync vs. Async很好地定义了这里使用的许多术语，并且GIF动画演示了同步与异步和编排与编排以及混合设置。
我知道OP answered his own question for his use case，但我想尝试解决一般性问题而不是链接文章。
微服务是否应该在任何流程管理器中发布事件，还是应该直接传递给负责事件链的下一个微服务？
要使用更通用的术语，流程管理器是 orchestrator 。这种情况的具体实现可能涉及一个有状态的角色，它协调工作流程，以某种方式跟踪进度。由于saga是工作流本身（由前向和补偿操作组成），因此流程管理器的工作是跟踪状态直到完成（成功或失败）。这通常涉及演员在进入下一步之前向等待某些结果的服务发送同步 *调用。当然可以引入并行操作，但事实并非如此，但重点是该演员决定了传奇的进展。
这与编排模型根本不同。使用这个模型，没有中心角色跟踪传奇的状态，而是通过每个步骤发出的事件隐含地进行传奇进展。可以说，这是事件驱动的模型的纯情况，因为没有协调。
也就是说，这个模型的挑战是在任何给定的时间点观察状态。通过上面的编排模型，理论上可以查询每个参与者的状态。在这个精心设计的模型中，我们没有这种奢侈，所以在实践中，相关ID被添加到对应于（在这种情况下）传奇的每个消息中。如果消息以某种方式可查询（事件总线支持它或通过其他一些存储装置），则可以查询与saga相对应的消息并且可以重建saga状态..（实际上是一个建模的事件源）。 / p>
谁应该知道如何建立Saga事件链？接收某项工作的第一个微服务还是路由器？
这是一个有趣的问题，也是我一直在思考的问题。最简单和默认的答案是..硬编码传奇计划并将它们映射到传入的消息类型。例如。消息A触发计划X，消息B触发计划Y等
但是，我一直在考虑管理这些计划的控制平面可能是什么样的，并提供了动态地将更改动态推送给消息处理程序和/或协调器的机制。考虑两个特定用例是授权策略的更改或动态地向计划添加新步骤。
如果某个事件需要将大量数据传递给下一个Saga事件，那么如何根据请求结构完成此操作？例如它被分成多个Sagas（作为结果分页类型）？
我接近这个的方法是包含对大数据的引用，如果它们是诸如文件之类的对象。对于固有地自身流式传输的数据，可以引用消费者一旦接收到消息就可以读取的并行信道。我认为这里的重要区别是将驱动工作流的消息与数据物理实现的位置分离，这取决于数据表示。