系统架构与设计决策：模块化单体与微服务的取舍

1. 系统整体架构设计的起点与核心思路

拿到“系统架构与设计决策”这章内容的时候，我先说一个大多数刚接触架构设计的人容易忽略的点：架构不是画几张拓扑图、选几个中间件就完事，架构的本质是对一系列约束和需求的取舍。这一章之所以叫“系统架构与设计决策”，重点落在“决策”两个字上。做架构设计时，真正值钱的不是最终那张分层图，而是每一个决策背后的推演过程——为什么要这样拆、为什么不那样选、代价是什么、后续怎么演进。

我早期在某公司做一个面向多端的内容分发与管理平台时，最初团队里对架构风格的争论就非常典型。一部分人觉得微服务是现阶段的“标准答案”，按业务域拆成内容服务、用户服务、权限服务、统计服务，每个服务独立部署、独立扩缩容，前端团队按接口对接。另一部分人觉得项目初期业务不确定性太高，微服务的边界划分很容易返工，不如先做一个模块化单体，把代码边界划清楚，后续真有必要再拆。两种观点都有依据，但如果只盯着“先进”或者“稳妥”去选，迟早要吃亏。正确的做法是先拉出关键约束条件，再来决定架构的走向。

这一章的内容，本质上就是从需求出发，把“质量属性”作为第一优先级的决策依据，然后逐步推导出系统的逻辑视图、物理视图、数据架构和部署方案。如果读者是刚开始写系统设计文档，或者正在准备评审答辩，我把这一章的思路拆解成一条可执行的链路：业务需求分析 -> 关键质量属性识别 -> 架构风格选型 -> 模块与边界设计 -> 数据架构设计 -> 部署与演进规划 -> 关键决策记录。后面所有小节，我都按照这条链路展开。

基于我个人的项目经验，这里最想先纠正一个观念：做架构决策时，可扩展性不应该是永远排第一的指标。对于大部分中小规模系统，过度追求可扩展性，带来的直接后果是初期开发成本暴涨、运维复杂度上升、团队学习成本增加。这个观点在评审会上直接决定了我后来是倾向模块化单体还是微服务。所以本章的架构风格对比中，我不会给你一个“万能答案”，而是以“业务处在什么阶段”和“团队能承受什么复杂度”来帮你做选择。

2. 架构风格选型：模块化单体与微服务的对比推演

2.1 为什么一开始不直接选微服务

很多系统设计文档的第一版，架构图直接画了一堆微服务方块，每个方块之间用箭头连着，看起来很“现代”。但一问到服务划分的依据、数据一致性怎么保证、服务间调用失败怎么办，经常就答不上来。微服务最大的问题并不是技术本身，而是它把分布式系统的所有复杂性前置到了项目早期。服务发现、配置中心、熔断降级、分布式事务、链路追踪，每一样都需要专门的投入。

我当时负责的内容分发与管理平台，核心场景包括内容录入、多端发布、内容审核、数据统计。从功能上看拆成四五个服务确实“像样”，但在项目启动时业务规则还没完全确定，内容审核流程经常调整，统计口径每两周就变一次，如果强行按服务拆分，一个接口改动可能要同时改三四个服务，再加上联调和发布成本，团队会非常痛苦。模块化单体在这个阶段反而是更合适的方案：所有代码在同一个应用内，但通过模块和接口约束强制划清边界，后面真正遇到性能瓶颈或者独立部署需求时，再按模块边界拆分，成本可控，风险也可控。

2.2 模块化单体如何为后续拆分留好“后路”

模块化单体听上去是一个妥协方案，但它绝不是“把所有代码堆在一起”这么简单。它的核心价值在于模块边界的定义，以及模块之间只能通过公开接口通信的规则。我在模拟项目X中具体落地时，采用了几项硬约束：每个业务域（内容、用户、审核、统计）是一个独立的Maven/Gradle模块，模块之间禁止直接引用对方的内部类，只允许调用对方暴露的Service接口，数据库表也按业务域拆分归属，统一通过一个数据访问层访问。

这样做的直接好处是，后续从单体拆微服务时，每个模块天然就是一个候选服务，接口和数据边界已经存在，拆分的动作基本变成了“把模块搬出去、配上远程通信”的体力活，而不是重新设计。这一点我在实际项目中得到过验证：某次业务方提出需要单独扩缩容内容审核模块，因为审核操作涉及人工处理，峰值时段和普通内容管理差别很大，我们仅用了一个迭代就把审核模块从单体中拆出，部署成独立服务，其他模块完全没动。如果没有前期的边界约束，这种“说拆就拆”的场景根本不可能实现。

2.3 什么情况下微服务才是更优解

• 系统包含多个业务团队，团队之间需要独立开发、独立发布，模块化单体无法解决团队间的部署耦合。
• 某个或某几个模块对资源的需求非常不均匀，例如内容审核模块需要大量人工处理但不占用高峰CPU，而内容分发模块需要频繁的I/O和网络操作，如果不分开部署，两者的扩缩容互相牵制。
• 系统需要支持多语言、多技术栈的异构组件，单体架构无法兼容。
• 组织已经在运维层面具备成熟的容器化、监控告警、日志采集能力，微服务的部署成本可控。

我在第4章的系统文档里用了一张决策表，左边是候选架构风格，右边是质量属性评分，很多人在评审时发现这张表比画半天的架构图更有说服力，因为它把主观的“我倾向于用微服务”变成了可以讨论的“微服务在这三项属性上有优势，但在另外两项上会带来劣势”。如果你正在撰写类似的架构文档，我建议也要把质量属性评分表当成标准配套，评委和同事看到的不是你的偏好，而是你的权衡依据。

3. 关键架构决策详解：从数据一致性到部署形态

3.1 数据一致性策略的决策过程

数据架构往往是第4章的重头戏，也是容易回答不清楚的部分。再回到那个内容分发与管理平台，业务里有一个典型场景：运营人员录入一篇内容，需要同时更新内容库、索引库、缓存，并且触发审核工单的创建。如果这几个操作放在单体里，用本地事务包裹是很自然的，但一旦走到微服务架构，就得思考数据一致性到底需要强一致还是最终一致。

我当时的决策原则是：核心链路、资金或状态类变更尽量持有强一致性，非核心链路、可容忍延时的场景选最终一致。具体到这个平台，内容库和审核工单需要保证不丢失，因为内容状态错了会导致线上事故；而索引库和缓存则允许短暂不同步，因为延迟几秒对于检索和展示来说完全可以接受。于是最终方案是：内容库的写入采用数据库事务保证，审核工单通过应用内的领域事件异步创建，索引和缓存的更新通过消息队列异步消费完成。这套方案在后来的线上运行中非常稳定，几乎没有出现数据不一致导致的事故。

你可以试着复盘一下手头系统的写入链路，凡是那种一个请求里串行调了三四个系统、还要求全部同步完成的，基本都是设计上的偷懒，不是业务有多复杂。异步化配合补偿机制，才是分布式环境下最务实的做法。

3.2 缓存与消息队列的引入策略

缓存和消息队列是第4章里容易出现的两个基础设施选型。我给团队的选型原则很简单：不为了用而用，先量化问题再上组件。以内容平台的缓存为例，之前内容查询接口面对峰值压力时，数据库连接池很容易被打满。分析后发现大部分请求都在查热点内容。引入Redis做热点内容缓存之后，我会把缓存key的设计和过期策略一并写进文档，而不是只写一句“使用Redis做缓存”。

具体设计上需要注意几个点：缓存key需要包含内容版本号或时间戳，避免内容更新后命中旧数据；缓存过期时间需要业务方确认可容忍的脏数据时间窗口；缓存穿透要处理，如果内容ID不存在，我采用的方案是返回空值并短暂缓存；缓存击穿则通过热点内容主动刷新或互斥更新来避免。这些细节如果不写进架构文档，后续开发同学在实现时会各行其是，这也是很多系统上了缓存之后反而出现更多问题的原因。

关于消息队列，我当时做过一个简单的容量预估：某活动期间，内容审核工单的创建峰值约为每秒800单，消费端平均处理单耗时约80毫秒。用公式换算一下，要稳定支撑这个峰值，消费端至少需要800乘以0.08约等于64，也就是至少64个处理线程。这个数值转换为消费者实例数，大概需要8到10个实例。这些计算逻辑我全都写进了设计文档，因为它能把“消息队列够不够用”这种笼统的问题，变成“需要部署几个消费者实例”这种可验证的结论。

3.3 部署形态与资源规划的权衡

部署形态的决策也与系统所处的阶段强相关。模拟项目X最早期的部署是一个单体应用加一个数据库，都跑在虚拟机上，通过进程守护和定时备份保障可用性。进入快速增长期后，我们引入了容器化部署，每个模块可以独立扩容，测试、预发布、生产环境完全隔离，发布流程也从手工脚本逐步演进为流水线自动构建、自动部署、自动回滚。这一段的演进路径，我在文档里以“部署形态的演进过程”单独开了一节，重点强调任何部署方案都不是一步到位，而是随着系统规模和团队能力逐步演化的。

容量估算上，我的经验公式是先抓两个数：核心链路峰值QPS，以及单次请求平均响应时间。通过排队论公式可以粗估所需实例数：一般而言，如果系统要支持每秒1000个请求、单实例能承受每秒200个请求，那么至少需要5个实例，再考虑到发布期间需要摘除部分实例，实际应该预留1到2个备用实例，最终建议部署7个。这套估算方法我在文档中写成了计算示例，评审时反馈也很好，因为不是拍脑袋定的数量。

4. 结构化梳理：用架构视图描述系统的多角度形态

4.1 逻辑视图与物理视图的匹配

初写架构文档的人，经常把逻辑视图和物理视图混在一起：画了个微服务部署图，然后在里面标“订单模块”“用户模块”，结果逻辑边界和物理边界交叉重叠，别人根本看不出来你在讲哪一层面的事。第4章的正确写法是分开描述：逻辑视图表达系统的“职责划分”，物理视图表达系统的“运行分布”。

• 逻辑视图：系统包含哪些业务域，每个业务域提供哪些核心能力，业务域之间通过哪些接口交互。例如内容域提供内容读写接口，审核域提供审核任务创建与处理接口，两者通过领域事件实现解耦。
• 物理视图：组件分别部署在哪里，如何通信，如何扩缩容。例如API服务、后台任务服务、Web管理端，各需要多少实例，通过负载均衡接入，依赖哪些中间件集群。
• 数据视图：数据如何分布、如何流转、如何处理一致性。例如内容库数据与审核数据的隔离，缓存数据与持久化数据的一致性。
• 部署视图：环境划分（开发、测试、预发布、生产）、容器与资源分配、网络策略、监控部署。

4.2 从业务读路径和写路径反推架构

我在设计文档时还有一个习惯，就是从“核心业务场景的读路径和写路径”反推架构，确保每个环节的设计都有业务支撑。以内容分发平台为例，我对标了一个写路径和两个读路径：运营人员创建并发布内容的写路径，以及前端用户查看内容列表的内容读路径、管理员查看审核任务的审核读路径。

写路径上，内容表插入记录后，审核工单异步创建，内容更新时间写入消息队列，索引模块与缓存模块消费更新。这里能看出系统的关键基础设施依赖哪些组件：MySQL负责数据持久化，Redis提供热点缓存，消息队列实现异步和解耦。读路径上，内容列表接口先查Redis，缓存未命中就回源MySQL，并且通过索引服务进行检索。这里可以验证缓存、索引、数据库三者在设计上是否真正达到预期。如果文档能把这两条链路的每一步与对应组件对应起来，整个系统的逻辑就非常清晰了，评审时也不用反复解释。

5. 常见架构设计问题与排查纠偏实录

5.1 架构评审阶段最高频的三个争议点

结合我参与过的评审和答辩经验，第4章的内容最容易在三个问题上被反复追问：事务到底是强一致还是最终一致？消息丢失了怎么办？服务拆分后谁对数据负责？

这三个问题如果文档里没有明确答案，评审基本过不去。我的处理方法是把结论前置，给出决策记录表，具体格式可以是：

我在项目文档中随附了一张类似的决策记录表，每周小组讨论时可以对照表格检查每条决策是否依然成立，而不是让架构决策流于形式，最后谁都不记得当初为什么这么定。

5.2 上线后最容易翻车的三个现实问题

• 第一个典型问题是缓存穿透。某个内容ID被恶意构造，不断请求不存在的内容，请求全部穿透到数据库，导致数据库压力骤增。排查发现缓存层对这类请求没有设防。当时用布隆过滤器加缓存空值双重方案补救，流程是：先用布隆过滤器拦截一定比例的不存在ID，剩下的走缓存；如果缓存没有且数据不存在，则将空值缓存短时间，防止同一批恶意请求持续打库。
• 第二个典型问题是消息堆积。某次业务方导入大量历史数据，触发审核工单批量创建，消息队列消费能力跟不上，延迟一度飙到十几分钟。排查发现消费逻辑里有一个串行的外部接口调用，单个消息耗时过长。优化路径是把外部接口调用改为批量获取、本地缓存，同时增加消费者实例，最终把积压时间降到了秒级。这个问题的根源，是系统设计时没有对单条消息处理耗时做压测，属于常见的设计遗漏。
• 第三个典型问题是数据库连接池被打满。之前的缓存和索引改造虽然有效，但运营后台有大量复杂筛选查询，这些没有经过缓存，直接落到数据库。排查发现不少慢SQL没有走索引，而开发阶段数据量小，问题没有被提前暴露。最终通过优化SQL、增加必要索引、把部分复杂统计查询转为异步预计算来解决。这个问题想说明一个道理：很多架构问题是数据量增长到一定程度后才暴露出来，所以架构文档里的容量预估和数据量增长预期千万不能省。

5.3 架构评审时回答“为什么不用XX技术”的模板化方法

评审答辩中经常会被问“为什么不用XX技术”，如果这个问题回答不好，容易让人觉得你选型拍脑袋。我的回答套路分三步。第一步，承认对方方案的价值，比如“XX技术确实在容器编排上有优势”。第二步，说明评估结论，比如“我们评估后认为现阶段团队对XX技术的运维经验不足，且系统当前的规模和演进速度，不需要引入它，使用模块化单体加上容器化部署已经能覆盖需求”。第三步，给出切换条件，比如“如果后续微服务数量超过8个、需要跨团队独立发布时，我们可以再用XX技术来承载，迁移路径是按照之前定义好的模块边界逐步拆分”。

这种回答把技术选型变成了一组有前提条件的决策，评审方自然容易接受。同时也提醒读者，架构文档的选型部分、决策记录部分都要尽量包含三者：评估了什么、为什么这样选、什么条件下会切换。

6. 系统架构与设计决策的演进路线图

6.1 架构设计不是一锤定音，需要持续演进

第4章的内容还承担着“系统演进蓝图”的作用。我写文档时一定会单独留一小节“架构演进路线图”，因为业务一定会变，技术栈一定会变，容量一定会增长，如果不给出演进预期，架构文档很快会过时。实际工作中很多系统的问题，恰恰是早期设计缺少演进规划，等规模涨上去了才发现各种历史包袱难以收拾，最后被迫“推倒重来”。

我通常会按时间轴规划三阶段：第一阶段是当前阶段的稳定版本，以单体应用加集中式数据库为主，满足业务快速迭代；第二阶段是腾飞起步阶段，将热点分析、异步处理模块引入，在稳定运行的前提下开始暴露并缓解性能压力；第三阶段是全面演进阶段，将业务域模块拆分为独立服务，配合分布式中间件，逐步过渡到微服务架构。每一阶段都会注明要达到的目标、引入的组件、和需要关注的风险。这种路线图不需要精确到具体时间，但需要让读者或评审者知道，系统不是停在设计图上，它会继续往前走。

6.2 文档的版本管理与评审记录

一个常被忽视的细节是，第4章的架构文档必须是有版本、有评审记录的活文档，而不是写完之后固定不变的静态PPT。我在实践中会在文档开头维护一张变更记录表，记录每次架构调整的日期、版本、变化点、决策背景和评审结论。这样做的好处是，几个月后有人在代码里看到某个看似奇怪的设计决定，可以顺着文档追回去，找到当时的原因，而不是靠老员工口口相传。多个项目经验表明，这种“可追溯性”比任何代码注释都更能帮助团队理解系统为什么长这样。

关于评审记录，还需要注意一点：评审提出的不同意见和最终采纳结果，要一并记录。我在一个项目里经历过一次非常有意义的技术争论，争论双方分别坚持模块化单体和微服务方向，最终评审结论是先做模块化单体、约定好接口边界、半年后根据系统规模再评估拆分。这次讨论以及最终决策，被完整地记录在第4章的决策附录中，后来新加入团队的同事读文档时，能很快理解系统为何使用现在的架构，而不会简单判定“当初我肯定会选微服务”。

7. 架构文档如何设计得清晰且让人愿意看下去

7.1 先画主干再填细节的写作顺序

很多架构文档读起来艰难，问题往往在于作者把各种细节不分主次地全部倒给读者。我在写这一章时，对于文档顺序做了三个“优先”：优先讲业务目标和质量指标，再讲架构风格和模块划分；优先讲核心业务链路和关键依赖，再讲辅助服务和可选中间件；优先讲风险识别和演进方向，再讲具体的配置参数和部署细节。以此为顺序展开，读者读完前两页已经知道系统大致长什么样、为什么这样设计，后续的一切内容都成了对前面结论的补充证明。

对于初学者，我强烈建议在正式写作前先用一张朴素但完整的图表达“用户请求从进入到返回的全部路径”，然后把沿途经过的模块、中间件、数据存储都标注出来。这张图的价值在评审时会被无限放大——它能快速让听众建立整体的直观感知，效果远好于堆满各种箭头和模块的复杂架构图。

7.2 有效数据和案例的运用

架构文档最怕“描述性语言”过多，缺少数据和案例支撑。比如“系统使用Redis提升性能”，不如写成“根据线上监控，内容查询接口在缓存命中率为92%的情况下，P99响应时间从850毫秒降低到120毫秒，数据库连接池使用率从75%下降到30%”。这个写法很容易让评审者建立起对方案的信任。

同样的原则也适用于比较分析。文档里比较模块化单体和微服务时，不要只说“微服务太复杂”，而是列出当前系统规模：团队6人、日请求峰值约500万、核心接口20多个，然后说明在这个规模下微服务会带来哪些额外成本，模块化单体足以支撑，并给出当团队人数增加到多少、日请求峰值达到多少时需要考虑切换到微服务。这才是真正的“设计决策”，它以事实和数据为判断依据，而不是仅凭个人偏好。

7.3 附录的价值：决策记录、术语表和指标定义

我把第4章后面安排了一组附录，这些附录在实际工作中被很多团队视为“小宝藏”。决策记录表汇总了所有重要选型的背景、候选方案、选定方案、反对意见、切换条件和最终结论。术语表按字母排序解释了文档中出现的技术名词，降低读者的理解成本。指标定义表则明确描述监控指标的计算方式、收集方式、告警阈值和衡量口径。比如P99、QPS、缓存命中率、消费积压量等，在团队讨论中这些都是高频词汇，如果没有统一定义，评审会上很容易出现各说各话的情况。

如果你接下来要写类似第4章的内容，哪怕是规模不大、技术不复杂的系统设计，我也建议把这三类附录加上。它们不需要很多篇幅，但对于提升文档长期使用价值非常明显。这份文档不是给别人一次性的评级和观赏用的，而是给后续接手的团队留下可依赖的参考。

8. 从本章内容延伸到整个设计文档体系

8.1 与前后章节的衔接方式

系统设计文档不是孤立的一张架构图，第4章的内容和前面需求章节、后面的详细设计章节都要能对得上。我在文档里做了一件简单却很受用的事情：在前面的需求章节描述了5个核心业务场景，在第4章的架构设计里，我会用表格把每个核心场景与对应的架构模块、数据存储、中间件、关键接口一一对齐。这样前后章节不再是各写各的，而是一条业务需求自上而下贯穿到技术实现的主线。

详细设计章节在第4章之后通常会描述模块内部的类设计、接口定义、数据结构等，为了保证节奏顺畅，我会在第4章明确指出哪些是系统级的决策、哪些是模块级的决策。例如“使用Redis作为缓存层”属于系统级决策，“内容列表接口的缓存key格式如何设计”属于模块级决策。这种分层方式能够避免架构文档的边界无限膨胀，也让模块级设计的责任落在对应的模块owner身上。

8.2 决策评审时讲故事的技巧

把第4章讲清楚，不能只靠“读文档”。评审会上如果有机会现场演示系统的核心链路，少讲概念，多讲一个完整的业务故事。例如，我当时会用一段故事描述运营人员如何创建一篇文章、保存后如何触发审核、审核通过后如何上架、上架后用户如何看到最新的内容，同时这个故事里穿插说明每个环节背后依赖了什么组件、用到了什么设计决策、失败时如何兜底。这样听众感受到的不是抽象架构，而是一个能跑通、能思考的系统。

我在评审会上常用类似这样的引导：一开始讲“我们模拟了一次流量尖峰”，接着描述监控指标的变化，然后讲述我们如何定位瓶颈、优化方案、最终效果如何。这种案例比任何“我们的架构很棒”的表述都有说服力。这也符合第4章标题中的“设计决策”——它本就应该是真实问题和真实应对的记录，而不是停留在教科书上的装饰图。

8.3 优秀架构师的隐含能力：平衡短期与长期

写第4章需要一个综合平衡的能力：既要知道当前系统的短期业务目标，又要能看清未来三到五年的演进方向。过度设计会拖累团队，抛弃设计则会在规模来临时无从应对。我在每一次架构选型时都提醒自己，架构真正服务于业务价值，而不是服务于某种技术理想。因此，本章所有内容都应围绕“决策的可解释性”来展开，这也是为什么我一直在强调决策记录表、量化指标、演进阶段这三个核心工具。

如果你在实践过程中发现自己不知道该怎么填决策记录表，可以先从最容易的一行开始，比如“内容列表是否启用缓存”这一条，然后逐步补全到其他更复杂的选型。每次只推进一点，逐步建立起一套能够长期可复用的架构决策体系，这种积累通常在半年后就会体现出明显优势。真正熟练之后，你会发现自己做架构决策的时间越来越短，体系化思考的能力越来越强。