后台应用架构演进

Posted on Views:

1.演进全览

静态页面（HTML）
    ↓
CGI通用网关接口（动态生成页面）
    ↓
Servlet/JSP（Java后端编程）
    ↓
MVC框架（Struts/Spring MVC）
    ↓
REST API（前后端分离）
    ↓
单体架构（All in One）
    ↓
微服务架构
    ↓
云原生 / Serverless（未来方向）

2.各阶段详解

2.1静态页面时代

浏览器 → 请求HTML文件 → Web服务器直接返回静态文件
  • 所有用户看到的页面完全相同
  • 无法处理数据库查询、用户交互

2.2CGI通用网关接口

浏览器 → URL请求 → 映射到服务器脚本 → 脚本执行（查数据库）→ 返回HTML

代表技术：ASP、PHP、JSP

问题：每个请求启动一个新进程，性能差，不适合高并发。

2.3Servlet 技术

浏览器 → HTTP请求 → Servlet容器（Tomcat）→ Servlet实例处理返回HTML/JSON

核心特点：

  • 一次加载，多次复用（单例模式）
  • 处理HTTP请求与响应的Java程序
  • 运行在Web容器中

痛点：HTML与Java代码混写，维护困难。

2.4JSP + MVC

用户请求 → Servlet（Controller）→ 调用业务逻辑（Model）→ 渲染页面（View/JSP）→ 返回HTML

代表框架：Struts、Spring MVC

改进：

  • 视图与逻辑分离
  • 统一入口（Front Controller）
  • 表单数据自动绑定

局限：服务端渲染，每次请求都要完整走一遍流程，性能优化困难。

2.5REST + 前后端分离

浏览器（React/Vue）→ AJAX请求 → 服务端返回JSON → 前端渲染界面

核心改变：

  • 后端只提供API，不返回HTML
  • 前端负责界面渲染和交互
  • 通过JSON格式交换数据
  • 同一套API可服务于Web、iOS、Android多端

接口设计：

GET    /api/users        → 查询用户列表
POST   /api/users        → 创建用户
PUT    /api/users/{id}   → 修改用户
DELETE /api/users/{id}   → 删除用户

2.6单体架构

┌──────────────────────────────────────┐
│           单一应用进程                 │
│                                      │
│  ┌────────┐ ┌────────┐ ┌────────┐   │
│  │ 用户模块 │ │订单模块 │ │支付模块 │   │
│  └────────┘ └────────┘ └────────┘   │
│                                      │
│  共享数据库 · 共享部署 · 共享内存       │
└──────────────────────────────────────┘
         ↓
    水平复制 + 负载均衡

典型部署：一个war/jar包，部署在一台或多台服务器上。

2.7微服务架构

                    ┌──────────────┐
                    │   API网关     │
                    │  (Kong/Nginx) │
                    └──────┬───────┘
                           │
        ┌────────┬─────────┼─────────┬────────┐
        ▼        ▼         ▼         ▼        ▼
   ┌────────┐┌────────┐┌────────┐┌────────┐┌────────┐
   │ 用户服务 ││订单服务 ││商品服务 ││支付服务 ││通知服务  │
   └───┬────┘└───┬────┘└───┬────┘└───┬────┘└───┬────┘
       │         │         │         │         │
    ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
    │MySQL │ │MySQL │ │MySQL │ │Redis │ │MQ    │
    └──────┘ └──────┘ └──────┘ └──────┘ └──────┘

核心特征：

  • 服务独立部署、独立扩展
  • 各服务使用独立数据库
  • 通过HTTP/RPC通信
  • 服务发现、配置中心、熔断降级

3.关键对比

维度 单体架构 微服务架构
代码组织 一个项目 多个独立项目
数据库 共享 各服务独立
部署方式 单个jar包 多个jar包
扩展粒度 整体扩展 按需扩展
故障隔离 一处故障全站挂 单点故障不影响其他
开发效率 初期快 需要分工协作
运维复杂度 低 高（需K8s/服务网格）
适用规模 小型项目 大型复杂系统