1 基本概念
1.1 定义
单体架构是一种将应用的主要功能集中在同一代码库、同一部署单元或同一运行进程中的软件架构模式。通常，用户界面、业务规则、数据访问以及公共能力都会被统一组织并打包发布，对外表现为一个整体系统。
这种架构并不意味着内部完全没有分层或模块划分。相反，很多单体系统内部也会采用清晰的包结构、分层设计和接口抽象，只是在部署与运行层面保持统一，从而让系统具备较强的一体化特征。
1.2 核心特征
单体架构的核心在于“集中式”与“整体性”。系统各部分虽然可以在逻辑上拆分，但在工程交付时通常作为一个整体存在。其常见特点包括共享同一运行环境、统一发布流程，以及较直接的调用链路。
1.2.1 单一部署单元
单体系统一般以一个应用包、一个可执行文件或一个服务实例的形式部署。无论内部包含多少功能模块，它们通常都不能独立上线或独立回滚，而是需要随整体一起发布。
1.2.2 共享运行环境
系统中的各个模块往往运行在同一进程或同一运行容器中，共享内存、线程池、数据库连接等基础资源。这种方式便于模块间直接调用，也使资源管理更为集中。
1.2.3 集中式代码管理
单体架构通常对应一个统一代码仓库，或者至少在工程组织上具有较强的一体化特征。代码变更、构建脚本、测试配置和发布流程通常集中维护，便于统一控制版本与依赖。
1.3 常见误区
由于单体架构的概念较直观，实践中容易与一些相近术语混淆。实际上，是否“单体”主要看部署与运行方式，而不只是看系统规模或代码文件数量。
1.3.1 与“简单系统”的区别
简单系统不一定是单体架构。一个系统即便功能很少，也可能被拆成多个独立服务；反过来，一个业务复杂的企业级系统，也可能仍然采用单体架构。两者的区别重点不在复杂度，而在组织和部署方式。
1.3.2 与“单模块应用”的区别
单模块应用是指代码组织上几乎只有一个功能模块，常见于工具类程序或早期原型。单体架构则可以包含多个逻辑模块，只是这些模块在发布与运行时被统一封装，因此二者不能简单等同。
2 架构组成
单体架构内部通常仍可划分为若干典型层次，以便控制复杂度并提升可维护性。常见组成包括表现层、业务逻辑层、数据访问层以及一些公共组件。
2.1 表现层
表现层负责接收外部请求并返回响应，常见形式包括网页界面、接口控制器或命令入口。它通常承担参数校验、请求分发和结果包装等职责，尽量避免直接处理复杂业务规则。
2.2 业务逻辑层
业务逻辑层是系统的核心，负责实现具体的业务流程、规则判断和状态流转。该层通常会调用数据访问层和公共工具，并尽量将复杂逻辑从界面与存储细节中分离出来。
2.3 数据访问层
数据访问层用于屏蔽底层存储细节，负责数据库读写、查询封装和持久化操作。通过这一层，可以减少上层对具体数据库语句、表结构或存储机制的直接依赖。
2.4 公共组件与工具库
公共组件与工具库用于承载多个模块都会使用的基础能力，例如日期处理、字符串操作、权限校验或消息封装等。它们能够减少重复实现，但也需要避免演变为“万能工具箱”而造成结构混乱。
2.4.1 日志与配置管理
日志系统用于记录运行状态、错误信息和关键操作痕迹，便于排查问题。配置管理则负责统一维护环境变量、数据库连接信息、功能开关等内容，以支持不同环境下的稳定运行。
2.4.2 异常处理机制
统一的异常处理机制可以将系统内部错误转化为可控的输出形式，避免底层异常直接暴露给调用方。它也有助于集中记录错误信息、分类处理问题并保持接口返回的一致性。
3 设计原则
单体架构虽然整体统一，但仍需要良好的内部设计来控制复杂度。合理的分层、清晰的边界和统一规范，往往决定了单体系统是否能够长期维护。
3.1 分层思想
分层思想强调按照职责将系统拆分为表现、业务、数据等不同层次。各层之间尽量通过明确接口交互，减少跨层直接调用，从而提升可读性与可测试性。
3.2 模块内聚
模块内聚指一个模块内部的功能应尽量围绕同一业务目标组织。高内聚的模块更容易理解、修改和复用，也有助于减少无关代码混入同一文件或同一包中。
3.3 低耦合目标
低耦合要求模块之间尽量减少相互依赖，避免一个模块的变更频繁影响其他部分。在单体系统中，虽然代码位于同一工程内，但仍应通过接口、抽象和边界划分来降低联动风险。
3.4 统一接口规范
统一接口规范有助于让系统内部调用方式、命名方式和返回格式保持一致。无论是内部方法、服务接口还是对外 API，统一规则都能减少理解成本，提升协作效率。
4 开发与部署
单体架构在开发和交付方面通常较为直接。由于系统以整体形式存在，开发、构建、测试和发布流程往往可以围绕统一工程展开。
4.1 本地开发流程
本地开发时，开发者通常只需拉取一个主工程即可运行大部分功能。配合本地数据库、模拟数据和调试工具，便可完成接口联调、页面验证和功能排查。
4.2 持续集成与测试
在持续集成流程中，单体系统通常会在代码提交后执行统一构建、自动化测试和静态检查。由于整体依赖关系明确，测试环境的搭建相对直接，但回归测试范围可能较广。
4.3 打包方式
单体应用常见的打包方式包括生成可执行包、Web 应用归档文件或容器镜像等。打包时会将编译产物、依赖库、静态资源和配置模板一并整理，形成可部署交付物。
4.4 部署模式
单体系统的部署一般采用整体发布，即一次将完整应用上线到目标环境。根据基础设施不同，部署方式可以较传统，也可以结合容器技术实现更标准化的交付。
4.4.1 传统服务器部署
传统部署通常将应用直接安装或拷贝到物理机、虚拟机或应用服务器上运行。该方式流程清晰、便于理解，但环境差异和手工操作较多时，管理成本可能上升。
4.4.2 容器化部署
容器化部署会将单体应用及其依赖打包进容器镜像，以便在不同环境中保持较一致的运行条件。这种方式有利于环境隔离和快速交付，也便于进行横向扩容与版本管理。
5 优点
单体架构在许多场景下仍然广泛使用，主要原因在于它具有较低的复杂度和较强的工程可控性。对于需求边界稳定或团队规模有限的项目，这些优点尤为明显。
5.1 架构简单
单体系统的技术结构通常较容易理解，不需要处理大量分布式通信、服务发现或跨服务事务问题。对团队而言，学习和上手成本相对较低。
5.2 开发效率高
在早期阶段，开发者可以围绕一个统一工程快速实现功能、联调接口并完成发布。由于模块间调用通常是进程内调用，开发流程较少受到额外基础设施的制约。
5.3 调试与排障方便
单体应用的运行链路相对集中，问题定位往往较直接。开发人员可以在同一进程中查看日志、跟踪调用栈或使用调试器，较容易发现错误来源。
5.4 性能损耗较低
由于内部模块通常通过函数调用或进程内对象交互完成协作，通信开销较小，延迟也相对可控。这使得单体架构在一些对实时性敏感但规模不大的系统中表现稳定。
6 局限性
随着业务增长，单体架构的优势可能逐渐被复杂度放大所抵消。尤其当团队协作变多、功能持续堆叠时，一些结构性问题会更明显。
6.1 扩展能力受限
单体系统通常只能按整体进行扩展，难以对热点功能单独扩容。如果某一局部模块负载升高，往往需要连同其他模块一起复制运行，资源利用效率可能不够理想。
6.2 代码库规模膨胀
当业务不断叠加后，代码库容易变得庞大而难以维护。模块边界若不清晰，开发者可能难以快速定位相关代码，进而影响迭代速度和协作质量。
6.3 发布耦合度高
在单体架构中，任何一处较大的修改都可能要求整体重新构建和发布。若系统模块较多，发布前的验证范围也会随之扩大，增加上线风险。
6.4 技术栈升级成本较大
由于各模块共享同一工程与运行环境，底层框架、语言版本或依赖库的升级往往牵一发而动全身。对于历史较长的系统而言，这类升级的测试与兼容成本会明显增加。
7 适用场景
单体架构并非过时方案，而是与业务阶段、团队能力和交付目标密切相关的选择。在很多情况下，它仍然是更务实的起点。
7.1 初创项目
初创项目通常更看重快速验证和低成本试错。单体架构能够帮助团队在资源有限的情况下尽快完成核心功能，避免过早引入过多分布式复杂性。
7.2 中小型业务系统
对于业务边界清晰、并发压力适中、协作团队规模不大的系统，单体架构往往足以支撑日常运行。此类系统更适合将精力投入到功能完善与流程优化上。
7.3 内部管理系统
内部管理系统通常需求相对稳定，访问量也不一定很高。采用单体架构可以简化运维和权限管理，使系统维护更轻松。
7.4 原型验证与快速迭代项目
在原型阶段，产品目标往往是尽快验证思路而不是追求极致架构。单体形式便于频繁修改和快速发布，能够更好地适应需求变化。
8 工程实践
良好的工程实践能够延长单体系统的生命周期。即便不拆分为多个独立服务，仍然可以通过规范化设计让系统保持较好的可维护性。
8.1 模块划分方法
模块划分通常可按业务领域、功能类别或技术职责进行组织。更推荐以业务边界为主进行切分，因为这样更符合后续演进和维护的实际需要。
8.2 目录结构设计
合理的目录结构应让开发者能够快速找到入口、核心逻辑和基础设施代码。常见做法是将控制器、服务、仓储、模型、工具等内容按层或按领域分目录存放。
8.3 依赖管理
依赖管理包括内部模块引用和外部库版本控制。保持依赖关系清晰、版本约束明确，可以减少构建失败、兼容冲突和“隐式耦合”问题。
8.4 接口与边界控制
接口与边界控制强调让模块之间通过明确契约交互，而不是随意共享内部实现细节。这样不仅便于测试，也能降低后期重构时的连锁影响。
8.4.1 防止循环依赖
循环依赖会使代码结构变得脆弱，增加编译、加载和理解难度。工程中通常需要通过提取公共接口、拆分职责或引入中间层来避免这种情况。
8.4.2 统一领域模型
统一领域模型有助于让同一业务概念在系统中保持一致表达。例如，订单、用户、权限等核心对象应尽量使用稳定而统一的定义，以减少歧义和重复建模。
9 与其他架构的比较
单体架构常常与其他架构模式一起被讨论。理解它与相关架构的差异，有助于在不同阶段做出更合适的技术选择。
9.1 与微服务架构的对比
微服务架构将系统拆分为多个独立服务，每个服务可独立部署和扩展；单体架构则更强调整体性和统一发布。前者更适合复杂度高、团队规模大的场景，后者则更适合起步阶段或边界较稳定的系统。
9.2 与分层架构的关系
分层架构关注的是系统内部的职责分离，强调表现层、业务层和数据层的组织方式；单体架构关注的是部署与运行形态。二者并不冲突，单体系统内部完全可以采用分层架构。
9.3 与面向服务架构的区别
面向服务架构通常强调通过服务接口复用能力，服务之间的协作相对明确，但不一定要求像微服务那样细粒度拆分。单体架构则不依赖独立服务边界，更多依靠进程内模块划分来组织系统。
9.4 迁移到其他架构的考虑
从单体迁移到其他架构时，应重点评估业务增长、团队协作、部署频率和系统瓶颈等因素。若现有系统仍能稳定支撑需求，盲目拆分往往会带来额外成本，而不一定立刻获得收益。
10 演进与重构
单体架构并不意味着长期静止不变。随着系统发展，它可以先优化为更清晰的模块化单体，再根据需要逐步演进到其他架构形态。
10.1 从单体到模块化单体
模块化单体是在保持单一部署单元的前提下，加强内部模块边界和接口约束的一种演进方式。它通常被视为过渡阶段，有助于在不大幅改变部署方式的情况下改善可维护性。
10.2 拆分服务的判断标准
是否拆分服务，通常要看是否存在明确的业务边界、独立发布需求、团队协作瓶颈以及性能或稳定性压力等信号。如果这些问题已明显影响交付效率，拆分才更具合理性。
10.3 渐进式重构策略
渐进式重构强调小步调整，而不是一次性推翻重建。常见做法包括先梳理模块边界、抽离公共能力、建立清晰接口，再逐步将独立性较强的部分迁出。
10.4 风险控制与回滚方案
在重构过程中，风险控制通常比技术动作本身更重要。应提前准备版本回滚、数据兼容、灰度发布和监控告警方案，以便在出现异常时快速恢复系统稳定。