单体架构的理解

1.单体项目是个啥？

在web应用中，如果所有的接口的功能(也可以说是业务功能)，全部集中在一个应用程序中完成，这种项目结构就叫做单体结构。

一个单体结构的电商web项目：

• 库存
• 订单
• 购物车
• 秒杀活动
• 用户评价
• 积分
• 支付

这些所有的功能，全都写在一个项目里，打包成一个程序，部署在一台服务器上。它们共享一个数据库，代码都混在一起（虽然在写的时候会分模块，但还是一个整体）。

2.单体项目有啥优缺点

优点：

• 结构非常简单，所有代码都在一个项目里
• 架构成本比较低
• 运维和部署的成本非常低。

缺点：

❌ 缺点1：代码臃肿，更新困难

“10行代码里写更新，100万行代码里写更行”

📌 问题本质：

随着业务增长，所有功能模块都集中在同一个代码库中，导致代码量庞大、逻辑混乱、职责不清，修改一处可能牵一发而动全身。

✅ 解决方案：

• 微服务架构：将大系统拆分为多个独立部署的小服务，每个服务负责一个业务领域（如订单、用户、支付等），降低单个服务的复杂度。
• 模块化设计：即使不拆微服务，也应通过清晰的分层和模块划分（如DDD领域驱动设计）来解耦代码。
• 持续集成/持续部署（CI/CD）：配合自动化测试与部署流程，减少人工“大海捞针”式修改。

❌ 缺点2：开发人员与业务强耦合

“张三写的复杂业务，只有张三能改”

📌 问题本质：

知识孤岛严重，团队协作效率低，人员变动风险高，新人上手慢。

✅ 解决方案：

• 文档化 + 知识共享机制：
  • 建立完善的接口文档（如 Swagger）、业务流程图、架构说明。
  • 定期组织技术分享会、代码评审。
• 清晰的编码规范与设计模式：
  • 统一使用设计模式（如工厂、策略、责任链）提升可读性。
  • 推行 Clean Code、SOLID 原则。
• 结对编程 / 轮岗机制：避免“一人一模块”的封闭开发模式。
• 领域驱动设计（DDD）：通过统一语言（Ubiquitous Language）让业务与技术对齐，降低理解成本。

❌ 缺点3：并发集中，木桶效应明显

“并发集中在单一服务上，整体性能受最弱环节限制”

📌 问题本质：

单体应用的所有请求都打到同一个服务实例上，某个慢接口或资源密集型操作会拖垮整个系统（比如一个报表查询让登录都变慢）。

✅ 解决方案：

• 服务拆分 + 独立扩容：
  • 将高并发模块（如登录、下单）拆成独立服务，单独部署、独立扩容。
  • 使用负载均衡 + 弹性伸缩（如 Kubernetes）应对流量高峰。
• 异步处理 & 消息队列：
  • 对非实时操作（如发短信、生成报表）使用消息队列（如 Kafka、RabbitMQ）异步化，削峰填谷。
• 缓存优化：
  • 使用 Redis 等缓存热点数据，减少数据库压力。
• 数据库读写分离 / 分库分表：
  • 避免所有请求挤在一张表上。

3.单体项目的适用场景

MVP ：就是先做一个一个功能最简单、但能用的版本

QPS ： 每秒请求数（每秒钟有多少人来访问你的系统）

✅ 典型适用项目举例：

• 企业内部 OA 系统
• 银行/国企内部管理系统（非核心交易系统）
• 学校教务系统
• 农业养殖监控系统（数据量小、实时性要求低）
• 小型电商平台（本地商户）

✅ 总结一句话：“小而简单、稳而不变” 的系统适合单体架构。