从 Monolith 到 Microservices 之间：解读 Modular Architectures 的 10 条原则
最近看到 TechLeads.club 开源的仓库 https://github.com/tech-leads-club/modular-architectures-principles，它尝试回答一个非常现实的问题：团队到底应该坚持 Monolith，还是尽快拆到 Microservices？
这个项目给出的答案并不是二选一，而是提出了一个中间地带：Modular Architectures。它强调系统演进要可逆、可观察、可治理，而不是一开始就把组织和技术锁死在某个架构形态里。
1. 这个项目在解决什么问题
软件架构里最难的决策之一，是“粒度（granularity）”到底切多细。切得太粗，团队会被单体系统的耦合拖慢；切得太细，又会被分布式系统的治理成本反噬。
仓库引用了 Google 团队在 HotOS 2023 的研究观点：很多团队在采用 Microservices 后，真实感受不是“更快”，而是“更难看清系统全貌、更难改动跨服务需求”。这类问题通常体现在几个方面：
- 跨服务调用与序列化造成性能损耗。
- 多版本并存导致行为难以预测。
- 服务数量增长后，构建、测试、发布、运维链路整体变重。
- API 一旦外发，演进速度明显下降。
- 涉及多个服务的需求很难原子化交付。
如果把这些现象抽象一下，可以把系统复杂度理解为：
在 Cloud Native 场景里，后半部分往往增长更快。
2. 核心思想：把“逻辑边界”和“物理边界”拆开决策
Modular Architectures 的关键主张是：
- 逻辑边界（模块划分）是代码设计问题。
- 物理边界（部署单元）是运维与组织问题。
这两个问题不应该在项目早期被一次性绑定。也就是说，先把模块边界设计清楚，再根据业务增长决定是否独立部署，而不是“因为要上微服务，所以先把所有边界都物理切开”。
这种方式的好处，是把架构从“不可逆选择题”变成“可渐进的连续决策”。
3. 10 条原则可以怎么理解
该白皮书把原则分成 4 组，共 10 条。按 IT 团队落地视角看，可以理解为“先约束结构，再约束协作，再约束发布，最后约束稳定性”。
| 分类 | 原则 | 运营视角下的解释 |
|---|---|---|
| 结构 | Well-Defined Boundaries | 每个模块职责明确，避免“共享内部实现” |
| 结构 | Composability | 模块像积木，能被不同 App 复用组合 |
| 结构 | Independence | 模块间通过契约通信，避免隐式依赖 |
| 运行 | State Isolation | 数据边界清晰，模块不直接读写彼此状态 |
| 运行 | Explicit Communication | API、事件、DTO 契约化，便于版本管理 |
| 运行 | Replaceability | 模块可替换，降低技术选型锁定成本 |
| 部署 | Deployment Independence | 只发布受影响的 App，减少变更爆炸半径 |
| 部署 | Individual Scale | 热点能力单独扩缩容，控制资源成本 |
| 韧性 | Observability | 观测按模块归属，故障定位更快 |
| 韧性 | Fail Independence | 单点故障可隔离，系统可降级而非整体失效 |
这套原则并不新奇，但价值在于“成体系且可操作”，尤其适合正在经历组织扩张、业务增线、团队并行开发的阶段。
4. 推荐的演进路径
仓库给出的路径是渐进式四阶段：
Modular Monolith：一个部署单元，先把模块边界定清楚。- Clear Boundaries：强化边界治理，建设按模块的日志、指标、告警。
- Dedicated Apps：把高变化、高流量或高风险模块拆成独立
App。 - Selective Microservices：仅在确有必要时，进一步拆成独立服务。
这里最值得借鉴的一点，是“按证据演进”：
- 先有业务信号，再做边界调整。
- 先做可观测性，再做复杂拆分。
- 先验证收益，再引入额外治理成本。
5. 对团队管理与协作的启发
从 IT 运营和技术管理的角度，这套框架最实用的价值在于治理清晰：
- 责任边界更清楚：模块天然对应 owner 和告警路由。
- 变更影响更可控：通过依赖图可以提前评估影响面。
- 发布节奏更灵活：业务线可以按自身节奏演进，而不是“全站同频”。
但它并不适合所有团队。如果你是 1 到 3 人的小团队，业务也很简单，直接维护一个清爽的 Monolith 往往更高效。架构的目标应是提升交付速度，而不是追求“看起来高级”的形态。
6. 30 天落地检查清单
如果你想在现有项目里试行这套思路，可以从一个月的轻量改造开始：
- 第 1 周：画出当前模块依赖图，识别跨域直接调用。
- 第 2 周：定义模块公共契约（API / Event / DTO）与禁止依赖规则。
- 第 3 周：建立按模块的日志标签、指标面板和告警分派。
- 第 4 周：选择一个高频变更模块，尝试提升为独立
App并验证收益。
建议你把成功标准写成可量化指标，例如：
- 需求 lead time 是否缩短。
- 跨团队协作等待时间是否下降。
- 故障定位平均时长是否改善。
没有度量，就很难判断“模块化”到底是在帮忙，还是只是在重命名复杂度。
7. 源地址与延伸阅读
- 项目仓库：https://github.com/tech-leads-club/modular-architectures-principles
- 英文白皮书：https://raw.githubusercontent.com/tech-leads-club/modular-architectures-principles/main/whitepaper-en.md
- 在线版白皮书：https://modular-architectures.com/whitepaper.html
- 相关研究（HotOS 2023）：https://doi.org/10.1145/3593856.3595909
如果你正在做架构升级，这个项目最值得参考的不是“是否要上微服务”，而是它提供了一种更务实的决策顺序：先治理边界，再治理部署，最后治理规模。