第二十五章 架构师之路

一

年度考核后的第二周，赵北辰给王志远发了一条消息：

"公司有一个架构师培养计划，我推荐了你。下周一去参加面试。"

王志远看到消息的时候，正在吃午饭，差点被饭噎住。

架构师培养计划是云智科技的内部人才培养项目，每年选拔 5-8 个有潜力的开发者，进行为期半年的系统性培训。培训内容包括系统设计、分布式架构、高可用方案、技术管理等。

通过培训并考核合格的人，会被授予"高级工程师"的职级，有机会在项目中担任架构师角色。

"赵哥，我才入职一年多，够资格吗？"

"资格不是看工龄，是看能力和潜力。你的年度考核是'优秀'，独立负责过核心模块，做过紧急项目的技术负责人。这些经历足够了。"

"但我对系统设计和分布式架构了解不多……"

"所以才要去学。培养计划就是让你从'写好代码'提升到'设计好系统'。"

二

面试比他想象的难。

面试官是公司的首席架构师老陈——一个头发稀疏但眼神锐利的中年人。

老陈没有问他具体的技术细节，而是给了他一个开放性的问题：

"设计一个短链接服务。用户输入一个长 URL，系统返回一个短 URL。当用户访问短 URL 时，系统重定向到原始的长 URL。日活用户 100 万，每天生成 10 万个短链接。"

王志远想了想，开始在白板上画。

他先画了整体架构：

用户 → 负载均衡 → Web 服务（无状态）→ 缓存（Redis）→ 数据库（MySQL）

然后他分析了几个关键问题：

1. 短链接生成算法：用 Base62 编码（a-z, A-Z, 0-9），6 位字符可以表示 62^6 ≈ 568 亿个短链接，足够用。
2. 唯一性保证：用自增 ID + Base62 编码，或者用哈希 + 冲突检测。
3. 读写比：读远大于写（用户访问短链接的频率远高于创建短链接的频率），所以要重点优化读性能。
4. 缓存策略：热门短链接放在 Redis 里，缓存命中率预计 > 90%。
5. 数据库设计：一张表，字段有 id、short_code、long_url、created_at、expires_at。

老陈听完，追问了几个问题：

"如果两个用户同时提交同一个长 URL，应该返回同一个短链接还是不同的？"

"如果数据库挂了怎么办？"

"如果 Redis 挂了怎么办？"

"如果日活从 100 万增长到 1000 万，架构需要怎么调整？"

王志远回答了前两个问题，第三个问题答得不太好，第四个问题只给出了一个大致的方向。

面试结束后，老陈说了一句："基础不错，但系统设计的思维还需要训练。你被录取了。"

三

培养计划的第一课，老陈讲了一个概念：CAP 理论。

"分布式系统有三个基本属性：一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）。CAP 理论说，这三个属性你最多只能同时满足两个。"

他在白板上画了一个三角形：

        C（一致性）
       / \
      /   \
     /     \
    A ───── P
（可用性）（分区容错性）

"在分布式系统中，网络分区（P）是不可避免的——网络总会出问题。所以实际上你只能在 C 和 A 之间选择：

• CP 系统：保证一致性，牺牲可用性。比如 ZooKeeper——当网络分区发生时，少数派节点会拒绝服务，保证数据一致。
• AP 系统：保证可用性，牺牲一致性。比如 Cassandra——当网络分区发生时，所有节点继续服务，但数据可能不一致。"

"那我们的短链接服务应该选 CP 还是 AP？"王志远问。

"你觉得呢？"

王志远想了想："短链接服务的核心需求是'用户访问短链接时能正常跳转'。如果因为一致性问题导致服务不可用，用户体验会很差。所以应该选 AP——保证可用性，允许短暂的数据不一致。"

"对。"老陈点头。"但'短暂的数据不一致'需要有一个兜底机制——比如最终一致性。数据最终会一致，只是可能有几秒钟的延迟。"

这就是BASE 理论——Basically Available（基本可用）、Soft State（软状态）、Eventually Consistent（最终一致性）。它是 CAP 理论在实践中的应用。

四

培养计划持续了三个月（后续还有三个月的实践阶段）。

每周两次课，每次两小时。内容涵盖了：

• 分布式系统基础（CAP、BASE、一致性协议）
• 高可用架构（主从复制、故障转移、限流熔断）
• 微服务架构（服务拆分、服务治理、API 网关）
• 数据库架构（分库分表、读写分离、分布式事务）
• 缓存架构（缓存策略、缓存一致性、多级缓存）
• 消息队列（Kafka、RabbitMQ、消息可靠性）
• 系统设计方法论（需求分析、容量估算、架构演进）

王志远每次课后都会花两个小时整理笔记，把学到的知识跟自己的实际项目经验对照。

他发现，很多他在项目中"凭直觉"做的决策，其实背后都有理论支撑。比如他在消息通知中心里用事件驱动架构，本质上就是一种"异步解耦"的模式；他在拆单功能里用乐观锁，本质上就是一种"乐观并发控制"策略。

以前他是"知其然不知其所以然"，现在他开始"知其所以然"了。

五

有一天课后，老陈跟他聊了一个话题：架构师的能力模型。

"好多人以为架构师就是画架构图的。"老陈说。"其实画图谁不会？架构师真正吃饭的本事是做决策。"

他在白板上画了一个能力模型：

架构师能力模型：
├── 技术深度：至少在一个领域有深入的理解
├── 技术广度：了解多种技术方案的优缺点
├── 系统思维：能从全局视角看问题，理解各部分的关系
├── 权衡能力：能在多个约束条件下做出最优决策
├── 沟通能力：能把技术方案讲给非技术人员听
└── 前瞻性：能预见系统的演进方向，提前做好准备

"其中最重要的是权衡能力。架构设计没有完美的方案，只有在各种约束条件下的最优方案。你要在性能和成本之间权衡，在一致性和可用性之间权衡，在简单和灵活之间权衡。"

"这跟技术选型很像。"王志远说。

"对。技术选型就是架构决策的一种。你之前做的 Spring Boot vs Quarkus 的对比分析，就是一个很好的架构决策过程——有数据、有实验、有权衡、有结论。"

王志远想了想："那架构师和高级开发的区别是什么？"

"高级开发关注的是'怎么实现'——用什么技术、怎么写代码、怎么优化性能。架构师关注的是'怎么设计'——系统怎么拆分、模块怎么交互、数据怎么流动、故障怎么处理。"

"简单说，高级开发是'把事情做对'，架构师是'做对的事情'。"

六

那天晚上，王志远坐在书桌前，面前摊着赵北辰留给他的架构师培养计划。

CAP、BASE、分布式一致性……这些词他以前在面试八股文里背过，但从来没有真正理解过。现在他开始明白了——架构师的核心能力不是画图，是做决策。在各种约束条件下，找到那个"没那么完美但最合适"的方案。

高级开发是"把事情做对"，架构师是"做对的事情"。一字之差，天壤之别。

他忽然有点理解赵北辰为什么总是在白板前站那么久了。不是在画图，是在做取舍。

:::{admonition} 小胖的笔记 :class: tip

本章知识卡片：系统设计基础

1. CAP 理论

实际选择：P 是必须的，所以在 C 和 A 之间选择。 - CP：ZooKeeper、HBase（强一致，可能不可用） - AP：Cassandra、DynamoDB（高可用，最终一致）

2. 系统设计面试框架

1. 需求澄清（5 分钟）
   - 功能需求：系统要做什么？
   - 非功能需求：QPS、延迟、可用性、数据量

2. 容量估算（5 分钟）
   - 日活用户、QPS、存储量、带宽

3. 高层设计（10 分钟）
   - 画架构图：客户端 → 负载均衡 → 服务 → 缓存 → 数据库

4. 详细设计（15 分钟）
   - 数据模型、API 设计、核心算法

5. 扩展与优化（5 分钟）
   - 缓存策略、数据库分片、CDN、监控

3. 架构师能力模型

:::