单体架构（monolithic architecture）通常指核心业务功能组成一个主要部署单元。理解它要区分代码组织、逻辑分层和部署方式，不能从“整体”推导出代码必然混乱。
单体应用可以包含多个模块和逻辑层，也可以采用清晰的接口、依赖方向和独立测试。其核心特征是主要作为一个整体构建和部署；单一代码库不是充分条件，多服务也可能共用一个代码仓库。
单体应用的核心特点与组成部分
大多数单体应用都具备这些特征：
-逻辑上可分层、可模块化；物理上仍可作为单个应用部署。后续维护难度取决于模块边界和依赖管理。
-一个主要应用部署单元；仍可依赖数据库、消息系统、身份服务或其他外部系统。
-变更通常发布该应用的新版本；需要重编译哪些部分、执行哪些测试，取决于语言、构建工具及依赖关系。
-可以共用一个数据库，也可连接多个数据源；数据库数量不是单体架构的定义条件。
一个典型的单体应用，通常会包含这些模块：
-授权模块：负责验证用户身份、控制权限。
-展示层：处理前端请求，返回HTML、XML或JSON等数据。
-业务逻辑层：实现应用的核心业务规则。
-数据访问层：封装对数据库的操作。
-通知模块：负责发送邮件、消息等自动通知。
单体应用常以统一产物发布，但并非任何小改动都必然全量编译。自动化构建、测试和部署也能支持单体持续交付。
单体架构长什么样？举个例子就懂
我们用一个银行App来理解。
用户打开网站、登录账号、查询余额、下载账单、转账……这背后涉及界面展示、用户登录、权限校验、业务处理、数据库操作等一堆功能。
在这个假设的银行应用例子里，后端核心功能被打包成统一程序。网页、手机端可以是独立客户端；后端内部也能划分授权、业务和数据模块。若模块边界失控，局部变更的影响才会不断扩大。
实际系统往往混合使用单体、模块化单体和服务化组件。比较时应明确具体子系统与部署边界，不能把某次局部调整概括为整个产品的架构路线。
单体架构的优势
直到今天，依然有大量项目在用单体架构，因为它确实有不少优点：
-在用户量、并发量不大的场景下，部分单体应用的性能、响应速度甚至优于微服务。
-测试、调试更简单，组件少、变量少，排查问题更直接。
-项目初期开发更简单，结构清晰，上手快。
-部署单元较少，发布流程通常更集中；仍需配置管理、数据库兼容、监控与回滚准备。
-日志、配置、监控都更统一，便于管理。
-也可以通过负载均衡+多副本的方式做横向扩容。
单体架构的劣势
但随着项目变大，单体架构的短板会越来越明显：
-变更影响可能集中：模块依赖复杂时，一处修改需要更广的检查和协调。
-代码难维护：代码库越来越大，新人难看懂，改代码风险高。
-发布粒度较大：整体发布可能增加验证成本，但配合自动化流水线、分批放量和兼容性设计，仍可持续交付。
-体积与资源需求增长可能影响启动或响应，是否成为瓶颈要通过测量判断。
-资源冲突：不同模块对资源需求不同，很难统一优化扩容。
-稳定性风险高：一个模块出问题，比如内存泄漏，可能直接拖垮整个应用。
-技术升级困难：架构太重、改造代价大，很难快速用上新框架、新语言。
单体架构vs微服务架构
简单一句话总结两者的差别：
单体架构：
单体架构：主要功能作为一个部署单元，内部可以模块化和分层；收益是部署与运维集中，代价是发布、故障和资源隔离的边界较大。
微服务架构：
微服务架构：按业务能力拆成可独立部署的服务。合理边界有助于独立扩容和发布，但API、共享数据、消息与版本兼容仍会形成依赖，不能保证互不影响。
当独立发布、资源隔离和团队自治的收益足以覆盖额外运维成本时，微服务可能有价值：
-明确服务边界有助于控制局部修改范围，跨服务影响仍需契约与端到端验证。
-更适合敏捷开发、快速迭代。
-每个服务可独立扩容、独立选技术栈。
-服务之间通过API通信，边界清晰。
-支持更快的发布节奏。
到底该用单体，还是微服务？
可以按这个思路选：
-优先用单体架构：
项目初期、功能简单、用户量小、团队规模不大的时候，单体架构 简单、较高效。
-更适合微服务架构：
业务存在明确边界、需要独立扩容或发布，且团队能承担服务发现、可观测性、分布式一致性及故障治理时，可评估微服务。高可用并非拆分后自动获得；也可先采用模块化单体，再按瓶颈拆分。
技术参考：Microsoft：常见Web应用架构，用于区分逻辑层和部署单元。
