是否选择Monorepo？

最近去新的团队，看到使用Monorepo的方式管理代码。感觉好像和微服务有些冲突，但最终确实是生成一个一个的应用，好像也没影响到微服务啊。这两天又想了一下，确实是有一些冲突的。

Monorepo介绍

Monorepo 是一种项目代码管理方式，指单个仓库中管理多个项目，有助于简化代码共享、版本控制、构建和部署等方面的复杂性，并提供更好的可重用性和协作性。Monorepo 提倡了开放、透明、共享的组织文化，这种方法已经被很多大型公司广泛使用，如 Google、Facebook 和 Microsoft 等。

Monorepo 演进

阶段一：单仓库巨石应用， 一个 Git 仓库维护着项目代码，随着迭代业务复杂度的提升，项目代码会变得越来越多，越来越复杂，大量代码构建效率也会降低，最终导致了单体巨石应用，这种代码管理方式称之为 Monolith。

阶段二：多仓库多模块应用，于是将项目拆解成多个业务模块，并在多个 Git 仓库管理，模块解耦，降低了巨石应用的复杂度，每个模块都可以独立编码、测试、发版，代码管理变得简化，构建效率也得以提升，这种代码管理方式称之为 MultiRepo。

阶段三：单仓库多模块应用，随着业务复杂度的提升，模块仓库越来越多，MultiRepo这种方式虽然从业务上解耦了，但增加了项目工程管理的难度，随着模块仓库达到一定数量级，会有几个问题：跨仓库代码难共享；分散在单仓库的模块依赖管理复杂（底层模块升级后，其他上层依赖需要及时更新，否则有问题）；增加了构建耗时。于是将多个项目集成到一个仓库下，共享工程配置，同时又快捷地共享模块代码，成为趋势，这种代码管理方式称之为 MonoRepo。

在这里插入图片描述

冲突

对于公司当前的场景，使用Go语言，微服务化部署的情况下，我是建议选择Multi-repo方案的。因为Mono-repo的优势不是很明显：

Go语言没什么复杂的工程配置
一般也不需要共享模块代码，功能层面可以通过rpc调用，一些通用逻辑可以维护SDK即可。而且即使用mon-repo，如何确保所有人员知道已经有这块逻辑了呢？

类型	Monorepo	微服务	冲突表现
架构理念差异	倾向于将多个项目或模块集中在一个仓库管理，在一定程度上有相对集中的架构思维，代码库是统一的整体，不同部分关联性强，变更可能影响多个模块。	强调服务的独立性、自治性，每个服务有自己独立的代码库、运行环境、技术栈等，追求高内聚、低耦合，以实现快速迭代、独立部署。	Monorepo 可能使微服务之间的边界模糊，服务独立性难以保证。因为都在一个仓库，不同微服务代码容易相互依赖、牵一发而动全身，违背微服务低耦合原则，增加服务间的耦合度，使微服务架构优势难以发挥。
开发与维护效率	虽然集中管理便于工具建设、提升项目可见性，但仓库规模大，代码量大、结构复杂。新成员理解项目全貌和业务逻辑困难，学习成本高。而且修改一处代码，可能影响多个服务，测试和验证范围广，耗时费力。	每个服务相对简单，开发人员可专注特定服务功能开发维护，新成员易上手。单个服务修改、测试和部署相对独立，效率高。	在 Monorepo 管理微服务，开发过程中开发、测试和部署的效率优势可能被削弱，不同微服务开发进度和节奏受影响，开发周期变长。
技术选型灵活性	仓库内所有项目使用统一开发流程、工具链和版本控制，技术选型要考虑整体兼容性和一致性，为保证整体稳定，引入新技术、框架或工具时需谨慎评估，限制技术创新和新技术引入速度。	各服务可根据自身业务需求和特点自由选择合适技术栈，技术选型灵活，能快速响应业务变化和技术发展。	在 Monorepo 管理微服务，微服务对新技术灵活选型的优势受限，不利于微服务根据业务特性选择最优技术方案，可能导致部分服务性能、功能实现受影响。
部署和运维复杂度	由于所有服务在一个仓库，部署时需要整体考虑依赖关系、环境配置等，流程复杂。一个小改动可能需重新部署整个仓库相关服务，运维难度大，故障排查困难，定位问题耗时久。	各服务独立部署，可根据自身状态和需求灵活部署，一个服务故障不影响其他服务，运维相对简单，故障排查定位范围小。	Monorepo 的部署和运维方式与微服务独立、灵活的部署运维理念冲突，导致在 Monorepo 中部署和运维微服务时，复杂度增加，难以实现微服务快速部署、高效运维的优势。