一、演进时间轴 

2000      2005      2010      2015      2020      2025
 │         │         │         │         │         │
单体架构  垂直拆分   SOA     微服务    云原生   Serverless
 │         │         │         │         │         │
ALL IN  读写分离  ESB 总线  容器化   Service   函数计算
 ONE     集群部署  Web服务  注册中心   Mesh    边缘计算

二、六大阶段详解

阶段 1：单体架构（2000-2005）

特征

  • All in One：所有功能（UI、业务、数据访问）打包在一个应用
  • 部署简单：一个 WAR/JAR 包部署到 Tomcat
  • 数据库单库：MySQL/Oracle 单实例

技术栈 

前端: JSP + Servlet + JavaScript
后端: SSH (Struts + Spring + Hibernate)
数据库: MySQL 单机
服务器: Tomcat + Apache

代表案例

  • 早期电商网站、企业 OA 系统

痛点

  • ❌ 代码耦合严重，改一处需全量发布
  • ❌ 无法水平扩展（数据库单点）
  • ❌ 团队协作困难（代码冲突频繁）

阶段 2：垂直拆分 + 集群化（2005-2008）

演进动作

  1. 应用垂直拆分：按业务模块拆分独立应用（用户中心、商品中心、订单中心）
  2. 数据库读写分离：Master 写 + Slave 读
  3. 负载均衡：Nginx/LVS 分流

架构图 

          ┌──────────┐
          │  Nginx   │ (负载均衡)
          └─────┬────┘
       ┌────────┼────────┐
       ↓        ↓        ↓
    [用户应用] [商品应用] [订单应用]
       │        │        │
       ↓        ↓        ↓
    用户库    商品库    订单库
   (主从复制) (主从复制) (主从复制)

技术栈 

缓存: Memcached
数据库: MySQL 主从复制
负载均衡: Nginx + Keepalived

痛点

  • ❌ 重复代码（用户服务被多个应用调用，代码复制）
  • ❌ 数据孤岛（应用间数据库不互通）

阶段 3：SOA 面向服务架构（2008-2013）

核心理念

  • 服务复用：将公共能力抽取为服务（用户服务、支付服务）
  • ESB 企业服务总线：统一服务调用和协议转换

架构图 

┌────────┐   ┌────────┐   ┌────────┐
│ Web 应用│   │移动 APP │   │ 第三方  │
└───┬────┘   └───┬────┘   └───┬────┘
    │            │            │
    └────────────┼────────────┘
                 ↓
         ┌──────────────┐
         │  ESB 总线     │ (协议转换、路由)
         └──────┬───────┘
    ┌───────────┼───────────┐
    ↓           ↓           ↓
[用户服务]  [订单服务]  [支付服务]

技术栈 

服务框架: WebService (SOAP + WSDL)
ESB: Mulesoft / IBM ESB
数据库: Oracle RAC 集群

代表玩家

  • 银行、电信等大型企业

痛点

  • ❌ ESB 成为性能瓶颈和单点
  • ❌ SOAP 协议重（XML 解析慢）
  • ❌ 服务粒度粗（一个服务包含多个业务）

阶段 4：微服务架构（2013-2018）

核心变化

  • 去中心化：移除 ESB，服务直连（通过注册中心）
  • 轻量协议：HTTP/REST、gRPC 替代 SOAP
  • 容器化：Docker 崛起，解决环境一致性

技术栈 

// Spring Cloud 全家桶
注册中心: Eureka / Consul
配置中心: Config Server
网关: Zuul / Gateway
熔断: Hystrix
负载均衡: Ribbon
调用: Feign / RestTemplate

// 阿里系
注册中心: Nacos
RPC: Dubbo
分布式事务: Seata

架构图 

       ┌──────────────┐
       │ API Gateway  │
       └──────┬───────┘
              │
    ┌─────────┼─────────┐
    ↓         ↓         ↓
 [用户服务] [订单服务] [商品服务]
    │         │         │
    └────────→│←────────┘
         (服务间调用)
         ↑
    ┌────┴────┐
    │  Eureka │ (服务注册发现)
    └─────────┘

关键能力

  • 服务治理：限流、熔断、降级
  • 分布式事务：TCC、Saga、本地消息表
  • 分库分表：ShardingSphere
  • 链路追踪：SkyWalking、Zipkin

代表案例

  • 国内互联网公司（阿里、美团、京东）

痛点

  • ❌ 服务数量爆炸（治理复杂）
  • ❌ 分布式事务难（一致性与性能矛盾）
  • ❌ 运维成本高（服务部署、监控）

阶段 5：云原生时代（2018-2023）

核心理念（CNCF 定义）

  • 容器化：Kubernetes 编排
  • 微服务：继续细化
  • DevOps：CI/CD 自动化
  • 服务网格：Istio 治理下沉

技术栈 

容器编排: Kubernetes (K8s)
服务网格: Istio + Envoy
可观测: Prometheus + Grafana + Jaeger
CI/CD: GitLab CI / Jenkins X / ArgoCD
基础设施即代码: Terraform / Helm

架构图 

┌────────────────────────────────────┐
│         Istio 控制平面              │
│  (流量管理、安全、可观测)            │
└─────────────┬──────────────────────┘
              ↓ (配置下发)
┌────────────────────────────────────┐
│        Kubernetes 集群              │
│  ┌─────────┐   ┌─────────┐         │
│  │  Pod A  │   │  Pod B  │         │
│  │ ┌─────┐ │   │ ┌─────┐ │         │
│  │ │ App │ │   │ │ App │ │         │
│  │ └─────┘ │   │ └─────┘ │         │
│  │ Envoy   │←─→│ Envoy   │         │
│  └─────────┘   └─────────┘         │
└────────────────────────────────────┘

关键变化

  1. 运维自动化：声明式 API（YAML），自愈、自动扩缩容
  2. 服务治理下沉：代码无需引入 SDK，Sidecar 透明代理
  3. 多云/混合云：屏蔽底层基础设施差异

代表案例

  • Netflix、Spotify、阿里云、腾讯云

阶段 6：Serverless 无服务器（2023-至今）

核心理念

  • 函数即服务（FaaS）：开发者只需写业务逻辑，无需关心服务器
  • 事件驱动：按请求自动扩缩容到 0
  • 按用量计费：没有请求不收费

技术栈 

FaaS 平台: AWS Lambda / 阿里云 FC / 腾讯云 SCF
框架: Knative (K8s 上的 Serverless)
BaaS: Firebase / AWS Amplify

代码示例 

// AWS Lambda 函数：处理订单创建
exports.handler = async (event) => {
    const order = JSON.parse(event.body);
    // 业务逻辑：保存订单到数据库
    await saveOrder(order);
    return { statusCode: 200, body: 'Order created' };
};

适用场景

  • ✅ 事件驱动任务：图片处理、定时任务、Webhook
  • ✅ 低频应用：后台管理系统、内部工具
  • ❌ 不适合：长连接（WebSocket）、高 QPS 核心业务

优势

  • 无需运维服务器
  • 自动弹性伸缩（毫秒级冷启动优化中）
  • 成本更低（按实际调用次数计费）

痛点

  • ❌ 冷启动延迟（优化中，如 AWS SnapStart）
  • ❌ 厂商锁定（难以迁移）
  • ❌ 调试困难（本地环境模拟难）

三、演进驱动因素对比

阶段 核心矛盾 解决方案 技术代表
单体 代码耦合 垂直拆分 SSH 框架
垂直拆分 代码重复 服务抽取 主从复制
SOA ESB 瓶颈 去中心化 WebService
微服务 运维复杂 容器化编排 Spring Cloud / K8s
云原生 多语言治理 服务网格 Istio / Envoy
Serverless 闲置资源 按需计费 AWS Lambda

四、技术选型决策树 

业务体量小（日活 < 1 万）
    → 单体架构（Spring Boot 单应用）

业务增长快，团队 < 20 人
    → 垂直拆分 + Redis 缓存

多个独立业务线，团队 > 50 人
    → 微服务（Spring Cloud Alibaba）

多语言技术栈，服务 > 100 个
    → 云原生（K8s + Istio）

低频/事件驱动场景
    → Serverless（函数计算）

五、答题总结

3 分钟回答框架：

1. 开场（30秒）

“互联网架构的演进本质是业务复杂度增加与技术能力提升的博弈过程，大致分为 6 个阶段。”

2. 快速梳理（1分30秒）

阶段 时间段 核心特征 代表技术
单体 2000-2005 All in One SSH
垂直拆分 2005-2008 集群+读写分离 Nginx+MySQL主从
SOA 2008-2013 ESB 总线 WebService
微服务 2013-2018 去中心化 Spring Cloud
云原生 2018-2023 K8s+服务网格 Istio
Serverless 2023-至今 函数计算 AWS Lambda

3. 点明演进逻辑（1分钟）

  • 单体 → 垂直拆分：解决扩展性（加机器）
  • 垂直拆分 → SOA：解决代码复用（服务化）
  • SOA → 微服务：解决 ESB 瓶颈（去中心化）
  • 微服务 → 云原生：解决运维复杂度（自动化编排）
  • 云原生 → Serverless：解决资源利用率（按需计费）

4. 总结升华（30秒）

“架构演进没有银弹，关键是匹配业务阶段。小团队别过度设计，大公司重点解决规模化治理问题。”

加分点：

  • 提及具体技术栈（如 Spring Cloud、Istio、Knative）
  • 对比优劣势（如 SOA 的 ESB 重 vs 微服务的轻量）
  • 结合实际案例（如阿里从单体到微服务的演进）

延伸问题：

  • 微服务拆分到什么粒度合适？
  • 云原生和微服务有什么区别？
  • Serverless 能完全替代传统架构吗？