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

Question

按照bounded context ，我们已经确定了两个微服务实现，我们分别将它们称为Service A和Service B。每个微服务都有不同的存储库(由于单一职责和更好的所有权的好处)。现在，每个存储库都使用自己的数据库架构(选择是为了更好地分离持久性并减少数据库实例的维护)。

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

• 对单个架构的更改会触发整个数据库的构建，从而触发所有微服务的下游，从而增加我们的反馈时间
• 我们通常无法实现真正的持续交付，因为架构更改还需要对Service代码进行相应的更改，因此在部署这两种服务时会采取谨慎的努力PRs
• 此外，还有一些通用表(例如 Users)需要由两个架构使用，目前这些表正在两个架构之间进行复制。

所以我的问题/疑问是:

• 我们是否应该根据架构分离数据库迁移存储库，就像服务一样。
• 我们是否应该有单独的数据库迁移脚本存储库？我们是否应该将它们合并到各自的 Service 存储库代码中？
• 我们是否应该进一步提取公共(public)表上一层并为 Eventual Consistency 引发域事件

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

Answer 1

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

此外，您应该考虑没有公用表。公用表可能有严重的缺点。如果服务 A 需要以破坏服务 B 的方式修改用户，那么您就创建了一个分布式整体。

<小时/>

更新1:

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

您设计微服务的方式在很大程度上依赖于领域。如果用户是经过身份验证的用户，那么您应该首先解决身份验证的横切问题。您可以选择让每个微服务需要身份验证 token (例如 jwt)来确定经过身份验证的用户是谁以及他们是否有权执行某些操作。然后您可以简单地在审核日志中使用用户的 ID。

至于用户是否“属于服务的有界上下文”，很可能不会。换句话说，User 的更新如何绑定(bind)到 Service A？您可能不认为该用户从属于服务 A，也不想通过针对服务 A 的操作来更新用户。