《极客时间教程 - 架构实战案例解析》笔记

架构的本质：如何打造一个有序的系统？

架构本质：通过合理的内部编排，保证系统高度有序，能够不断扩展，满足业务和技术变化。

• 出发点：业务和技术复杂化引起系统混乱，需通过架构保证有序
• 手段：“分”与“合”
  • 分：拆分为子系统、模块、组件
  • 合：基于业务流程和技术手段，有机整合组件

架构分类：业务架构、应用架构、技术架构

好架构的标准：

• 业务可扩展、可复用
• 高可用、高性能、可伸缩
• 低成本落地

架构师自我修养：

• 优秀的程序员
• 沟通交流（感性）
• 权衡取舍（理性）
• 多领域知识（技术广度）
• 技术前瞻性（技术深度）
• 看透问题本质（思维深度）
• 抽象思维（思维高度）

业务架构：作为开发，你真的了解业务吗？

从架构角度看，业务架构是源头，然后才是技术架构。

产品经理 vs 架构师：

• 产品经理：定义系统外观（告诉用户系统长什么样，告诉开发要实现什么功能）
• 架构师：将业务抽象为结构化的模块体系（拆分业务流程，按业务域划分系统模块，定义模块间关系）

架构目标之业务的可扩展

业务的主题是变化和创新，系统的主题是稳定和可靠。

架构目标之业务的可复用

实现业务可复用的三个关键：

1. 模块职责定位清晰：定位范围内的职责全部涵盖，范围外的全部不要
2. 数据模型和接口通用：归纳业务场景，抽象提炼通用化设计
3. 业务层次划分：底层业务相对固定，上层业务因场景而异

可扩展架构：如何打造一个善变的柔性系统？

系统构成：模块 + 关系

• 模块：子系统、应用、服务或功能模块
• 关系：模块之间的依赖关系

模块要求：定位明确、概念完整、自成体系、粒度适中

依赖关系要求：最好单向、最好层次化结构

模块围绕自身内部数据处理，对外部依赖越小，封装性越好，稳定性越强。

打造合理模块体系的手段：

• 拆分：实现模块划分
• 整合：优化模块依赖关系
• 模块通用化：减少模块数量，定位更清晰，职责更聚焦
• 业务平台化：抽取底层能力，统一提供服务

实践顺序：先垂直拆分（区分不同业务） → 再水平拆分（按业务流程细分）

可扩展架构案例（一）：电商平台架构是如何演变的？

电商平台架构发展的大致过程：

单体架构

• 单个应用，所有代码跑在一个进程，所有表在一个 DB
• 内部分层：表示层 → 业务层 → 数据访问层 → DB 层

分布式架构

• 多个独立应用互相协作，通过 API 接口调用
• 适用于业务相关性低、耦合少的业务系统

SOA 架构

• 传统 SOA：解决企业内部大量异构系统集成
• 新 SOA：解决系统重复建设
• 核心组件：ESB（企业服务总线），负责服务注册/路由、协议支持等

微服务架构

• 围绕业务划分清晰的数据边界，通过良好定义的接口输出能力
• 去中心化：不需要 ESB 集中管理
• 哑管道：通过 HTTP 等简单方式访问，避免重协议
• 智能终端：业务逻辑包含在微服务内部，不需要额外中间层

可扩展架构案例（二）：App 服务端架构是如何升级的？

V1.0 架构

问题：Jar 包紧密依赖、移动团队职责过杂、并行开发困难

V2.0 架构

问题：移动端和 PC 端互相干扰、重复造轮子、稳定性差

V3.0 架构

拆分每个业务线的服务端，App 接口和 PC 端接口物理独立，共享核心业务逻辑。

移动网关内部实现

• 通用层：系统级功能（协议适配、安全、监控、日志），封装为拦截器，可配置化
• 接口路由层：根据 URL 在配置文件中找到业务适配器，分发请求
• 服务适配层：内外部接口适配，可对多个内部服务做业务聚合，提供粗粒度接口

可扩展架构案例（三）：你真的需要一个中台吗？

• 前台：面向 C 端的应用，对外
• 后台：企业内部系统，对内
• 中台：实现基础业务平台化，实现企业级业务能力快速复用

中台的适用性

两种架构模式：

• “川”字型：各业务线并列独立建设

• “山”字型：抽取共同核心逻辑，实现通用化，一处建设多处复用

从“川”字型转为“山”字型的时机：

• 业务线数量：第 3 条业务线开始考虑
• 业务线相似度：相似度越高越适合“山”字型

中台的核心价值：

• 业务角度：收敛业务场景，统一业务规则
• 系统角度：相当于操作系统，提供标准接口，屏蔽底层复杂性
• 数据角度：收敛数据，统一数据模型

通过有限而固定的基础业务，满足无限而快速变化的上层业务场景。

演进路径：松散微服务 → 共享服务体系 → 中台

传统企业中台架构设计：

互联网 vs 传统企业：

• 互联网企业：有大量微服务基础，往中台转是改良，目的是更好地衔接前台和后台
• 传统企业：有大量遗留系统，落地中台是革命，目的是盘活老系统，实现数字化转型

可复用架构：如何实现高层次的复用？

复用层次（从高到低）：产品复用 > 业务流程复用 > 业务实体复用 > 组件复用 > 代码复用

• 技术复用：代码级 + 技术组件复用，通用性强但与业务场景远，复用价值相对较低
• 业务复用：
  • 业务实体复用：针对细分业务领域
  • 业务流程复用：针对业务场景
  • 产品复用：最高层次，对整个系统的复用

可复用架构案例（一）：如何设计一个基础服务？

核心：服务边界划分 + 功能抽象设计

可复用架构案例（二）：如何对现有系统做微服务改造？

三步法：

1. 圈表：确定微服务包含哪些表（确定数据模型）
2. 收集 SQL：收集所有访问这些表的 SQL（包括业务场景、访问频率）
3. 拆分 SQL：处理跨表关联查询，将非本服务的表关联拆分

可复用架构案例（三）：中台是如何炼成的？

核心问题：

1. 业务变化导致当前系统弊端明显，不能适应业务发展
2. 架构改造时需在业务、系统、资源三者间平衡，分步式改造

技术架构：作为开发，你真的了解系统吗？

• 业务架构解决功能性问题
• 技术架构解决非功能性问题
• 职责：系统所有组件的技术选型 + 确保组件正常运行

技术架构目标：高可用、高性能、伸缩性、安全性

高可用架构：如何让你的系统不掉链子？

故障分类：

• 资源不可用：网络故障（节点连接不上）、服务器故障（节点不能正常工作）
• 资源不足：高并发下节点无法正常工作，响应超时
• 功能问题：代码逻辑错误、接口不兼容、中间件不成熟

高可用策略：

• 事前：尽量避免问题发生
• 事中：转移故障，降低影响，快速恢复
• 事后：故障复盘，完善技术和流程

高可用架构案例（一）：如何实现 O2O 平台日订单 500 万？

高可用架构案例（二）：如何第一时间知道系统哪里有问题？

高可用架构案例（三）：如何打造一体化的监控系统？

高性能和可伸缩架构：业务增长，能不能加台机器就搞定？

性能优化方向：

• 加快单个请求处理：优化处理路径、并行处理
• 同时处理多个请求：负载均衡
• 请求处理异步化：MQ

性能提升思路：

• 可水平拆分 + 无状态
• 短事务 + 柔性事务
• 缓存
• 并行计算
• 异步处理
• 容器化

高性能架构案例：如何设计一个秒杀系统？

可伸缩架构案例：数据太多，如何无限扩展你的数据库？

案例：电商平台技术架构是如何演变的？

单体架构

SOA 架构

微服务架构

垂直拆分（分库）

水平拆分

多机房部署

服务调用本地化

依赖分级管理

多机房独立部署

从务实的角度，给你架构设计的重点知识和学习路径

参考资料

架构实战案例解析