单体与微服务区别

一、架构本质区别

  1. 单体架构

所有业务代码写在同一个 SpringBoot 项目、一个 Jar 包:用户、商品、订单、支付、文件上传全部耦合在一起,共享一个数据库。

• 部署:只打一个 jar,启动一个进程

• 调用:模块之间本地方法调用,直接 new 对象 / 注入 Bean

• 数据库:单库多表,所有业务共用一套库

  1. 微服务架构

按业务领域拆分成多个独立 SpringBoot 子项目(用户服务、订单服务、商品服务、网关等),每个服务独立工程、独立数据库、独立部署。

• 部署:每个服务单独打包独立运行,可单独扩容

• 调用:跨服务通过 HTTP/Feign 远程调用,走网络

• 数据库:分库隔离,订单库、用户库、商品库互不干扰

二、工程代码结构差异(重点) 单体项目结构 单模块工程,内部分包分层:controller/service/mapper/entity/common全部代码在一个模块,公共工具、业务、配置都在当前项目内部。

优点:结构简单,上手快;缺点:代码臃肿,百万行后维护灾难。

微服务聚合工程结构(Maven 多模块)

  1. 父工程(mall-parent):统一版本管理,不写业务

  2. 公共模块 mall-common:全局工具、统一返回、异常、MP 配置,所有服务依赖

  3. API 模块 mall-api:存放 Feign 远程调用接口、公共实体 DTO/VO,解决跨服务传参

  4. 网关服务 gateway:统一流量入口

  5. 多个独立业务微服务(user/order/product/pay)每个业务服务内部才是标准 SpringBoot 分层,互相隔离

三、优缺点总结

单体架构优点

  1. 开发简单,无复杂中间件

  2. 本地调用无网络损耗,性能好

  3. 部署简单,一个 jar 启动

  4. 排查问题简单,无分布式链路

  5. 入门学习成本低

单体架构缺点

  1. 代码耦合严重,后期维护成本爆炸

  2. 扩容浪费资源,只能整体扩容

  3. 发布风险高,小改动全量重启

  4. 数据库压力集中,多表竞争锁

  5. 大型团队协作冲突频繁

微服务架构优点

  1. 服务解耦,单一职责,易维护

  2. 故障隔离,单个服务宕机不影响整体

  3. 按需弹性扩容,节省服务器成本

  4. 独立迭代、单独发布,风险小

  5. 团队分模块并行开发,效率高

  6. 支持高并发、大数据量业务

微服务架构缺点

  1. 架构复杂,大量中间件学习成本高

  2. 存在分布式难题:分布式事务、分布式锁、接口幂等、超时重试

  3. 远程调用带来网络延迟,需要熔断限流保障稳定性

  4. 运维成本高:多服务、多数据库、多中间件部署维护

  5. 排查困难,需要链路追踪、分布式日志

  6. 开发工作量变大,需要封装公共模块、Feign 接口

相关推荐
cfm_29148 小时前
Nacos零基础入门实战
微服务
运维大师9 小时前
【K8S 运维实战】01-K8s架构深度剖析
运维·架构·kubernetes
XUHUOJUN9 小时前
Azure Stack Hub 容量规划指南(上篇:Microsoft 软件层 + 架构原理)
架构·azure stack
seacracker9 小时前
HPC存储I/O抖动无解?PowerFS基于CRDT弱一致架构,彻底实现前台零抖动
架构·分布式存储·powerfs·hpc存储·i/o零抖动
解局易否结局9 小时前
ArkTS 设计模式与架构进阶:构建可维护的 HarmonyOS 应用
华为·设计模式·架构·harmonyos
Swift社区11 小时前
AI 为什么越来越像微服务?
人工智能·微服务·架构
ai_coder_ai11 小时前
基于架构的软件设计方法
架构
AA陈超12 小时前
006 T03 — 蓝图操作指南
c++·游戏·架构·ue5·github·虚幻引擎
Geek-Chow13 小时前
Kubernetes HPA Behavior When Deployment Is Scaled to 0
云原生·容器·kubernetes