在落地微服务架构时，源代码的组织方式往往是个绕不开的难题。
由于每个微服务相对独立，最直观的方案是'多仓'模式，即每个微服务独占一个仓库。这种做法的好处很明显，就是从源头开始对微服务进行隔离，每个服务拥有各自独立的持续集成和部署流程。
然而，这种模式会带来比较大的管理开销，尤其是当微服务之间存在共享代码的情况。共享代码在很多场景下是无法避免的，比如通用的工具类库或配置中心客户端。一旦共享代码发生变更，所有引用它的微服务都可能需要同步修改。如何确保这些改动在多个仓库间保持同步，往往是一个棘手的运维问题。
对于中小规模的微服务应用来说，采用'单仓'（Monorepo）策略通常更务实。单一代码库能方便地管理共享代码。当需要对公共部分进行修改时，相关的改动以及对受影响微服务的调整，都可以在同一个提交（commit）中完成，这非常有利于追踪变更链路。当然，单仓也有弊端，比如构建时可能会触发不相关微服务的编译和部署，增加资源消耗。
在实际项目中，我们常利用 Maven 的多模块特性来落地这一策略。最简单的组织方式是将共享代码和业务微服务组织成 Maven 中的多个模块。典型的结构是将公共模块置于同级目录下，例如 common-lib 存放通用工具，service-a 和 service-b 分别对应不同业务，所有模块以扁平化的方式挂载在父工程下，既保持了逻辑上的独立性，又实现了物理上的统一管控。
