具有大量数据的服务集成

Question

我试图评估microservices/DDD对于我正在编写的应用程序的可行性，对于这个应用程序，一个特定的上下文/服务需要响应在另一个上下文中完成的操作。虽然以前我会通过发布到消息队列的集成事件来处理这个问题，但我还没有处理可能包含大量数据的事件。

作为一个通用的例子。假设我们有一个命令和激励上下文。下订单时，需要生成发票并发出发票。

对于这些信息，我将使用顺序信息引发一个OrderPlaced事件，例如：

public class OrderPlacedEvent
{
    public Guid Id { get; }
    public List<OrderItem> Items { get; }
    public DateTime PlacedOn { get; }
}

从Orders上下文中，Invoicing上下文将使用此事件来生成所需的发票。这看起来相当标准，但是所有的例子都是相当小的，并且似乎没有解决如果订单中有1000+项会发生什么，这使我相信，也许集成事件只是针对一些小的信息。

“最简单”的方法是只使用一个订单ID并查询orders服务来获取其余的信息，但是这将增加方法试图删除的两个服务之间的耦合。

我的假设是事件数据应该是最小的正确吗？如果是的话，我怎么可能(甚至可能)呢？正确地处理这样一个场景，其中存在另一个上下文/服务需要响应的大数据块？

Answer 1

信息有许多不同的预期粒度，这取决于你想要实现什么。马丁·福勒( Martin )对此有一个很好的讨论，那就是事件驱动体系结构(https://www.youtube.com/watch?v=STKCRSUsyP0&feature=youtu.be)的许多含义。他给出了四种风格：

• 事件通知(几乎没有数据的spartan“发生了什么”消息)。
• 事件进行状态转移(与以前相同，但消费者可以追溯到生产者系统以获得详细信息)。
• 事件源(将较小的消息单独存储在其周围的视图中)。
• CQRS (带有拆分、更新和读取合同的附加想法的事件源)。

我通常添加第五种类型的消息传递(而不是事件驱动的)，这只是一个直接上升的工作队列，其中一些进程A正在为进程B创建工作。

对于更具体的场景，1000 s的项目看起来并不是太大。不过，如果这是个问题，我可能会考虑触发工作队列的事件源系统。所以就像这样：

[Order System] --> [Invoicing Events] --> (Invoice Order Events)
                         |                         ^
                         v                         |
                   [Invoicing Step 1]          [Invoice Order Service]
                         |
                         v
                        ...
                    [Invoicing Step n]

每个发票步骤都可以调用发票系统的微服务，该服务包装了从订单事件构建的事件存储。

工作队列(所有发票步骤)消息可以相当小，只要有足够的数据就可以告诉下一个处理器需要什么才能开始。来自订单系统的消息可能是小的，也可能是大的，只要您已经建立了一个系统、适当的视图，就不会有多大关系。

我还勾勒出了相当线性的发票，但不一定是这样。如果您有分支或同级步骤，您肯定可以这样构建它。