单体仓库与多仓库都有哪些优势劣势，微服务选择哪种方案比较好？

这段时间在研究bilibili泄露出来的源码，发现bilibili虽然使用了微服务的设计理念但是所有服务都是放在同一个仓库底下的，而我司和bilibili恰恰相反，我司所有项目都是分开独立的，也出现了一些问题。于是就产生了好奇并在网上进行了探索随后产生了这篇文章。

本文会尝试回答下面几个问题：

1. 什么是单体仓库(mono-repo)？
2. 为什么 Google/Facebook/Bilibili 采用单体仓库？
3. 单体仓库(mono-repo)和多仓库(multi-repo)分别解决了哪些问题？
4. 单体仓库(mono-repo)和多仓库(multi-repo)在解决问题的同时又引入了哪些问题？

为什么要区分单体仓库和多仓库？

在介绍单体仓库和多仓库前，我们先了解一下应用的类型，了解一下为什么要区分单体仓库和多仓库。

1. 单体应用

在早期，实际上是不用区分单体仓库和多仓库的，因为在早期的时候一个应用就把所有功能打包了。哪怕使用多个仓库也是根据公共模块方式来区分，仓库数量也是比较少的。这时候的应用我们一般叫他单体应用。主要的特点就是一个程序就打包所有功能，全家桶。

这样的开发模式有很多优点，如：

1. 易于理解项目整体。开发人员可以把整个项目加载到本地的 IDE 当中，进行 code review，方便开发人员把握整体的技术架构和业务目标。
2. 易于集成和部署。所有的代码在一个仓库里面，不需要特别的集中管理和协调，也可以直接在本地部署调试。
3. 易于重用。所有的代码都在一个仓库中，开发人员开发的时候比