单体与微服务区别

一、架构本质区别

  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 接口

相关推荐
晶捷软件5 小时前
从 IT 架构视角看 ERP 选型:用友、金蝶与鼎捷生态(含晶捷智能)的技术差异
架构·智能制造·erp·制造业信息化
@大迁世界5 小时前
Firefox 本地模式:localhost 再见了 ?
前端·架构
深蓝AI5 小时前
总榜第一不等于最划算:Intelligence Index v5 换代后,模型选型要算的三笔账
程序员·架构
天远数科6 小时前
零信任架构实战:基于天远企业股权变更构建自动化商业银行对公授信存续期股权异动与资产抽逃预警网关
运维·人工智能·架构·自动化
AI你一生一世7 小时前
当“暂停“成为架构决策:从签证系统停摆看高可用设计的边界
架构·系统架构·流量控制·幂等性·高可用设计·优雅降级·状态一致性
L0208248 小时前
Kubernetes Ingress|CNI 网络模型|Calico 网络策略|Pod 调度器完整实战教程
运维·网络·云原生·容器·kubernetes
每天一道题9 小时前
CAP、Raft 与多数派:分布式系统如何达成一致?
分布式·后端·微服务
闲云野鹤在人间10 小时前
Kubernetes Pod Scheduler 详解
云原生·容器·kubernetes
云宏信息11 小时前
超融合和存算分离怎么选?从性能、可靠性、扩展、成本四个维度讲述如何精准匹配架构选型 | 附企业降本轻量云方案
运维·服务器·架构·云计算
snpgroupcn12 小时前
能源行业SAP系统升级的技术约束分析:资产数据连续性与切换窗口的工程处理(上篇)
架构·sap