可以说，没有什么能阻止你这样做。如果所有三个服务在同一数据库示例上使用不同的架构，则可以为每个服务Flyway配置设置defaultSchema和schemas属性，以确保架构历史表位于每个服务各自的架构中，并且不会有任何重叠。

然而，如果您对每个服务使用相同的模式，我在以前的项目中已经看到，版本控制可能会使系统出错。

**例如：**如果每个服务都管理自己的迁移脚本版本，则可能会导致冲突。也就是说，如果服务A有V1、V2和V3脚本，服务B也有V1、V2和V3脚本，那么Flyway将抛出一个校验和错误，因为它将在服务A之后迁移服务B时检测到V1等内容已更改。然而，如果仔细对迁移脚本进行版本控制，就可以解决这一问题。为了方便起见，我建议使用隐式创建时间顺序的版本化系统，例如V2022.08.26.10.01__your_script.sql。

或者，您也可以使用out of order来更好地控制迁移顺序

您可以拥有一个包含所有迁移脚本的模块，它可以由所有服务(在您的示例中为A、B和C)作为依赖项添加。一旦准备就绪，只有一个服务应该运行迁移，例如，服务A和其他服务(B和C)应该只验证模式。作为一个优势，如果您在您的服务上运行集成测试，它们可以在测试时独立运行Flyway或在您的CI/CD管道上执行测试。即使对于当地的开发，Flyway也可以被激活。

不幸的是，这引入了对服务部署顺序的轻微依赖，它们仍然可以以任何顺序进行部署，但在负责迁移执行的服务完成其工作之前，另一个服务将是不健康的。如果您使用某种蓝/绿部署样式、竖井或类似方式，这应该不是问题，而只是需要考虑的问题。

如果您决定尝试这样的操作，您只需覆盖Flyway迁移阶段，并在验证仍在运行时将迁移方法保留为空。我想你需要看看FlywayMigrationStrategy，但我已经有一段时间没有做过了，先检查一下自己。