在微服务中，为数据库迁移脚本和API代码提供单独的代码存储库是否有意义？

Posted 2021-05-05

根据bounded context，我们已经确定了两个微服务实现，让我们分别称它们为Service A和Service B。这些微服务中的每一个都有不同的存储库（由于单一责任和更好的所有权的好处）。现在，每个这些存储库都使用自己的数据库模式（为更好地分离持久性和减少数据库实例的维护而做出的选择）。

之前，我们将数据库迁移脚本（用于持续交付）提取到单独的单个存储库（包含Service A和Service B模式的脚本）中，并在CI下的单个作业下运行它们。现在，当我们处理更多故事时，我们已经开始面临一些挑战，其中一些列在下面：

• 对单个模式的更改会触发整个数据库的构建，从而触发所有微服务的下游触发，从而增加我们的反馈时间
• 我们总体上未能实现true持续交付，因为模式更改也需要Service代码的相应更改，因此谨慎地努力部署PRs
• 此外，还有一些常见的表，如Users，需要两个模式使用，这些模式目前在两个模式中都是重复的。

所以我的疑问/怀疑是：

• 我们是否应该根据模式分离数据库迁移存储库，就像服务一样。
• 我们是否应该为数据库迁移脚本提供单独的存储库？我们应该在他们各自的Service存储库代码中加入他们吗？
• 我们是否应该进一步提取常见表a level up并为Domain Events提升Eventual Consistency

任何指针/建议都会有很大帮助。谢谢。

答案

您应该考虑使用相应的代码存储库保留迁移。服务A应该有自己的一组独立于服务B的迁移。这将允许您部署服务A并迁移A的模式，而不会对服务B产生任何影响。

此外，您应该考虑没有通用表。常见表可能有严重的缺点。如果服务A需要以破坏服务B的方式修改用户，则您已创建了分布式整体。

---

更新1：

构建审核日志可能不需要强大的参照完整性。您可以考虑使用软外键。

您设计微服务的大部分依赖于域。如果User是经过身份验证的用户，那么您应首先解决身份验证的交叉问题。您可以为每个微服务选择要求身份验证令牌（例如jwt）来确定经过身份验证的用户是谁以及他们是否有权执行某些操作。然后，您只需在审核日志中使用用户的ID即可。

至于用户是否“属于服务的有限环境”，它可能不会。换句话说，对User的更新如何绑定到Service A？您可能不认为用户从属于服务A，也不想通过针对服务A的操作来更新用户。