Architecture 微服务关系/依赖策略

我想了解一些关于处理跨微服务的数据依赖性和关系的两种不同解决方案的反馈

以这些服务为例：

简单地说，有银行服务和账户服务。帐户服务保存帐户，并始终使用银行ID连接到银行

困境在于如何处理和验证这种关系和bankId以及每个决策的利弊

选项1:

完全忽略验证。如果给定的银行ID是现有ID，则针对帐户的POST/PATCH将永远不会验证

专业人士

• 服务彼此不了解，它们之间没有硬依赖关系，如果一个服务宕机，另一个也不会停止工作。（哪个是大的）

缺点

• 如果银行标识不正确，则帐户“丢失”，无法访问
• 报告服务和/或任何读者必须解释丢失或不正确的银行，并在不崩溃的情况下提供其拥有的任何数据

倒影

这些服务是完全解耦的，这将有利于性能、时间和复杂性。所有读卡器和应用程序都需要是“反应式”的，并且能够在跨服务关系“中断”时处理

选项2:

始终使用同步REST调用进行验证。如果BankId不存在或BankService无法响应或已损坏，则针对帐户的POST/PATCH将失败

专业人士

• 100%数据完整性
• 读者不需要处理和期待破裂的关系

缺点

• 服务是紧密依赖的，您可能会争辩说，它们不再是合适的微服务，也可能是单一服务
• 绩效受到负面影响
• AccountService发布/修补程序将不起作用如果BankService关闭，GET仍将起作用

倒影

服务是紧密依赖的，这真的很糟糕，这更像是“老办法”，一般来说，我觉得这样做是错误的。在这种情况下，合并服务甚至更糟糕，如果你开始通过合并来解决问题，你可能会继续这样做，很快就会得到大量服务，而整个微服务原则都失败了。当然，阅读仍然有效，但这是一个牵强的借口

选项3:

在AccountService中保留BankEntity的只读副本。AccountService通过事件总线保持此更新。在POST/PATCH上对此进行验证

专业人士

• 100%数据完整性
• 读者不需要处理和期待破裂的关系
• 没有可测量的负面绩效影响

缺点

• 复杂性增加
• 由于事件的异步性质，我们不能假设银行的只读副本已100%更新。创建银行实体后，快速连续发布/修补帐户可能会失败
• AccountService获得了更多关于其他服务的知识，尽管它是一个松散的依赖项

倒影

这是最复杂的方式，读者不需要处理断开的关系，性能/运行时间问题也得到解决，但是，您必须处理银行的只读副本可能尚未更新的事实，然后稍后再试。将其与选项1进行比较意味着你仍需要以某种方式处理它，而且由于这将更为复杂，所以我认为这不是最有利的一个

结束想法

最好实现的总体目标是服务之间不同步地通信，并且数据完整性尽可能好

然而，在一个微服务体系结构中，我的印象是，关系完整性可能只是这样做会让你失去的东西之一

我们的决定倾向于选项1，实际上只是忽略了它，在任何需要使用它的地方，您都必须预期并处理它可能不正确的情况。这似乎是最“微型服务”的解决方案，服务之间并不真正了解对方，只有应用程序和报表服务需要进行跨服务操作

任何服务都需要承担全部责任，确保它们在任何给定时间都拥有充分发挥自身功能所需的所有数据。假设AccountEntity出于任何原因需要一个位置才能成为一个可用且完整的域实体，您不能指望依赖BankId，您必须将位置存储在AccountEntity上，如果它发生变化，您可能会得到一个事件，您可以更新它

TL；DR

---

你对此有何经验、看法和想法？你会怎么做？你会选择哪种策略？

这一种策略是基于观点的，这里没有正确或错误的答案（实际上不是正确的，有很多错误的答案，但也有很多正确的答案）。这实际上取决于您的用例。就个人而言，我倾向于更松散的耦合，直到我需要更强的耦合

我最喜欢的模式是为银行ID输入URL，而不是数字。这将为您提供一个指向银行的指针，而不必知道另一个服务的内部结构的细节

---

如果以后您决定需要ID，您可以解析所有URL并收集ID，也可以在运行时这样做。关键是，您还不必知道这一点，除非您已经有了这些数据的使用用例，否则不要将其耦合起来。

首先，您选择的选项将取决于您的业务需求

完全忽略：在您的银行和帐户的情况下，我不想使用这种方法，因为这可能会导致丢失帐户。在业务流能够确保sonner或更高版本的解决方案的情况下，您可以采用这种方法