架构师的成长输入

发表于 2025-09-29 分类于架构师

架构师学习第1篇

写在前面

以前，我相信代码即真理。作为一名专注于实现的技术专家，我聚焦于代码写得足够好，我就牛逼。直到我加入这家初创公司，成为研发负责人，现实给了我更复杂的挑战。

我们没有预算去组建豪华的架构团队，我不得不从微观的代码世界抬起头，开始被迫去思考那些我不曾涉足的宏大命题：技术选型、系统边界、网络安全、以及如何在资源捉襟见肘时支撑复杂的业务增长。

这不是一个“资深架构师下凡”的故事，而是一个“写代码的手艺人被迫去画图纸”的记录。

正因为我没有科班架构师的思维定式，我是带着“代码的触觉”去搭建系统的。我更加警惕过度设计，更加关注落地的成本。在本书/本文中，你看到的不仅是技术的选型，更是一个工程师在理想与现实、代码洁癖与商业速度之间，无数次权衡后的真实思考。

这一系列风格大概率就会以记录或碎碎念的方式呈现，估计没什么章法。

必读神书：
- 《数据密集型应用系统设计》 (Designing Data-Intensive Applications - DDIA)
  - 评价： 架构领域的“圣经”。Martin Kleppmann 把分布式系统、数据库原理、一致性哈希、CAP 理论讲得极为透彻。
  - 你的关注点： 不要只看结论，要看它对不同存储引擎（B-Tree vs LSM-Tree）、事务隔离级别、流处理的深度剖析。这对于你理解 Minio、SeaweedFS 这类分布式存储的底层逻辑至关重要。

[Image of Designing Data-Intensive Applications book cover]

现代架构模式：
- 《软件架构：架构模式、特征及实践》 (Fundamentals of Software Architecture)
  - 评价： O’Reilly 出品的红皮书。它系统性地定义了架构风格（微内核、微服务、事件驱动、基于空间等）及其适用场景。
  - 核心价值： 帮你建立系统的“评估维度”（如可扩展性、弹性、性能、成本），学会用雷达图来做技术选型。

架构师不仅要懂技术，更要懂业务。

领域驱动设计 (DDD)：
- 推荐阅读： 也就是 Eric Evans 的蓝皮书（太晦涩，建议当字典查）或者 Vaughn Vernon 的《实现领域驱动设计》（红皮书，更实战）。
- 关键点： 限界上下文（Bounded Context）、聚合根（Aggregate Root）、防腐层（ACL）。
- 实战意义： 当你在做 SaaS 或 CRM 系统时，DDD 能帮你厘清微服务的边界，避免微服务变成“分布式单体”。
可视化与沟通：C4 模型
- 架构师的一大工作是沟通。UML 太重，白板太乱。
- C4 Model (Context, Containers, Components, Code): 由 Simon Brown 提出。它像谷歌地图一样，从宏观（系统全貌）到微观（类图）分层展示。
- 建议： 以后做设计评审（Design Review），尝试用 C4 画图，你的专业度会瞬间提升。

作为现在的架构师，如果不考虑 AI，设计就是过时的。你需要思考如何把 LLM 融入现有架构。

RAG (检索增强生成) 与 Agent 架构：
- 不要只盯着模型微调，重点关注 向量数据库 (Vector DB) 的选型与 Context Window 的管理。
- 学习 LangChain 或 LangGraph 的设计理念（尽管你可能不直接用 Python 写生产代码，但思想通用）。
- 思考题： 如何设计一个架构，既能处理传统的 CRUD 业务，又能低延迟地响应 AI 推理请求？如何处理 AI 的非确定性输出？
架构演进：
- 从 DevOps 转向 **Platform Engineering (平台工程)**。
- 关注 IDP (Internal Developer Portal) 的构建，让开发人员自助服务，架构师负责制定标准和“铺路”。

架构师是技术团队的政委。

ADR (Architecture Decision Records)：
- 强烈推荐： 开始在你的项目中使用 ADR。
- 是什么： 记录每一个架构决策的背景、选项、决策结果、后果（好的和坏的）。
- 为什么： 解决“为什么当初那个傻X选了这个方案”的问题。它是架构师的“免责声明”和团队的知识资产。
技术影响力：
- 阅读 **《技术管理模式：像在谷歌一样进行软件工程》 (Software Engineering at Google)**。了解大规模团队如何做代码评审、发布管理和知识共享。

为了节省你的时间，我只推荐最高质量的信息源：