微服务中的服务间通信

时间:2018-10-22 14:35:49

标签: api design-patterns architecture microservices

我了解事件驱动的体系结构,其中服务订阅了事件以进行服务间通信。创建/更新/删除实体时可以触发事件。但是在GET请求的情况下如何实现服务间通信。

例如:一个通知微服务,该服务返回最终用户的产品通知列表-需要读取用户的通知首选项(他想要通知哪些产品),需要获取基本产品信息(产品名称,价格)以及通知数据本身的通知服务。

这可以通过在通知服务中协调所有服务(首选项服务,产品服务)来轻松实现-但这会导致在那里紧密耦合。

当需要从多个服务中获取数据时,在微服务中实现服务间通信的正确方法是什么?

2 个答案:

答案 0 :(得分:1)

这里存在一些误解,我将尝试列出它们。事件驱动的体系结构并不是真正的“服务间通信”。术语事件在这里是指系统中发生的可能触发状态更改的事件。例如,像本例这样的陈词滥调是“存款”和“提款”是系统中发生的特定于域的事件。在这种情况下,存款是存款事件中交易金额的,而提款是提款事件中 强>。事件驱动的体系结构有效地将数据与数据处理分离。

  

这可以通过在通知服务中协调所有服务(首选项服务,产品服务)来轻松实现-但这会导致在那里紧密耦合。

根据以上几点,从多个微服务获取数据可能不被认为是紧密耦合的。也可以将其视为凝聚力。凝聚力是尊重领域的一种耦合形式。例如,如果这些首选项特定于通知,则其为通知首选项,因此可以存在于同一服务中。

为了管理您可能希望接收其通知的产品,每次创建新产品时,都可以将产品名称或标识符传播到带有“ ProductAdded”事件的事件总线,通知服务可能对此事件感兴趣然后,通知服务可以将产品创建为用户可以订阅接收通知的选项。让我知道这是否有帮助以及是否可以澄清其他内容。

答案 1 :(得分:0)

使用工作流程系统,例如Argo

在我的术语中,通知微服务是复合服务。传统的做法是在ESB中协调其他服务-与您的建议非常相似:

  

这可以通过在通知服务中协调所有服务(首选项服务,产品服务)来轻松实现-但这会导致在那里紧密耦合。