在微服务架构中实现低耦合

时间:2020-01-05 10:58:50

标签: architecture microservices

在我们的系统中,许多用例中都需要客户详细信息。 在某些用例中,某些服务需要与第三方验证此数据,而其他服务则应将该数据发送到其他第三方的服务,以便与客户建立合同。

正如我所见,处理它的方法很少,而且都很糟糕:(

  1. 向客户服务发送查询(这意味着对其进行高度耦合)
  2. 收听来自客户服务的所有事件,并将所有客户的详细信息作为高速缓存保存在需要该数据的所有服务中((复杂的解决方案,由于同步问题而可能会发生许多错误,等等。)。 li>

我认为选项1更好,但这意味着许多服务与客户服务之间的高度耦合...

还有更好的方法吗?

1 个答案:

答案 0 :(得分:0)

通常在体系结构考虑中,可能没有“最佳”方法,但是任何解决方案都将在需求和条件方面进行权衡。

已经讨论了如何在微服务体系结构中共享数据的问题,例如herehere;我也喜欢this articlethis article这个话题。

对于您的情况,我看到以下选项:

  • 每个服务都有一个数据库,用于存储其拥有的数据:基本上,这是您的第一选择,实际上是微服务架构的“原始”想法。实际上,我不太同意这会导致高度耦合,但是您必须仔细设计接口以使其独立于内部数据结构和逻辑。较小的服务,而是它们之间更多的通信是典型的结果。
  • 所有服务共享的单个数据库:这确实增加了更多的耦合,并且打破了微服务架构的概念。但是,如果您希望对用例/数据模型/数据库架构等所做的更改很少,则可以选择这种方法。
  • 事件/订阅模型:您必须非常清楚事件是什么;如果您有许多事件和/或许多订阅者,则可能会变得复杂。
  • 最后:重新考虑微服务方法-例如,它可能有助于将多个单一服务组合为一个较大的服务。

决策还应取决于预期的数据量,可伸缩性,更改频率。