分布式应用程序之间的消息中会包含哪些数据？

Question

我正在尝试在我们的微服务架构中实现队列，以实现特定的AWS SNS / SQS。

例如，我有这种情况。 创建订单后，Orders MS引发OrderCreated事件，此事件将消息发布到AWS OrderCreated SNS。 SQS队列InvoiceCreate已订阅OrderCreated SNS，并将收到此消息。

到目前为止，一切都是情趣。如果Invoicing MS正在监听InvoiceCreate queueu并检索所有新消息-Invoicing MS应该创建一个发票，但是我的问题是什么数据？

a）联系MS订单（订购与创建发票相关的数据）。如果无法这样做，则消息将一直留在队列中，直到进销存MS能够收集相关数据为止

b）发布的消息应包含创建发票所需的所有相关数据。

如果选择“开票制MS”，则不会分离，而是取决于“订购MS”，但另一方面，它可以收集除原始消息包装的数据以外的其他数据。

如果选择B，则由于OrderCreated事件和OrderCreated SNS并不真正知道谁将使用消息数据，即。 OrderCreated还可用于执行不同的操作，我很困惑如何精确地决定应在此消息中填充哪些数据

Answer 1

我们的体系结构更像您的选项B。要使用您的示例，Order服务将发布它的OrderCreated事件，并在其有效负载部分的大部分（甚至所有）订单信息中附加（作为有效载荷）信息。我们将消息和有效负载格式化为JSON以实现兼容性，但是您可以执行任何操作。

在某些情况下，我们不会发布所有信息，仅发布“添加/编辑”实体的特定字段-这取决于服务和信息的敏感性。只要您只向消息中添加字段（不删除任何字段），就表示您遵守合同，而且并没有真正与其紧密联系。

再次，在您的示例中，InvoiceService可以从以下几个选项中的一个或多个中获取其信息：

• 如果您包括所有需要的内容，则直接从OrderCreated消息中将其拉出
• 从OrderCreated消息中提取所有内容，发布一个InvoiceStarted事件，该事件触发OrderService（和/或其他人）向其发送OrderInvoiceComplete消息以及所需的其他详细信息
• 保留所需的任何关键数据的本地副本-通过订阅其他事件进行填充-以便可以将OrderCreated数据与某些本地数据结合起来充实发票

最好避免InvoiceService通过直接回拨给OrderService来对消息做出响应-这是一种非常紧密的耦合，可以根据需要通过简单地发回消息来避免这种情况。

因此，有很多选择。我个人更喜欢这样一种技术，即在创建/更新事物时将所有可能有用的数据放入消息中，并让消耗性服务决定使用/忽略什么。对于我们的方案来说，这种方法效果很好，但是只有少数设备完善的客户可以访问我们的服务，因此可能存在更安全的方式来进行与我们无关的