预计阅读 28 分钟
04 | 可扩展架构 —— 分层架构、微服务、SOA、中台思想
好的架构不是一次设计出来的，而是随着业务演进而逐步生长出来的。
开篇自测
- SOA 与微服务的核心区别是什么？微服务是 SOA 的升级版吗？
- 你了解”中台”的概念吗？它解决了什么问题，又带来了什么新问题？
- 单体架构一定是落后的吗？什么情况下单体架构反而是最优解？
一、可扩展性的本质
1.1 什么是可扩展性
可扩展性不仅仅是”加机器就能抗更多流量”，它还包括：
- 功能扩展性：新增一个业务功能，需要修改多少现有代码？
- 团队扩展性：从 5 人团队扩展到 50 人团队，开发效率是否能保持？
- 技术扩展性：引入一种新技术（如新的数据库），需要改动多少系统？
可扩展架构的核心思想是拆分——通过将系统分解为独立的、职责单一的模块，使得每个模块可以独立开发、测试、部署和扩展。
1.2 拆分的两个维度
纵向拆分（按层次） 横向拆分（按业务）
+------------------+ +------+ +------+ +------+
| 表现层 | | 用户 | | 订单 | | 商品 |
+------------------+ | 服务 | | 服务 | | 服务 |
| 业务逻辑层 | | | | | | |
+------------------+ +------+ +------+ +------+
| 数据访问层 |
+------------------+
| 存储层 |
+------------------+
目的：关注点分离 目的：业务解耦
各层可独立演进 各业务可独立扩展二、架构演进之路
2.1 从单体到分布式
几乎所有成功的大型系统都经历了类似的架构演进路径：
阶段 1: 单体架构
+----------------------------------+
| 用户模块 | 订单模块 | 商品模块 |
| 所有代码一个仓库 |
| 一个数据库 |
| 一台机器部署 |
+----------------------------------+
适用：初创期，用户 < 10万，团队 < 10人
|
v (用户增长，团队扩大)
阶段 2: 垂直拆分
+----------+ +----------+ +----------+
| 用户系统 | | 交易系统 | | 商品系统 |
| 用户DB | | 订单DB | | 商品DB |
+----------+ +----------+ +----------+
适用：发展期，用户 10万~100万，团队 10~30人
|
v (业务复杂度上升，重复建设严重)
阶段 3: SOA / 微服务
+------+ +------+ +------+ +------+ +------+
| 用户 | | 订单 | | 商品 | | 支付 | | 物流 |
| 服务 | | 服务 | | 服务 | | 服务 | | 服务 |
+------+ +------+ +------+ +------+ +------+
| | | | |
+----------------------------------------------+
| 服务治理平台 / API 网关 |
+----------------------------------------------+
适用：成熟期，用户 > 100万，团队 > 30人
|
v (跨业务协同困难，需要能力沉淀)
阶段 4: 中台架构
+----------------------------------------------+
| 前台业务（快速变化） |
| 电商App | 小程序 | 直播 | 社区 |
+----------------------------------------------+
| 中台能力（稳定复用） |
| 用户中台 | 交易中台 | 数据中台 | 营销中台 |
+----------------------------------------------+
| 后台系统（基础设施） |
| 数据库 | 缓存 | 消息队列 | 存储 |
+----------------------------------------------+2.2 架构演进的驱动力
每次架构升级都不是为了追新技术，而是被具体的问题驱动：
| 演进阶段 | 驱动问题 | 核心解决方案 |
|---|---|---|
| 单体 -> 垂直拆分 | 代码耦合，部署困难，数据库瓶颈 | 按业务拆分应用和数据库 |
| 垂直拆分 -> SOA | 重复建设，服务调用混乱 | 抽取公共服务，统一服务治理 |
| SOA -> 微服务 | ESB 成为瓶颈，服务粒度太粗 | 去中心化，细粒度服务拆分 |
| 微服务 -> 中台 | 各业务线重复造轮子，数据孤岛 | 沉淀通用业务能力为中台 |
三、分层架构详解
3.1 经典三层架构
+--------------------------------------------------+
| 表现层 (Presentation) |
| 职责：处理用户交互、数据展示、输入验证 |
| 技术：React/Vue/Android/iOS/API Gateway |
+--------------------------------------------------+
|
+--------------------------------------------------+
| 业务逻辑层 (Business Logic) |
| 职责：核心业务规则、工作流编排、数据处理 |
| 技术：Spring Boot/Express/Go |
+--------------------------------------------------+
|
+--------------------------------------------------+
| 数据访问层 (Data Access) |
| 职责：数据持久化、缓存管理、外部数据源交互 |
| 技术：MyBatis/JPA/GORM + Redis + ES |
+--------------------------------------------------+3.2 分层架构的原则
依赖规则：高层可以依赖低层，低层不能依赖高层。
表现层 ----依赖----> 业务层 ----依赖----> 数据层
表现层 <----不可---- 业务层 <----不可---- 数据层开放层与封闭层：
- 封闭层：请求必须逐层传递，不能跳过（严格分层）
- 开放层：允许跨层调用（灵活但可能导致耦合）
实践中建议以封闭层为主，仅在性能关键路径上允许跨层调用。
3.3 DDD 分层架构
领域驱动设计（DDD）提出了更精细的四层架构：
+--------------------------------------------------+
| 用户接口层 (Interfaces) |
| REST API / GraphQL / gRPC |
+--------------------------------------------------+
|
+--------------------------------------------------+
| 应用层 (Application) |
| 用例编排、事务控制、DTO 转换 |
+--------------------------------------------------+
|
+--------------------------------------------------+
| 领域层 (Domain) |
| 核心业务逻辑、领域模型、领域服务 |
| （不依赖任何外部技术框架） |
+--------------------------------------------------+
|
+--------------------------------------------------+
| 基础设施层 (Infrastructure) |
| 数据库实现、消息队列、外部服务调用 |
+--------------------------------------------------+
核心思想：领域层是最稳定的，不依赖其他任何层。
技术选型变更（换数据库、换消息队列）不会影响核心业务逻辑。四、SOA 与微服务
4.1 SOA 架构
SOA（Service-Oriented Architecture，面向服务架构）的核心理念是将系统拆分为可复用的服务，通过**企业服务总线（ESB）**进行集成：
+--------+ +--------+ +--------+
| 系统 A | | 系统 B | | 系统 C |
+---+----+ +---+----+ +---+----+
| | |
+---v-----------v-----------v----+
| 企业服务总线 (ESB) |
| 消息转换 | 协议适配 | 服务编排 |
+---+---+---+---+---+---+---+---+
| | | |
+---v--+ +--v---+ +-v----+ +v------+
|用户 | |订单 | |库存 | |支付 |
|服务 | |服务 | |服务 | |服务 |
+------+ +------+ +------+ +-------+SOA 的优势在于统一管理，但 ESB 容易成为系统瓶颈和单点故障。
4.2 微服务架构
微服务是 SOA 思想在互联网时代的演进，去掉了重量级的 ESB，强调去中心化治理：
API 网关
|
+-------+--------+--------+-------+
| | | | |
+------+ +------+ +------+ +------+ +------+
| 用户 | | 订单 | | 商品 | | 支付 | | 通知 |
| 服务 | | 服务 | | 服务 | | 服务 | | 服务 |
+--+---+ +--+---+ +--+---+ +--+---+ +--+---+
| | | | |
+--v---+ +--v---+ +--v---+ +--v---+ +--v---+
|用户DB| |订单DB| |商品DB| |支付DB| |消息DB|
+------+ +------+ +------+ +------+ +------+
每个微服务：
- 独立代码仓库
- 独立数据库
- 独立部署
- 独立团队维护4.3 SOA vs 微服务
| 维度 | SOA | 微服务 |
|---|---|---|
| 服务粒度 | 粗粒度（一个业务域） | 细粒度（一个业务能力） |
| 通信方式 | ESB（重量级） | REST/gRPC（轻量级） |
| 数据管理 | 共享数据库 | 每个服务独立数据库 |
| 治理方式 | 集中式（ESB） | 去中心化 |
| 部署方式 | 通常一起部署 | 独立部署 |
| 团队结构 | 按技术分工 | 按业务分工 |
| 适用规模 | 企业级系统集成 | 互联网应用 |
4.4 微服务的核心挑战
挑战 1：服务拆分粒度
太粗 -> 失去微服务的意义
太细 -> 分布式调用开销大，运维复杂
经验法则：一个微服务由 2-3 人团队负责（两个披萨团队）
挑战 2：分布式事务
单体架构中一个事务搞定的操作，微服务中可能跨多个服务
-> 需要 Saga、TCC 等分布式事务方案（第 6 章详述）
挑战 3：服务间通信
同步调用（REST/gRPC）导致链路过长
-> 引入异步消息（第 5 章详述）
挑战 4：运维复杂度
从 1 个应用变成 50 个应用
-> 需要容器化（Docker）+ 编排（K8s）+ 监控 + 链路追踪
挑战 5：数据一致性
每个服务有自己的数据库，跨服务查询困难
-> 事件溯源、CQRS 等模式4.5 微服务基础设施全景
+---------------------------------------------------------------+
| 微服务基础设施全景 |
+---------------------------------------------------------------+
| |
| 流量入口 API 网关 (Kong / Spring Cloud Gateway) |
| |
| 服务通信 同步: gRPC / REST |
| 异步: Kafka / RabbitMQ |
| |
| 服务发现 Consul / Nacos / Eureka / etcd |
| |
| 配置管理 Nacos / Apollo / Spring Cloud Config |
| |
| 负载均衡 客户端: Spring Cloud LoadBalancer 服务端: Nginx |
| |
| 熔断限流 Sentinel / Hystrix / Resilience4j |
| |
| 链路追踪 Jaeger / Zipkin / SkyWalking |
| |
| 日志聚合 ELK (Elasticsearch + Logstash + Kibana) |
| |
| 容器编排 Kubernetes / Docker Compose |
| |
| CI/CD Jenkins / GitLab CI / GitHub Actions |
| |
+---------------------------------------------------------------+五、中台架构
5.1 中台的由来
中台概念源于阿里巴巴的”大中台，小前台”战略（约 2015 年提出）。其核心观察是：不同业务线（淘宝、天猫、聚划算）有大量重复的能力建设（用户体系、交易流程、支付能力），将这些通用能力沉淀为中台，可以大幅提升效率。
值得注意的是，2020 年后阿里自身也对中台战略进行了反思和调整，逐步将”大中台”拆分为更贴近业务的独立单元，以解决中台响应慢、过度抽象等问题。这说明中台不是一劳永逸的方案，而是需要随组织和业务阶段持续演进的架构策略。
5.2 中台的分类
业务中台 数据中台 技术中台
+------------------+ +------------------+ +------------------+
| 用户中心 | | 数据采集 | | 微服务框架 |
| 交易中心 | | 数据仓库 | | 消息中间件 |
| 营销中心 | | 数据分析 | | 分布式缓存 |
| 库存中心 | | 数据服务 | | 任务调度平台 |
| 支付中心 | | 标签画像 | | 监控告警平台 |
+------------------+ +------------------+ +------------------+
提供业务能力复用 提供数据能力复用 提供技术能力复用5.3 中台的困境与反思
中台并非万能良药，很多企业在实施中台后遇到了新的问题：
| 问题 | 表现 | 根因 |
|---|---|---|
| 响应慢 | 前台业务需求排队等待中台支持 | 中台团队资源有限，优先级难以平衡 |
| 过度抽象 | 中台为了通用性做了过多抽象，使用复杂 | 没有在通用性和易用性之间找到平衡 |
| 组织壁垒 | 前台和中台之间出现部门墙 | 组织架构没有配合技术架构调整 |
| 投入产出比低 | 中台建设周期长、投入大，但收益不明显 | 业务线太少，复用价值不足以覆盖建设成本 |
什么时候适合建中台？
- 公司有 3 个以上业务线且有明显的能力重叠
- 团队规模 > 100 人
- 业务已进入稳定期，核心流程已沉淀
什么时候不适合建中台？
- 创业公司，业务还在快速探索期
- 只有 1-2 条业务线
- 团队 < 30 人
六、如何选择合适的架构
6.1 架构选型决策矩阵
| 因素 | 单体 | 垂直拆分 | 微服务 | 中台 |
|---|---|---|---|---|
| 团队规模 | < 10 人 | 10-30 人 | 30-200 人 | > 200 人 |
| 业务复杂度 | 低 | 中 | 高 | 多业务线 |
| 部署频率 | 低 | 中 | 高 | 高 |
| 技术栈多样性 | 单一 | 少量 | 多种 | 多种 |
| 运维能力 | 基础 | 一般 | 强 | 强 |
| 初始成本 | 低 | 低 | 高 | 很高 |
6.2 康威定律
“设计系统的组织，其产生的架构受限于组织的沟通结构。” 原文：“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” —— Melvin Conway, 1968
这意味着：架构设计必须与团队组织结构匹配。如果你要做微服务，但团队仍然按照前端、后端、测试来划分，微服务就很难成功。正确的做法是按业务域组建全功能团队。
反模式（技术导向团队）：
前端团队 --> 负责所有前端
后端团队 --> 负责所有后端
DBA 团队 --> 负责所有数据库
-> 跨团队沟通成本高，难以独立交付
正确模式（业务导向团队）：
用户团队 --> 前端 + 后端 + 数据库（用户域）
订单团队 --> 前端 + 后端 + 数据库（订单域）
商品团队 --> 前端 + 后端 + 数据库（商品域）
-> 各团队独立交付，沟通高效思考题
-
你所在的团队目前使用的是什么架构？如果要进行架构升级，你会选择什么方向？驱动升级的核心痛点是什么？
-
有人说”微服务是银弹”，也有人说”微服务是分布式单体”。你怎么理解微服务的适用边界？
结尾自测
-
架构演进的四个典型阶段是什么？每个阶段的驱动力是什么？
- 答：单体 -> 垂直拆分（代码耦合/数据库瓶颈）-> SOA/微服务（重复建设/ESB 瓶颈）-> 中台（跨业务线能力复用）。
-
SOA 和微服务在通信方式上的核心区别是什么？
- 答：SOA 依赖重量级的 ESB 进行集中式通信；微服务采用 REST/gRPC 等轻量级协议进行点对点通信，去中心化。
-
微服务架构中，“每个服务独立数据库”的原则带来了什么好处和什么挑战？
- 答：好处是服务间数据解耦、独立扩展。挑战是跨服务查询困难、分布式事务复杂。
-
康威定律对架构设计有什么指导意义？
- 答：架构设计要与组织结构匹配。做微服务就要按业务域组建全功能团队，而非按技术栈划分团队。
-
什么情况下不应该建中台？
- 答：创业公司、只有 1-2 条业务线、团队规模小、业务处于快速探索期。中台的建设成本高，只有当复用价值足够大时才有意义。
下一章预告：微服务之间如何高效通信？异步消息如何实现系统解耦？下一章我们将深入消息队列与异步架构。
购买课程解锁全部内容
面试晋升必学：11 章掌握系统设计
¥29.90