徐术挺-漫思录

课程学习指南

30分钟阅读

阶段七 · 课程学习指南

本阶段按「架构方法论 → 高并发 → 分布式 → 领域建模 → 中台 → 云原生 → 新趋势 → 系统重构」组织。★ 为必学主干。

一、架构方法论

1. 从零开始学架构 ★（第一门，架构思维启蒙）

为什么学：这是极客时间最经典的架构入门课。它不讲具体技术，讲「架构的思维方式」——复杂度的来源、架构设计的三个原则、高可用/高性能/可扩展的设计模式。学完它，你才真正「会想问题」。

知识地图：

  • 架构的本质：解决「复杂度」问题（高性能、高可用、可扩展、低成本、安全）
  • 高性能架构模式：读写分离、缓存、CDN、消息队列、集群
  • 高可用架构模式：冗余、故障转移、限流降级、异地多活
  • 可扩展架构模式：分层、微服务、插件化、事件驱动
  • 架构设计三原则：合适、简单、演化
  • 架构设计流程：识别复杂度 → 设计备选 → 评估取舍

经典案例：小白问「为什么有的公司用 Redis 缓存，有的用 CDN，有的两个都用？」老师：「因为它们的复杂度和瓶颈不同。用户遍布全国、静态资源多 → 用 CDN（把内容搬到离用户近的地方）；热点数据高并发读 → 用 Redis（把数据库的压力挡在内存）。架构不是『堆技术』，而是『对着复杂度开药方』——先诊断，再开药。」

引发思考：

  1. 复杂度有哪几类来源？你现在的项目，复杂度主要来自哪类？
  2. 「合适、简单、演化」三原则，你能各举一个例子说明吗？
  3. 为什么说「没有最好的架构，只有最合适的架构」？

2. 许式伟的架构课 / 郭东白的架构课（选学，大师视角）

为什么学：许式伟（WPS 架构师）讲「架构的地基」——需求、数据、代码、基础设施层层推导；郭东白（原阿里 P11）讲「架构师的成长与判断」——架构决策、技术演进、组织协作。两门都是「高手心法」，适合有一定基础后再看。

知识地图（许式伟）：

  • 架构的地基：需求分析、数据建模、模块划分
  • 领域语言与业务建模
  • 架构演进：从单机到分布式
  • 代码架构：分层、接口、依赖
  • 基础设施：存储、网络、计算

知识地图（郭东白）：

  • 架构师的职责与价值
  • 架构决策的方法论（权衡、风险评估）
  • 技术演进与组织能力
  • 复杂系统的拆解与治理

经典案例：许式伟讲「数据是架构的中心」：「先想清楚『数据怎么流动』——从产生、存储、加工到消费，架构跟着数据走。你看 WPS 的云文档，核心不是『画界面』，而是『文档数据怎么在多端同步、怎么保证不冲突』。数据流想清楚了，代码结构自然就出来了。」

引发思考：

  1. 拿到一个需求，你第一步该做什么？（先建模数据还是先画界面？）
  2. 架构决策和普通技术选型的区别是什么？为什么架构师要「背锅」？
  3. 「架构是演化的」——你能举一个你见过或听过的「过度设计」案例吗？

二、高并发

3. 如何设计一个秒杀系统 ★（必学，高并发第一课）

为什么学：秒杀是高并发问题的「集大成者」：瞬间流量、防超卖、防刷、降级兜底。极客时间最经典的实战课之一。学完它，你拿到任何「高并发场景」都有了一套可复用的设计框架。

知识地图：

  • 秒杀系统的挑战：瞬时高并发、超卖、刷单
  • 架构分层：前端 → 网关 → 应用 → 缓存 → 数据库
  • 削峰：消息队列排队、答题/验证码、随机放量
  • 防超卖：Redis 原子操作、数据库乐观锁
  • 限流与降级：令牌桶、熔断、兜底
  • 静态化与 CDN、浏览器层拦截
  • 压测与监控

经典案例：秒杀 10 万并发，小白说「数据库加个锁不就行了」。老师摇头：「数据库每秒能扛的写操作就几千，10 万请求全打库直接宕机。正确的流程是：请求先进 Redis（原子扣减库存，防超卖），成功的人才进 MQ 排队，后端再异步落库。用户看到的『排队中』，其实是系统在『削峰』。你以为你在抢购，其实你在走一条精心设计的流水线。」

引发思考：

  1. 防超卖有几种实现？（DB 乐观锁 / Redis 原子操作 / 预扣库存）各自的利弊？
  2. 为什么秒杀要「静态化 + CDN」？静态资源和动态接口怎么分工？
  3. 秒杀系统为什么要「异步落库」？如果异步失败，订单丢了怎么办？（对账 + 补偿）
  4. 你能画出完整的秒杀架构图吗？每一层各自挡住什么流量？

4. 手把手带你搭建秒杀系统（选学，动手实现）

为什么学：上一门讲设计，这一门带你「真正写出来」——从项目骨架、Redis 扣库存、MQ 削峰到压测验证，全程动手。设计 + 实现结合，才是真掌握。

知识地图：

  • 秒杀项目搭建（Spring Boot 或 Go）
  • Redis 原子扣减与 Lua 脚本
  • MQ 削峰与异步下单
  • 限流、防刷（拦截器/网关）
  • 压测（JMeter）与调优
  • 监控与容错

经典案例：小白写完了秒杀接口，用 JMeter 压测，5000 并发直接崩溃。老师带着定位：「① 数据库连接池满了（改 Redis 前置）；② 日志打太频繁（异步日志）；③ 内存溢出（加大堆、优化代码）。一步步压测、一步步修，最终扛住 2 万并发。你要的不是『会背秒杀方案』，而是『亲手把一个方案调到能扛住』。」

引发思考：

  1. 压测从多少并发开始？怎么判断系统的「极限」？
  2. Redis Lua 脚本为什么能保证「检查库存 + 扣减」的原子性？
  3. 你压测出来的瓶颈，和你想的设计瓶颈一致吗？为什么？

5. 高并发系统设计 40 问 / 高并发系统实战课 / 李智慧高并发架构实战课（选学，体系补全）

为什么学：三门的侧重点：40 问是「高并发面试题集锦」（怎么回答面试官）；高并发实战课是「案例式教学」（电商、IM、直播等场景）；李智慧的课是「从 0 设计高并发系统」的完整方法论。按需选 1~2 门。

知识地图（40 问）：

  • 高并发系统设计套路：缓存、异步、池化、分流、限流
  • 分层架构、读写分离、水平扩展
  • 常见面试题精讲（如何设计一个高并发系统？）

知识地图（案例实战）：

  • 电商：商品、订单、支付、库存
  • IM：消息、推送、在线状态
  • 直播：弹幕、礼物、连麦
  • 通用方法论：容量规划、性能预估

经典案例：老师问小白：「如果面试官问『如何设计一个支持 10 万 QPS 的查询系统』，你 30 秒内能说清思路吗？」 小白支支吾吾。老师给模板：「① 静态化 + CDN 挡大头；② 加 Redis 缓存热点；③ 数据库读写分离 + 加索引；④ 服务无状态化，水平扩容；⑤ 限流兜底防雪崩。一句话一个点，五句话让面试官知道你『有系统思维』。」

引发思考：

  1. 「读多写少」和「写多读少」的系统，设计思路有什么不同？
  2. 容量规划：怎么估算一个系统要多少台机器？（QPS × 响应时间 / 单机能力）
  3. 高并发设计里，哪些是「必做」、哪些是「过度设计」？

三、分布式

6. 分布式技术原理与算法解析 ★（必学，分布式世界观）

为什么学：分布式是「现代架构的底层现实」——数据要复制、任务要分工、机器会故障。这门课把分布式的核心问题（一致、共识、容错、分布式事务）和核心算法（Raft、Paxos、Gossip、一致性哈希）讲清楚，让你「看任何分布式系统都能看懂它的设计」。

知识地图：

  • 分布式系统的挑战：网络不可靠、时钟不可靠、故障不可避免
  • 一致性：强一致、最终一致、CAP、BASE
  • 共识算法：Paxos、Raft、ZAB
  • 分布式存储：数据分片、复制、一致性哈希
  • 分布式事务：2PC、TCC、Saga、消息最终一致
  • 分布式锁、分布式 ID、分布式缓存
  • 分布式计算：MapReduce、任务调度

经典案例：小白问「为什么分布式系统里『两台机器对时间』那么难？」老师：「每台机器的时钟会漂移，网络传输有延迟，你没法让所有机器『同时』看到同一件事。所以分布式系统不谈『绝对时间』，只谈『先后顺序』——用逻辑时钟、用版本号、用一致性协议来达成『看起来一致』。记住一句话：分布式系统就是『一群各自为政的机器，努力装作一台机器』。」

引发思考：

  1. CAP 定理的「三选二」为什么是伪命题？（网络分区必然发生，只能在 C 和 A 之间选）
  2. Raft 和 Paxos 的区别？为什么工程界更爱用 Raft？（易理解、易实现）
  3. 一致性哈希为什么能解决「加机器导致大量数据迁移」的问题？
  4. 分布式事务为什么「能不用就不用」？最终一致性和强一致各自适合什么业务？

7. 深入浅出分布式技术原理 / 分布式系统案例课（选学，原理+案例）

为什么学：前者把分布式原理用通俗语言再讲一遍（适合巩固），后者用真实大厂案例（电商、支付、社交）讲分布式系统怎么落地。一原理一实战，搭配食用。

知识地图（案例课）：

  • 电商下单的分布式事务落地
  • 支付系统的幂等与对账
  • 社交 Feed 流的分布式存储
  • 分布式系统故障案例复盘（脑裂、数据丢失、时钟问题）

经典案例：某支付系统出现「重复扣款」事故，小白问「分布式下怎么保证不重复扣？」老师：「幂等 + 唯一约束。每个请求带一个全局唯一 ID（分布式 ID），数据库对『订单号 + 用户』建唯一索引，第二次来直接拒绝；再加一个『对账』任务，每天核对支付和订单两侧数据。分布式系统的可靠性，靠的是『设计兜底 + 事后对账』双保险，不是靠『不出错』。」

引发思考：

  1. 脑裂（split brain）是什么？为什么会出现？怎么解决？（多数派）
  2. 幂等键设计要注意什么？分布式 ID 的几种生成方案（雪花、UUID）优劣？
  3. 为什么说「对账」是金融系统的最后一道防线？

8. 分布式金融架构课（选学，高要求场景）

为什么学：金融系统是分布式技术的「炼狱」——高并发 + 强一致 + 合规审计 + 资金安全。学它，你会看到分布式技术在「最严格场景」下的样子。

知识地图：

  • 金融系统架构特点（账务、风控、监管）
  • 资金安全：幂等、对账、差错处理
  • 分布式事务在金融的落地
  • 两地三中心、容灾
  • 实时风控与反欺诈

经典案例：小白问「为什么银行转账的 SQL 敢用事务，而互联网公司老说『最终一致性』？」老师：「余额就是钱，银行必须强一致——同一笔钱不能被两个人花。而『点赞数』是弱一致——偶尔差几个无所谓。金融架构课教会你：先分清业务的一致性要求，再选择技术方案。一致性是需求，不是选择题。」

引发思考：

  1. 账务系统为什么用「余额 + 流水」双表？流水的作用是什么？
  2. 实时风控怎么在毫秒级判断一笔交易是否可疑？（规则引擎 + 特征 + 模型）
  3. 如果是你设计一个钱包系统，你会怎么保证「不丢账、不多账」？

四、领域建模（DDD）

9. DDD 实战课 ★（必学，业务建模）

为什么学：DDD（领域驱动设计）是「让技术跟着业务走」的建模方法论——把复杂的业务领域切成限界上下文、设计聚合和实体。微服务怎么拆？答案在 DDD 里。面试聊架构，DDD 是必聊话题。

知识地图：

  • 为什么需要 DDD：技术语言和业务语言的鸿沟
  • 战略设计：限界上下文、上下文映射、子域
  • 战术设计：实体、值对象、聚合、领域服务、领域事件
  • 领域模型与代码分层（四层架构、六边形架构）
  • DDD + 微服务：如何用 DDD 指导服务拆分
  • 落地案例与坑

经典案例：小白问「订单服务拆成一个微服务，合适吗？」老师：「不是『订单』一个服务，而是『下单这个业务场景』一个服务。DDD 的答案：先找限界上下文（比如『下单』和『物流』是两个上下文），每个上下文内部设计聚合（订单聚合里有订单、订单项、收件地址）。聚合是事务边界——聚合内的数据一起变、一起持久化。你用 DDD 建模后，微服务的边界就『长出来』了，而不是拍脑袋拆的。」

引发思考：

  1. 实体（Entity）和值对象（Value Object）的区别？地址是实体还是值对象？
  2. 聚合为什么是「事务边界」？聚合拆小了/拆大了分别有什么问题？
  3. 贫血模型和充血模型的区别？为什么 DDD 推崇充血模型？
  4. 你能对「电商下单」做一个完整的 DDD 建模吗？（画限界上下文 + 聚合）

10. 手把手教你落地 DDD / 如何落地业务建模（选学，实操）

为什么学：DDD 的理论和落地之间隔着一条鸿沟。这两门课用真实项目全程演示「怎么把一个业务一步步建出领域模型」，并给出代码分层示例，帮你把 DDD 用起来而不是背名词。

知识地图：

  • 事件风暴（Event Storming）工作坊方法
  • 从需求到限界上下文
  • 从模型到代码：领域层、应用层、基础设施层
  • 聚合设计实战
  • DDD 重构存量系统

经典案例：小白参加了一次「事件风暴」：大家把业务里发生的每一个事件（用户下单、支付成功、库存扣减、订单取消）贴满整面墙，顺着事件流找『界限』——事件在哪儿断裂，限界上下文就在哪儿。小白惊呼：『原来业务建模不是想出来的，是大家一起『画』出来的。』

引发思考：

  1. 事件风暴为什么从「事件」开始，而不是从「表」开始？
  2. DDD 落地最大的障碍是什么？（团队共识？重构成本？）
  3. 你的项目中，有哪些「技术语言绑架业务语言」的例子？

五、中台

11. 说透中台 / 数据中台实战课（选学，组织与架构）

为什么学：中台是「把多个业务共用的能力抽出来共享」的组织级架构。理解它，你就理解大厂「前台快、中台稳」的组织设计，也能分辨「真中台」和「伪中台」。

知识地图：

  • 中台的本质：复用 + 共享 + 沉淀
  • 业务中台 vs 数据中台 vs 技术中台
  • 中台建设的挑战（组织协调、边界划分）
  • 数据中台：数据资产、数据服务、指标体系
  • 中台的坑与反思（中台为什么会失败）

经典案例：小白问「我们公司也在搞中台，为什么越搞越乱？」老师：「中台的前提是『多个业务真的有共性』——淘宝、天猫、闲鱼共用账号、订单、支付，抽中台就值。如果只有一个业务，硬抽中台就是『为共享而共享』，多一层抽象多一层成本。中台失败的案例，90% 是『把中台当运动搞』，而不是『按业务共性长出来的』。」

引发思考：

  1. 「中台」和「微服务」的关系？中台是架构问题还是组织问题？
  2. 数据中台的核心资产是什么？（数据模型？指标体系？数据服务？）
  3. 你怎么判断一个公司「该不该建中台」？

六、云原生

12. 云原生架构与 GitOps 实战 ★（必学，云原生时代）

为什么学：云原生（容器 + K8s + DevOps + 可观测性）是当前后端架构的主航道。这门课教你用「云原生的方式」设计和交付系统：声明式管理、GitOps、服务网格、Serverless。

知识地图：

  • 云原生四要素：容器化、微服务、DevOps、持续交付
  • K8s 核心机制（声明式 API、控制器模式）
  • GitOps：用 Git 作为运维的唯一事实来源
  • 基础设施即代码（IaC）
  • 灰度发布、金丝雀发布
  • 可观测性：日志、指标、链路追踪

经典案例：小白问「GitOps 是什么？不就是 git push 吗？」老师：「对，但『一切』都走 Git：配置、部署清单、环境差异，全部代码化放在 Git 仓库里，改配置 = 提 PR = 走评审 = 自动同步到集群。谁改了什么、为什么改，全部有记录可审计。这比『运维在服务器上手动敲命令』靠谱一万倍——服务器只是 Git 的『执行者』，不再是『记忆』。云的哲学：一切皆代码，一切可回滚。」

引发思考：

  1. 声明式 API 和命令式操作的区别？为什么 K8s 用声明式？（以终态为准，系统自己对齐）
  2. GitOps 如何保证「生产环境与 Git 完全一致」？（持续同步 + 漂移检测）
  3. 云原生应用和「上了云的应用」有什么区别？（十二要素 vs 老应用搬上云）

13. 容器实战高手课 / Service Mesh 实战 / Serverless 进阶实战课（选学，云原生深化）

为什么学：容器课深入 Docker/容器运行时原理（镜像、网络、存储、隔离）；Service Mesh 课讲服务网格（Istio：流量治理、安全、可观测）；Serverless 课讲无服务器架构（FaaS、BaaS、按量付费）。按兴趣和方向选。

知识地图（容器）：

  • 容器原理：namespace、cgroup、镜像分层
  • 容器网络与存储
  • Dockerfile 最佳实践
  • 容器安全与调优

知识地图（Service Mesh）：

  • 服务网格是什么：sidecar 模式
  • Istio 架构与流量管理
  • 熔断、重试、灰度在网格层的实现
  • 可观测性（链路、指标、访问日志）

知识地图（Serverless）：

  • FaaS 与 BaaS、事件驱动
  • 冷启动与性能
  • Serverless 应用架构（前端、后端、数据处理）
  • 成本模型与选型

经典案例：小白问「有了微服务框架（如 Spring Cloud），为什么还要 Service Mesh？」老师：「框架的治理能力（熔断、限流、重试）是『代码里的库』——每个语言都要写一遍，升级框架要改代码重新发布。Service Mesh 把治理能力下沉到『独立进程（sidecar）』，业务代码只管业务，治理由网格统一管理——语言无关、升级无感。这就是『从代码治理到基础设施治理』的进化。」

引发思考：

  1. 容器和虚拟机共享内核 vs 隔离，安全边界在哪？
  2. Serverless 的冷启动怎么优化？（预留并发、精简依赖、语言选择）
  3. 你会在什么场景选 Serverless？什么场景坚决不选？（长任务、强延迟要求）

七、新趋势：区块链与 Web3

14. 说透区块链 / 深入浅出区块链 / Web 3.0 入局攻略（选学，认知扩展）

为什么学：区块链是「分布式技术的巅峰应用」——它把「互不信任的多个节点」通过共识达成一致。这三门课（一科普、一原理、一产业）让你建立对区块链和 Web3 的正确认知，不被概念收割，也能看懂相关岗位与机会。

知识地图（深入浅出区块链）：

  • 区块链本质：分布式账本 + 共识 + 加密
  • 比特币与以太坊
  • 智能合约（Solidity 入门）
  • 共识机制：PoW、PoS
  • 公链、联盟链、私有链
  • 区块链的应用与局限

知识地图（Web3）：

  • Web1/2/3 的演进
  • 去中心化身份、数字资产（NFT）
  • DAO、DeFi
  • Web3 的机会与泡沫

经典案例：小白问「区块链到底解决什么问题？」老师：「解决『信任』问题。传统转账要银行做『公证人』，区块链让全网节点共同记账——每个节点都有一本一模一样的账本，谁想篡改，其他节点立刻发现。代价是慢（比特币每秒 7 笔）、贵、耗电。所以区块链不是『万能数据库』，它是『不需要信任第三方』的数据库。理解它的适用边界，比会背概念重要。」

引发思考：

  1. 区块链和普通分布式数据库的本质区别是什么？（信任模型不同）
  2. 为什么说「区块链不是用来存大数据的」？（每个节点都要存全量副本）
  3. 智能合约有哪些安全风险？（重入攻击、整数溢出）——延伸到阶段十安全

八、系统重构

15. 遗留系统现代化实战 / 大型 Android 系统重构实战（选学，改造能力）

为什么学：现实世界没有「绿地项目」，工程师 80% 的时间在改老系统。这两门课教你：怎么评估遗留系统、怎么安全地拆分重构（绞杀者模式、 strangler fig）、怎么控制重构风险。

知识地图（遗留系统现代化）：

  • 遗留系统的典型问题（无测试、大泥球、技术债）
  • 评估与度量（如何证明重构的必要性）
  • 重构策略：绞杀者模式、防腐层、读写分离迁移
  • 增量重构与并行运行
  • 风险控制与回滚
  • 迁移到微服务/云原生的路径

经典案例：小白问「一个 10 年老系统，老板让拆微服务，怎么下手？」老师：「千万别『大爆炸式重构』——一次重写 99% 会死。用『绞杀者模式』：新功能用新架构写，老的先用防腐层包起来，一个一个模块迁移，新旧并行运行，逐步替换。每次小步迁移都保证可回滚。重构不是重写，是『在保住业务的前提下，一点点换地基』。」

引发思考：

  1. 「重构」和「重写」的分界线是什么？什么时候该劝老板别重写？
  2. 绞杀者模式为什么能降低风险？它的核心机制是什么？（渐进式替换）
  3. 没有测试的老代码，怎么敢改？第一步该做什么？（Characterization Test 表征测试）

本阶段小结

学完阶段七，你完成了「工程师 → 架构师」的关键一跃：

  • 有架构思维：知道复杂度在哪、怎么取舍；
  • 会高并发设计：秒杀系统信手拈来；
  • 懂分布式原理：CAP、共识、分布式事务不再虚；
  • 会用 DDD 建模：业务和技术之间架起桥梁；
  • 懂云原生：容器、K8s、GitOps、Serverless 门儿清；
  • 会改造老系统：不再怕接手「祖传代码」。

现在的你，已经能读懂绝大多数系统设计文档，也能在面试中讲出一套自洽的方案。但「设计得对」还不够，还得「跑得稳、坏得快发现」——下一阶段，学运维与性能。

下一站：08_阶段八_运维与性能/。