每个微服务对应一个代码库吗？

你是把每个微服务放在它自己的 git 存储库中，还是使用 monorepo？如果是后者，您如何在同一个 repo 中处理多个服务？

回答
1. 我一直为每个服务使用一个 repo，但这主要是因为我们在工作中使用 maven 和 GitHub。我发现 monorepo 的想法很有趣，但我一直无法找到正确的工具，也不想花时间自己动手。

我反对monorepo的想法。一旦你建立了一个完整的微服务生态系统，它们就会变得非常大，而且很难在企业规模上工作。

例如，在我的公司里有一个近4GB的 repo。它不断有50多个PR在等待审查/批准/合并。

在许多情况下，开发团队可能很少互动，也不在彼此的代码上工作。因此，他们没有必要为了在自己的项目上工作而被迫下载另一个团队的代码，以monorepo的形式。

如果开发团队之间联系紧密，并且经常需要其他团队的大部分工作来完成自己的开发任务，那么单库就非常好。

另外，拥有较小的存储库使得管理用户访问和授权变得更加容易。我非常喜欢在大型项目中使用单独的软件库。

2. 不存在 "一刀切 "的情况

典型的例子：当开始一个项目的时候，有可能边界不是很清楚，因此服务之间的接口经常变化。如果是这样的话，一个monorepo就更方便了：把所有的服务放在一个地方，可以更好地看到什么在哪里。

另一个典型的例子：一些服务变得 "独立"，因为它开始被不同的客户使用，这些客户使用不同的服务版本。这样的服务应该有自己的资源库。

或者，那可以是一组相关的服务。

或者，我们根本不在乎，反正就是把所有东西都放在一个地方。

换句话说：这个问题没有上下文是错误的。我们需要看一下当前情况的需要。

Tha说，即使我们想问这个问题，回答这个问题也是错误的。回答是错误的，因为无论哪种方式都可以取得体面的结果。这是一个骑自行车的问题，是一个不太重要的问题。尽管人们会过分执着于一个或另一个答案，但这是真的。

3. 每个服务的Repo。简化了部署，并确保内部管理的依赖关系只通过版本化的工件消费。

4. 我两种都用过。Monorepo更容易。

内部的依赖性变得非常简单。本地开发始终是最新的，可以很容易地用一个脚本/命令来控制，因为所有的东西都在那里，并且始终保持同步。集成测试有一个有意义的家，可以毫无顾虑地在本地运行。

你可以在一个分支/PR中为多个服务编写代码，这是一个巨大的人体工程学的好处。

如果你的团队不大，GitHub/gitlab的界面很好，因为你不需要打开20个标签来查看正在发生的事情，即使你只有几个开发人员。

我倾向于默认使用Monorepo来处理任何不是真正独立的项目。

5. 你得到的主要好处是。

原子化修改。当你做一个广泛的改变时，你不需要提交到多个仓库。

所有的东西在任何时候都是在一个版本的依赖关系上。从安全的角度来看，这对避免某些微妙的bug很有用。

每个人都可以很容易地接触、搜索和以其他方式使用所有的代码。

主要的缺点是，当 repo 越来越大时，你需要专门的工具。这通常意味着需要一个专门的团队来完成。这真的只对小型和大型公司有意义，对那些处于中间的公司来说，交易是很差的。

6. banq：这取决于你对领域和上下文的划分，每个子领域对应一个代码库，当然，复杂核心子域是每个BC对应一个代码库，这还和clean架构实现有关。