我正在尝试将队列实现到我们的微服务架构中,特定的AWS SNS / SQS。
例如,我有这种情况。创建订单后,订单MS会引发OrderCreated事件,此事件会将消息发布到AWS OrderCreated SNS。 SQS队列InvoiceCreate订阅了OrderCreated SNS并将收到此消息。
到目前为止,一切都有意义。如果开票MS正在收听InvoiceCreate队列并检索所有新邮件 - 开票MS应该创建发票,但我的问题是什么数据?
a)联系订单MS(订购与创建发票相关的数据)。如果无法执行此操作,则消息将保留在队列中,直到开票MS能够收集相关数据
b)发布的消息应包含创建发票所需的所有相关数据。
如果选择A Invoicing MS将不会解耦,它将取决于订单MS,但另一方面,它可以收集除原始消息打包的数据之外的其他数据。
如果选择B,因为OrderCreated事件和OrderCreated SNS确实不知道谁将使用消息数据,即。 OrderCreated也可用于执行不同的操作,我很困惑如何精确地决定在此消息中应该填充哪些数据
我们的体系结构设置更像您的选项B.要使用您的示例,Order服务将发布它的OrderCreated事件并附加 - 作为有效负载 - 消息的Payload部分中的大多数(甚至全部)Order信息。我们将消息和有效负载格式化为JSON以实现兼容性,但您可以做任何事情。
在某些情况下,我们不会发布所有信息,只发布已添加/已编辑实体的特定字段 - 这取决于服务和信息的敏感性。只要你只为消息添加字段(不要删除任何字段),你就是在遵守合同并且与它没有紧密联系。
同样,对于您的示例,InvoiceService可以从以下一个或多个选项中获取其信息:
最好通过直接调用OrderService来避免InvoiceService响应消息 - 这是一个非常紧密的耦合,如果必须的话,可以通过简单的消息传递来避免。
所以,有很多选择。我个人更喜欢在创建/更新内容时将所有可能有用的数据放入消息中并让消费服务决定使用/忽略的方法。对于我们的场景,这很有效但我们只有少数包含良好的客户端访问我们的服务,因此可能有更安全的方法来执行它与我们无关。