为何微服务项目都使用单体代码仓库？
之前在学习微软的示例eShopOnContainers时发现它使用的是单体代码仓库库，之后又发现大家在进行微服务项目开发时也都在使用单体代码仓库。问题来了，为啥要微服务项目都要使用单体仓库（所有微服务都在一个代码仓库）呢？
之前在学习微软的示例eShopOnContainers时发现它使用的是单体代码仓库库，之后又发现大家在进行微服务项目开发时也都在使用单体代码仓库。问题来了，为啥要微服务项目都要使用单体仓库（所有微服务都在一个代码仓库）呢？
1 微服务应用的代码仓库组织
我们都知道，微服务应用相对于单体应用来说，最大的好处就是可以独立开发、测试、部署和扩展。单体应用一般会采用单体代码仓库，但是微服务应用的代码仓库应该如何组织呢？是每个微服务一个仓库吗？
其实不一定，针对微服务应用的代码仓库组织，业界有两种主要的实践：
（1）多体仓库（Multi-Repo）：即每个微服务对应各自代码仓库
（2）单体仓库（Mono-Repo）：即所有微服务对应一个代码仓库
下图展示了这两种实践的示意（引用自波波老师《Spring Boot与K8s云原生应用开发》课程）：
单体应用仓库 vs 微服务多体仓库 vs 微服务单体仓库
2 多体仓库与单体仓库的比较
多体仓库的优点显而易见，职责单一，代码量和复杂性受控，支持多个团队独立开发，边界清晰。单个微服务也易于独立开发测试和扩展，不需要集中式管理。差不多，这些就是微服务带来的好处。
但是，多体仓库有其自己的缺点：
一来项目代码不容易形成统一规范，每个团队各自为政，随意引入依赖，Code Review无法集中开展，代码风格也会各不相同。
二来项目整体集成和部署会比较麻烦，虽然单个项目集成容易，但是整体进行集成就会收到仓库分散带来的困难。
三来也是我个人认为对于中小技术团队来说最为重要的，开发人员会缺乏对于整体项目的认知，只关心自己负责的那一小块，从而缺失对整体架构和业务目标整体性的理解。
最后，项目间可能会存在较多的冗余代码，每个微服务一个仓库会造成每个团队不断地重复造轮子，而不是去优先重用其他团队开发的已有的项目代码。
对于多体仓库的缺点，单体仓库解决了一些，这也就形成了单体仓库的好处：
一来易于规范化项目代码，所有微服务都在一个仓库中，可以规范代码风格，便于集中组织Code Review。
二来易于整体集成和部署，所有微服务都在一个仓库中，配合DevOps工具可以方便地实现一键构建和部署，实现持续集成。
三来易于理解项目整体，开发人员可以将整个项目clone到本地IDE中进行Code Review也可以直接本地部署和调试从而易于掌握整体技术架构和应用目标。最后易于重用已有轮子，开发人员在开发时容易发现和重用已有的代码而不是去重复造轮子，当然也利于对现有的代码进行重构。
当然，万物都是有利有弊，单体仓库也不例外。随着业务的快速发展，单体仓库中的项目代码会变得越来越庞大，复杂性也会随之上升。因此，对于企业来说，需要有专门的集成团队和自动化的集成工具来支持，才能保证单体仓库的持久应用。
3 业界都有哪些企业谁在用单体仓库？
在业界使用单体仓库组织微服务项目的企业不少，例如Google、Facebook、Twitter和Salesforce以及Microsoft等互联网巨头，虽然他们内部的项目庞大，开发人员众多，但是他们还是选择了使用单体仓库。
谁在用MonoRepo
eShopOnContainers项目代码结构
刚刚我们也说道，这些巨头企业都是有专门的集成团队和成熟的自动化集成工具来为开发团队进行支持，使得开发团队可以一键构建和部署。
画外音：对小企业来说，可能上微服务架构都得慎重？一百个读者，有一百个哈姆雷特，各有各的看法。
4 小结
对于中小企业/初创企业/进行数字化转型的传统行业企业来说，如果要上微服务架构，一般早期微服务的数量不会特别多，采用单体仓库会比较合适。
从本文也可以了解到，微服务架构并不是倡导所有的东西都要独立自治，像代码仓库就可以集中管理，而且这也是业界的最佳实践之一。
最后，如果你在使用.NET Core开发微服务或者计划使用.NET Core开发微服务，都可以先阅读一下这本《.NET微服务：容器化应用架构指南》，目前已更新到ASP.NET Core 3.1版本（LTS版本）。
画外音：欲练此功，必看此书。点击此处即可学习此书！
