3.15、单体应用总结
分类: 搭建单体商城服务
单体应用总结
我们已经完成了单体商城应用的开发。在进入微服务架构之前，让我们总结一下单体应用的优缺点，以及存在的问题。
本节将学习：当前架构优缺点、存在的问题，以及微服务化需求。
当前架构优缺点
架构优势
单体应用的优势：
- 简单结构：代码结构清晰，易于理解
- 开发效率高：无需考虑服务间通信
- 部署简单：只需部署一个应用
- 测试方便：本地测试即可验证功能
- 事务管理简单：使用本地事务即可
架构劣势
单体应用的劣势：
- 扩展性差：只能整体扩展，无法按需扩展
- 技术栈限制：必须使用统一的技术栈
- 部署风险高：一个小改动需要重新部署整个应用
- 团队协作困难：多人开发容易产生冲突
- 性能瓶颈：所有功能共享资源
存在的问题
性能问题
性能问题：
- 数据库连接池耗尽：所有模块共享连接池
- 内存占用高：所有功能运行在同一进程
- CPU 负载高：无法针对特定功能优化
可维护性问题
可维护性问题：
- 代码耦合度高：模块间依赖复杂
- 修改影响范围大：一个小改动可能影响整个系统
- 技术债务积累：难以重构
可扩展性问题
可扩展性问题：
- 无法按需扩展：必须整体扩展
- 资源浪费：某些功能不需要扩展，但必须一起扩展
- 成本高：扩展成本随系统规模线性增长
微服务化需求
为什么需要微服务？
微服务化的需求：
- 独立扩展：每个服务可以独立扩展
- 技术多样性：不同服务可以使用不同技术栈
- 团队自治：不同团队可以独立开发和部署
- 故障隔离：一个服务故障不影响其他服务
微服务化挑战
微服务化带来的挑战：
- 服务拆分：如何合理拆分服务
- 服务通信：服务间如何通信
- 数据一致性：如何保证分布式数据一致性
- 服务治理：如何管理大量服务
架构对比
单体 vs 微服务
迁移路径
从单体到微服务
迁移步骤：
- 识别服务边界：按业务领域拆分
- 提取服务：将功能提取为独立服务
- 独立数据库：每个服务使用独立数据库
- 服务通信：实现服务间通信机制
- 逐步迁移：逐步将功能迁移到微服务
本节小结
在本节中，我们总结了：
第一个是当前架构优缺点。 单体应用简单但扩展性差。
第二个是存在的问题。 性能、可维护性、可扩展性问题。
第三个是微服务化需求。 独立扩展、技术多样性、团队自治、故障隔离。
第四个是迁移路径。 从单体到微服务的迁移步骤。
这就是单体应用总结。理解单体应用的优缺点，有助于我们更好地设计微服务架构。
在下一章，我们将学习 DDD 领域驱动设计，为微服务拆分做准备。