全栈攻城狮

Appearance

微服务架构演进路线 ​

架构没有最好，只有合适。单体、集群、SOA、微服务、Service Mesh、Serverless 是一条连续演进路线，每一步都源于上一阶段的痛点，也带出新的代价。本文梳理这条路线，明确 Spring Cloud 在其中的位置，并给出"何时该拆、拆到什么程度"的决策方法。

一、演进全景 ​

架构演进路线：
  单体应用
    │ 痛点：部署慢、扩展难、团队协作差
    ▼
  垂直拆分 + 集群
    │ 痛点：重复代码多、运维复杂、无统一治理
    ▼
  SOA（ESB 服务化）
    │ 痛点：ESB 重、耦合深、性能损耗
    ▼
  微服务（Spring Cloud 时代）
    │ 痛点：治理复杂度高、运维成本大
    ▼
  Service Mesh（Istio 时代）
    │ 痛点：基础设施成熟度要求高
    ▼
  云原生 Serverless

二、单体阶段 ​

单体应用 ​

单体应用特征：
  ├─ 一个应用包部署（WAR/JAR），一个进程
  ├─ 模块按包划分：controller / service / dao
  └─ 数据库共享（一个库）

优点：
  ├─ 开发简单、部署简单、调试方便
  ├─ 事务天然一致（本地事务）
  └─ 性能好（无网络开销）

缺点：
  ├─ 代码膨胀后构建部署慢
  ├─ 团队协作冲突（合并困难）
  ├─ 扩展只能整体扩展（资源浪费）
  └─ 单点故障：一处崩溃整个挂

何时保持单体 ​

适合保持单体的场景：
  ├─ 业务规模小、团队小（< 10 人）
  ├─ 功能耦合紧密、边界不清晰
  ├─ 无独立扩展需求
  └─ 演进节奏不需要独立发布

三、集群与垂直拆分 ​

集群部署 ​

集群化改造：
  ├─ 同一应用多实例部署（负载均衡）
  ├─ 数据库读写分离 / 缓存前置
  ├─ 静态资源 CDN
  └─ 会话外置（Redis）

解决的问题：容量、可用性

垂直拆分 ​

垂直拆分（按业务模块拆）：
  电商示例：
    ├─ user-service（用户）
    ├─ order-service（订单）
    ├─ product-service（商品）
    └─ 各自独立数据库

解决的问题：
  ├─ 代码规模可控
  ├─ 独立团队、独立发布
  └─ 独立扩展（订单服务扩容）

新痛点：
  ├─ 服务间调用（HTTP/RPC）
  ├─ 分布式事务
  ├─ 重复基础设施（监控、日志各自为政）
  └─ 链路问题定位难

四、SOA 阶段 ​

SOA 与 ESB ​

SOA（面向服务架构）：
  ├─ 服务以粗粒度暴露能力
  ├─ ESB（企业服务总线）做服务编排与协议转换
  └─ 强调复用与标准化（WSDL、SOAP）

优点：
  ├─ 服务复用、标准化
  ├─ 异构系统集成能力
  └─ 治理规范（注册、路由、协议适配）

缺点：
  ├─ ESB 是中心化瓶颈（单点 + 性能损耗）
  ├─ 开发链路长（契约、适配、编排）
  └─ 耦合深、难维护

与微服务的区别 ​

SOA vs 微服务：
  ├─ 服务粒度：SOA 粗粒度 / 微服务细粒度
  ├─ 通信方式：SOA 常走 ESB / 微服务直连（轻量 HTTP）
  ├─ 数据管理：SOA 共享库 / 微服务独立库
  ├─ 治理方式：SOA 中心化 / 微服务去中心化（注册中心）
  └─ 部署方式：SOA 集中部署 / 微服务独立部署

五、微服务阶段（Spring Cloud） ​

微服务的完整能力集 ​

微服务需要的基础设施（Spring Cloud 对应）：
  服务发现        → Nacos / Eureka
  负载均衡        → Spring Cloud LoadBalancer
  网关            → Spring Cloud Gateway
  配置管理        → Nacos Config / Config Server
  熔断限流        → Sentinel / Resilience4j
  分布式事务      → Seata
  链路追踪        → SkyWalking / Zipkin
  消息驱动        → Spring Cloud Stream
  定时任务        → XXL-Job / Elastic-Job
  部署运维        → Docker / K8s / CI/CD

微服务的代价 ​

拆分的成本：
  ├─ 分布式复杂度：网络、事务、一致性
  ├─ 运维成本：多服务部署、监控、日志
  ├─ 团队要求：DevOps 能力、自动化测试
  ├─ 调试成本：跨服务问题定位
  └─ 性能开销：RPC 网络损耗、序列化

微服务边界划分 ​

划分原则：
  ├─ 按业务领域（DDD 限界上下文）
  ├─ 按独立扩展需求（高频扩容的独立）
  ├─ 按团队结构（康威定律）
  └─ 按变更频率（一起变的不拆）

拆分策略：
  ├─ 从单体中逐步抽出（绞杀者模式）
  ├─ 先拆边界清晰的模块（用户、订单）
  └─ 共享模块先做接口化沉淀

六、Service Mesh 阶段 ​

服务网格 ​

Service Mesh 形态：
  ├─ Sidecar（数据面）：每个服务旁挂 Envoy 代理
  ├─ 控制面（Istiod）：规则下发、证书管理
  ├─ 流量劫持：iptables 透明转发
  └─ 能力：路由、熔断、重试、mTLS、可观测

解决的问题：
  ├─ 治理能力从框架下沉到基础设施
  ├─ 业务代码与治理逻辑解耦
  └─ 多语言统一治理（Java、Go、Node 同样能力）

与 Spring Cloud 的关系 ​

Spring Cloud vs Service Mesh：
  ├─ Spring Cloud：框架内治理（SDK 方式，侵入业务）
  ├─ Service Mesh：基础设施治理（透明，业务无感）
  └─ 过渡方案：两者共存（框架治理先保留，网格逐步接管）
过渡四阶段：
  1. 并存：Spring Cloud 治理 + Sidecar 观测
  2. 治理下沉：流量管理交给 Istio，框架保留发现
  3. 发现迁移：服务发现迁移到网格（Pilot 与注册中心打通）
  4. 全面网格化：移除框架治理依赖

七、Serverless 阶段 ​

Serverless 形态 ​

Serverless：
  ├─ FaaS：函数即服务（按调用计费、毫秒级冷启动）
  ├─ BaaS：后端即服务（托管数据库、认证、存储）
  └─ 平台托管：无需关心服务器与容量

优势：
  ├─ 弹性极致（按请求扩缩容到 0）
  ├─ 成本精细（用多少付多少）
  └─ 运维极简（无服务器管理）

局限：
  ├─ 冷启动延迟（Native Image 缓解）
  ├─ 无状态约束（不适合长连接、状态服务）
  ├─ 供应商锁定
  └─ 不适合计算密集 / 高吞吐业务

微服务到 Serverless ​

演进关系：
  ├─ 无状态、事件驱动的服务适合函数化
  ├─ 有状态、事务型服务保留在微服务
  ├─ 网关/批处理/定时任务可函数化
  └─ 混合架构：微服务为主体 + 函数补充弹性

八、演进决策方法 ​

是否需要微服务 ​

引入微服务的信号：
  ├─ 团队规模增长（> 2 个协作团队）
  ├─ 发布频率高但被单体耦合拖累
  ├─ 某模块需要独立扩展 / 独立技术栈
  └─ 已有 CI/CD 与监控体系

暂缓的信号：
  ├─ 业务还在快速试错（单体改动快）
  ├─ 团队无运维能力（拆了管不过来）
  └─ 模块边界模糊（拆了通信成本更高）

演进决策树 ​

决策树：
  业务规模小？
    ├─ 是 → 单体（保持简单）
    └─ 否 ↓
  模块边界清晰？
    ├─ 否 → 先梳理边界（DDD），暂缓拆分
    └─ 是 ↓
  有独立扩展/发布需求？
    ├─ 否 → 集群化即可
    └─ 是 ↓
  团队有 DevOps 能力？
    ├─ 否 → 先补能力再拆
    └─ 是 → 引入微服务（Spring Cloud）
        继续演进：
          治理复杂 → 评估 Service Mesh
          弹性需求强 → 引入 Serverless 补充

演进节奏 ​

推荐节奏：
  ├─ 一步一个阶段，不在能力不具备时跳跃
  ├─ 拆分按业务逐步进行（不搞大爆炸重构）
  ├─ 每步配套：监控、灰度、回滚
  └─ 定期复盘：架构是否匹配当前规模

总结 ​

架构演进是"问题驱动"的：单体解决简单，微服务解决复杂，Service Mesh 解决治理侵入，Serverless 解决弹性。Spring Cloud 是微服务阶段最具代表性的治理框架，但它不是终点——当治理复杂度超过业务价值时，就该考虑治理下沉到网格；当弹性需求成为主要矛盾时，就该引入 Serverless。演进的关键不是"用最新架构"，而是让架构复杂度与业务复杂度匹配。