单个 dotnet core 解决方案 + git 存储库中的多个微服务？

Question

我正在研究 API 层新架构解决方案的选项。我们决定使用 dotnet core，并且希望将应用程序功能的每个部分分解为微服务。我们使用 azure devops 来处理构建/测试/发布 CI/CD 工作流程。

根据广泛的分析，我估计我们当前的后端解决方案可以分为 10-15 个独立的微服务。不幸的是，其中大多数都有类似的后端依赖关系，但我仍然想将它们分开，这样我们就可以隔离单元测试，拥有更小的 CI/CD 足迹，并让项目从关注点的牢固分离开始。

然而，与此同时，我希望避免使用 10-15 个不同的 git 存储库、解决方案和 CI 流程来促进此工作流程。对于开发的简化来说，这将成为一场噩梦，因为开发人员需要定期更改工作空间（任何 IDE 中的“最近打开”列表都会完全溢出！）、维护和同步 10-15 个 CI/CD。

在我看来，理想的结果是单一解决方案、git 存储库和构建流程，其中每个微服务作为解决方案中的一个项目分开。当代码提交时，我想在 Azure DevOps 中启动一个进程，该进程只会构建/测试/部署那些在提交中更改的服务。

这是可能的还是我在做梦？我在谷歌上运气不佳，但也许我没有为此输入正确的短语......

提前致谢！

Answer 1

我们的情况大致相似，并决定将我们的微服务（不幸的是，使用共享数据库）托管在单个 git 存储库中，但每个微服务都有自己的解决方案。每个 API 都有自己的构建定义，每个构建定义都有自己的带有路径过滤器的触发器。我想，即使 API 位于同一解决方案中，这种方法也能发挥作用：使用触发器中的路径过滤器创建单独的构建，目标是每个 API 源代码位于 git 存储库中的文件夹。当多个 API 发生更改时，只有针对这些文件夹的构建才会启动。请参阅Azure DevOps 文档中的构建管道触发器。

我建议您考虑如何跟踪版本，因为您最终会得到 10-15 个版本定义。单独跟踪它们（以查看在特定测试环境中运行的构建）有点麻烦，而且我还没有找到一种好方法来制作仪表板来显示部署到特定环境的所有版本/阶段。