我了解事件驱动架构，其中服务订阅事件以进行服务间通信。当一个实体被创建/更新/删除时可以触发一个事件。但是在 GET 请求的情况下如何实现服务间通信。
例如：为最终用户返回产品通知列表的通知微服务 - 需要读取用户的通知偏好（他想要通知哪些产品），需要获取基本产品信息（产品名称，价格）和通知数据本身的通知服务。
这可以通过在通知服务中编排所有服务（偏好服务、产品服务）来轻松实现 - 但这会导致那里的紧密耦合。
当需要从多个服务中获取数据时，在微服务中实现服务间通信的正确方法是什么？
【问题讨论】：
标签： api design-patterns architecture microservices
这里有一些误解，我会尝试列出它们。事件驱动架构并不是真正用于“服务间通信”。此处的术语事件 是指您的系统发生的可能触发状态更改的事情。例如，像这个例子一样陈词滥调的是“存款”和“取款”是发生在你的系统上的特定领域的事件。本场景下的存款是存款事件中交易金额的加法，提款是提款事件的减法强>。事件驱动架构有效地将数据和数据处理解耦。
这可以通过在通知服务中编排所有服务（偏好服务、产品服务）来轻松实现 - 但这会导致那里的紧密耦合。
如上所述，从多个微服务获取数据可能不被视为紧密耦合。它也可以被认为是凝聚力。内聚作为一种尊重领域的耦合形式。例如，如果这些偏好是特定于通知的，那么它就是一个通知偏好，因此可以存在于同一个服务中。
为了管理您可能希望接收通知的产品，每次创建新产品时，您都可以使用通知服务可能感兴趣的“ProductAdded”事件将产品名称或标识符传播到事件总线然后，通知服务可以将产品创建为用户可以订阅以接收通知的选项。让我知道这一切是否有帮助，以及我是否可以澄清其他任何事情。
【讨论】：
使用工作流系统，例如Argo。
在我的术语中，通知微服务是一个复合服务。执行此操作的传统方法是在 ESB 中编排其他服务 - 与您的建议非常相似：
这可以通过在通知服务中编排所有服务（偏好服务、产品服务）来轻松实现 - 但这会导致那里的紧密耦合。
【讨论】：