Day31-12｜10.6.1 大型网站系统架构演化实例（一）：单体架构阶段的取舍与边界

一、教材定位

第 10.6 节通过大型网站的架构演化实例，展示系统如何从简单结构逐步应对用户增长、流量波动、数据规模和业务复杂度。10.6.1 讨论第一阶段的单体架构。单体并不是天然落后或错误的架构，在业务早期、团队规模较小、需求变化快且系统规模有限时，单体能够以较低成本快速验证业务。但随着压力和复杂度增长，单体结构也会暴露出扩展、发布、故障隔离和团队协作问题。

考试不会只问“单体架构的优缺点”，更可能要求分析某阶段为什么采用单体、单体遇到什么瓶颈、哪些问题属于架构问题、下一步如何演化。回答必须体现阶段性和权衡：早期选择单体可能是合理的，关键在于是否建立边界、监控和演化出口，而不是事后用微服务标准否定早期方案。

二、典型大型网站的早期背景

假设一个网站刚开始提供用户注册、内容浏览、搜索、下单和后台管理。用户量较小，业务规则仍在快速变化，团队只有少量开发人员，部署环境也比较简单。此时系统通常采用单体应用、单一数据库和统一部署包，所有模块运行在一个进程或少量实例中。

典型结构可以概括为：浏览器或移动端通过网关进入应用，应用内部包含用户、内容、搜索、订单、支付和后台模块，所有模块共享数据库，文件和日志也集中存储。模块之间主要通过函数调用协作，事务由同一个数据库管理。部署时构建一个应用包，启动若干相同实例即可。

三、单体架构的结构特点

1. 功能集中

多个业务模块在一个部署单元中运行，调用路径短，内部通信不需要网络协议。团队可以快速修改和联调，适合需求尚未稳定的探索阶段。

2. 数据集中

单一数据库便于事务、查询、报表和数据分析。开发人员可以直接使用统一的数据模型，跨模块业务流程容易实现。

3. 统一发布

所有模块通常共享版本和发布流程。一次构建就能部署完整系统，环境配置和监控相对简单。小团队容易建立共同的开发和运维习惯。

4. 共享资源

应用实例共享内存、线程池和连接池，数据库共享 CPU、内存、连接和锁资源。共享降低了早期成本，但也使不同模块之间容易相互影响。

四、单体架构的优势

1. 交付速度快

模块之间直接调用，开发、调试和测试链路短。业务试错阶段可以快速验证产品假设，不必先建立复杂的服务治理和分布式基础设施。

2. 事务和一致性简单

跨模块操作可以依靠本地事务，失败时统一回滚。对早期订单、库存和支付等流程，集中事务减少了分布式一致性设计成本。

3. 运维成本低

部署单元少，服务发现、消息治理、链路追踪和版本兼容相对简单。小规模系统不需要为每个模块维护独立流水线和值班体系。

4. 便于全局重构

需求变化尚未稳定时，统一代码库和数据模型便于快速调整边界。若一开始就过度拆分，反而可能把不稳定的业务边界固化为服务接口。

五、单体架构的局限

1. 扩展粒度粗

如果只有搜索模块流量增长，也往往需要扩展整个应用实例。不同模块的资源需求不一致，造成资源浪费；某个模块达到瓶颈时，整体扩容成本较高。

2. 发布相互阻塞

任何模块修改都可能触发完整构建、回归和发布。随着代码和团队增长，发布窗口变长，低风险变化也要等待高风险模块一起验证。

3. 故障影响范围大

内存泄漏、线程池耗尽、慢查询或异常循环可能影响同一实例中的所有模块。即使多个实例部署，错误版本和共享数据库仍可能造成全局影响。

4. 模块边界逐渐模糊

为了方便，模块可能直接访问他人表、调用内部类和共享公共对象。时间久了形成循环依赖和隐式契约，后续拆分困难。

5. 技术栈和团队协作受限

所有模块通常共享语言、框架和发布节奏。不同团队无法独立选择适合的技术，也难以按照业务边界独立交付和值班。

6. 质量属性难以局部优化

搜索可能需要高吞吐和缓存，订单需要强一致和审计，后台报表需要大批量查询。单体共享运行环境和数据库，使不同质量目标互相竞争。

六、单体阶段必须建立的架构边界

单体不等于无结构。即使部署为一个应用，也应按业务能力划分模块，明确依赖方向和数据访问边界。订单模块不应直接修改库存内部表，搜索模块不应依赖订单内部对象，公共模块不能成为所有业务规则的垃圾场。

可以采用分层、模块化、包边界、接口、领域对象和访问权限建立“逻辑上的服务边界”。代码仓库中设置依赖检查，数据库使用不同的访问账号或视图，模块间通过稳定接口协作。这样未来即使不拆分，也能降低维护成本；若需要拆分，也有较好的迁移基础。

七、单体阶段的性能与可靠性设计

1. 缓存和静态资源

将热点内容、会话和配置合理缓存，静态资源使用独立存储或分发。但缓存必须明确失效、一致性和热点保护，不能把数据库问题简单转移为缓存问题。

2. 数据库优化

通过索引、查询优化、读写分离、连接池和归档控制数据库压力。慢查询和锁等待要纳入监控，避免一个报表任务拖垮核心事务。

3. 资源隔离

为不同模块设置线程池、连接池、队列和超时，避免共享资源被单个功能耗尽。对非核心功能设置限流、降级和熔断，保护核心路径。

4. 发布与回滚

建立自动化构建、配置基线、灰度、健康检查和快速回滚。数据库变更采用兼容顺序，避免代码和结构同时不可逆变化。单体也需要可观测性和故障演练。

八、单体架构的演化触发信号

是否需要从单体向下一阶段演化，可以观察以下信号：核心模块发布被非核心模块阻塞；某类流量独占资源；故障经常跨模块传播；团队无法独立交付；数据库读写冲突和热点持续增加；测试时间超过迭代周期；新旧代码边界不清；扩容只能整体进行；安全和合规要求需要不同隔离级别。

这些信号不意味着必须立即全面微服务化。可以先进行模块化、读写分离、缓存、反向代理、静态资源分离、异步任务、独立搜索和资源隔离。演化路径应根据问题根因和风险选择。

九、案例分析：从早期电商单体开始

某电商创业团队最初采用单体应用，包含用户、商品、购物车、订单、库存、支付和后台。第一年用户量不大，团队用一个数据库完成交易，需求每周变化。单体帮助团队快速验证商品和订单流程，整体架构是合理的。

第二年开始出现问题：商品搜索占用数据库资源，促销活动导致缓存击穿，订单发布需要等待后台报表验证，支付异常会拖慢订单线程池。团队如果直接重写为几十个微服务，可能把不稳定的业务边界和数据模型分散到多个系统，增加一致性和运维成本。

更稳妥的演化是先在单体内部建立模块边界，分离静态资源和搜索读模型，给搜索和报表设置独立资源，异步处理通知和批任务；同时建立订单、库存和支付之间的接口和事件契约，补充幂等、对账和链路追踪。经过一段时间运行后，再根据变化频率和故障隔离需求选择优先拆分的模块。这样既利用了单体早期的简单性，又为后续演化建立了出口。

十、综合知识练习

题1

单体架构是否一定是不合理的？

参考答案：不一定。在业务和团队规模较小、需求变化快、事务关系集中时，单体可以降低交付和运维成本。关键是保持逻辑模块边界、可观测性和演化出口，并根据规模、质量和组织变化及时调整。

题2

单体架构遇到瓶颈时，为什么不一定要立即全面微服务化？

参考答案：瓶颈可能来自数据库、缓存、资源共享、模块边界或某个热点功能，全面拆分会引入网络、分布式事务、消息和运维复杂度。应先定位根因，通过模块化、资源隔离、读写分离和异步化等低风险措施，再按价值和风险渐进拆分。

题3

单体阶段如何为后续演化做准备？

参考答案：建立业务模块和依赖边界，明确数据所有权，禁止跨模块直接修改内部数据，使用稳定接口，隔离资源和线程池，建立日志、指标、链路、自动化测试、发布回滚和架构决策记录。

十一、论文写作素材

论文中可以这样描述单体阶段：

“系统早期业务和团队规模较小、需求变化频繁，我选择结构清晰的模块化单体，以降低分布式通信、事务和运维成本。随着用户和数据增长，出现搜索流量影响交易、模块发布相互阻塞和共享数据库热点等问题。我没有直接进行大规模重写，而是先建立模块边界、资源隔离、读写分离、缓存、异步任务和可观测性，并为订单、库存和支付定义接口、幂等和对账机制。通过发布周期、核心成功率、数据库热点和故障影响范围识别后续拆分边界，逐步演化架构。”

十二、今日复盘

单体架构适合早期快速验证，但不等于无边界和无治理。
单体优势在于交付快、事务简单、运维成本低和便于早期重构。
规模增长后会出现扩展粒度粗、发布阻塞、故障传播和团队协作问题。
单体阶段也应建立模块、接口、数据、资源和质量边界。
演化触发应来自业务、规模、质量和组织信号，而不是技术潮流。
案例答题要体现“阶段合理、问题出现、先治理再拆分”的渐进思路。