一、架构演进的核心逻辑
演进动力 ：随着项目规模扩大、用户量增长，架构需要解决 =="耦合度高、扩展性差、维护成本高"等问题，从"单体集中式"向"分布式松耦合"==升级
二、三种架构的详细对比
传统 MVC 架构（单体后端渲染）
-
核心定位 ：早期中小型项目的基础架构，后端主导页面渲染
-
具体层次（以 Java Web 为例）：
- View 层：JSP/Thymeleaf（负责页面渲染，由后端生成 HTML 返回）
- Controller 层：Servlet/SSM 的 Controller（接收请求，调用 Service，返回渲染后的页面）
- Service 层：业务逻辑处理
- Dao 层：MyBatis/Hibernate（数据交互）
- Model 层：JavaBean 实体类（封装数据）
-
应用场景：
- 小型项目（如企业内部管理系统、个人博客）
- 对前端交互要求低、快速开发的场景
- 团队技术栈以后端为主，前端资源较少的情况
-
痛点：
- 前后端耦合度极高：前端页面依赖后端渲染，前后端开发需同步进行，联调成本高
- 扩展性差：所有功能集中在一个项目，修改某一模块需重新部署整个应用
分层架构（前后端分离单体）
-
核心定位 ：解决传统 MVC 的前后端耦合问题，前端独立为应用，后端聚焦接口服务
-
具体层次：
-
前端层（独立应用）：
- 框架层：Vue/React/Angular
- 工具层：Axios（接口请求）、Vue Router（路由）、Pinia/Vuex（状态管理）
- 职责：页面渲染、用户交互、数据展示，完全自主控制页面逻辑
-
后端层（单体接口服务）：
- Controller 层：接收前端 HTTP 请求，返回 JSON 数据（不再渲染页面）
- Service 层：业务逻辑处理
- Dao 层：持久层框架（MyBatis/JPA）
- （可选）公共层：工具类、异常处理、统一返回结果封装
-
-
应用场景：
- 中型项目（如中小电商、企业级 SaaS 系统）
- 对前端交互体验要求较高的场景
- 前后端团队可独立并行开发的项目
-
痛点：
- 后端仍是单体应用：所有接口服务集中在一个项目，当业务模块过多时，依然会出现 "代码臃肿、启动慢、故障影响面大" 的问题
- 需关注接口规范：前后端通过接口通信，需约定统一的请求格式、返回格式（如 RESTful 规范）
微服务架构（分布式松耦合）
-
核心定位 ：解决分层架构的 "单体瓶颈"，将后端拆分为多个独立的微服务，实现高扩展、高可用
-
具体层次（前后端分离 + 微服务）：
-
前端层：同 "分层架构" 的独立前端应用
-
后端层（微服务集群）：
-
微服务单元：每个微服务对应一个独立的业务模块（如用户服务、订单服务、商品服务），每个微服务都是一个小型的 "Controller+Service+Dao" 分层应用
-
服务治理组件：
- 注册中心（Nacos/Eureka）：管理微服务的地址、状态
- 网关（Gateway）：统一入口，负责路由、鉴权、限流
- 配置中心（Nacos/Config）：统一管理所有微服务的配置
- 服务调用（Feign/OpenFeign）：微服务之间的接口调用
- （可选）熔断降级（Sentinel/Hystrix）：防止服务故障扩散
-
-
-
应用场景：
- 大型 / 超大型项目（如电商平台、社交 APP、金融系统）
- 业务模块多、用户量高（百万 / 千万级）、需要高可用的场景
- 团队规模大，不同模块可独立维护的项目
-
痛点：
- 架构复杂度陡增：需引入服务治理、分布式事务、日志追踪等组件，运维成本大幅提高
- 并非 "越大越好"：小型项目用微服务会 "过度设计"，反而增加开发 / 维护成本
总结：架构选型的核心原则
- 小型项目：选传统 MVC（快速开发）
- 中型项目：选前后端分离分层架构（平衡开发效率与扩展性）
- 大型项目：选微服务架构（解决单体瓶颈，支持高并发高扩展）