软件中的单体架构是什么？原理到优缺点，一篇讲清楚

单体架构是软件开发里非常经典、传统的设计模式。这里的“单体”（monolithic），直译就是“整块、整体式”。按照《剑桥词典》的解释，monolithic除了“整体的”，还带有“过于庞大”和“难以改动”的意味，这也恰好对应了它在软件里的特点。

在实际开发中，单体架构就是把一个应用的所有功能，都写在同一个代码库里。应用里的各个模块、组件高度绑定，必须全部齐全，代码才能正常编译、运行。而且，这些功能之间通常是紧耦合关系，不像模块化设计那样松散独立，多个功能打包在一起，共同组成一个完整应用。也正因为如此，单体应用时间一长，往往会变得非常复杂。

单体应用的核心特点与组成部分

大多数单体应用都具备这些特征：

-单层结构：所有组件揉合成一个大应用，代码库体积庞大，越往后维护、更新越麻烦。

-独立自包含：不依赖其他外部应用，可以单独运行。

-单一代码库：只要改一个组件，其他相关部分可能也要跟着调整，而且整个应用必须重新编译、测试、部署。

-共用一个数据库：一般采用关系型数据库作为统一数据源。

一个典型的单体应用，通常会包含这些模块：

-授权模块：负责验证用户身份、控制权限。

-展示层：处理前端请求，返回HTML、XML或JSON等数据。

-业务逻辑层：实现应用的核心业务规则。

-数据访问层：封装对数据库的操作。

-通知模块：负责发送邮件、消息等自动通知。

可以看出，单体架构有一个很明显的特点：哪怕只改一小段代码，也要重新编译整个应用。

单体架构长什么样？举个例子就懂

我们用一个银行App来理解。

用户打开网站、登录账号、查询余额、下载账单、转账……这背后涉及界面展示、用户登录、权限校验、业务处理、数据库操作等一堆功能。

如果这是单体架构，那它就是一个整体、统一、打包部署的程序。不管用户用电脑还是手机访问，背后都是同一套代码。而且各个模块紧耦合，牵一发而动全身——改一个地方，很可能要连带改其他模块。

其实很多我们熟悉的产品，最早都是单体架构，后来才慢慢改成微服务，比如Spotify、Netflix、Facebook、Instagram、Uber等。

当然也有反过来的例子，比如亚马逊Prime就曾从微服务改回单体。也有从诞生到现在一直坚持单体的，比如WordPress和Linux内核。

单体架构的优势

直到今天，依然有大量项目在用单体架构，因为它确实有不少优点：

-在用户量、并发量不大的场景下，部分单体应用的性能、响应速度甚至优于微服务。

-测试、调试更简单，组件少、变量少，排查问题更直接。

-项目初期开发更简单，结构清晰，上手快。

-部署方便，直接把打包好的文件丢到服务器就行。

-日志、配置、监控都更统一，便于管理。

-也可以通过负载均衡+多副本的方式做横向扩容。

单体架构的劣势

但随着项目变大，单体架构的短板会越来越明显：

-更新成本高：改一处，动全身，严重影响开发和发布效率。

-代码难维护：代码库越来越大，新人难看懂，改代码风险高。

-部署效率低：每次都要全量编译、全量部署，不适合持续交付。

-启动慢、响应慢：应用体积大，拖累性能。

-资源冲突：不同模块对资源需求不同，很难统一优化扩容。

-稳定性风险高：一个模块出问题，比如内存泄漏，可能直接拖垮整个应用。

-技术升级困难：架构太重、改造代价大，很难快速用上新框架、新语言。

单体架构vs微服务架构

简单一句话总结两者的差别：

单体架构：

所有组件高度依赖，共用一个代码库。小改动也要重新编译、全量部署，风险集中，效率受限。

微服务架构：

由多个松耦合的小服务组成，每个服务只干一件事。修改时只动对应服务，可独立开发、测试、部署，互不影响，扩展性、灵活性都更强。

所以微服务现在更受大型团队欢迎，优势很突出：

-模块化清晰，局部修改不影响全局。

-更适合敏捷开发、快速迭代。

-每个服务可独立扩容、独立选技术栈。

-服务之间通过API通信，边界清晰。

-支持更快的发布节奏。

到底该用单体，还是微服务？

可以按这个思路选：

-优先用单体架构：

项目初期、功能简单、用户量小、团队规模不大的时候，单体架构最简单、最高效。

-更适合微服务架构：

业务复杂、需求变动频繁、需要高频发布、追求高可用和强扩展，或者团队希望灵活使用新技术时。