架构之路
从方法论到微服务的一站式导读
《架构整洁之道》教你怎么想，《大型网站技术架构》《亿级流量网站架构核心技术》教你怎么扛，《微服务设计》教你怎么拆，《架构即未来》教你组织怎么长。一条主线，把六本书炼成一站。
架构 = 对「改变」的投资
- 两大价值维度：行为价值（现在能用——功能正确）与结构价值（未来能改——易于变更）。只顾行为、不管结构，系统会越改越慢。
- 架构的首要目的：支撑系统的整个生命周期，让维护、升级、扩展的成本可控。
- 架构崩坏的信号：改一个小功能要动全局；回归测试越来越多；上线风险越来越大——说明结构价值已被透支。
- 架构决策就是投资：每一次「先快速实现、以后再重构」都是在向未来借债，架构师要负责这笔债不失控。
如果架构能让功能开发事半功倍，那么这个架构就是项目最大的红利；反之，它就是最沉重的债务。
—— 提炼自《架构整洁之道》（Robert C. Martin）评判架构好不好，不看它今天快不快，而看它明年还能不能快。
范式 = 被剥夺的能力
- 结构化编程（结构化剥夺 goto）：只留顺序、分支、循环 → 模块可被证明正确（可推导性）。
- 面向对象编程（OO 剥夺函数指针）：用多态取代函数指针 → 依赖可以反转，组件可以独立替换（多态解耦）。
- 函数式编程（函数式剥夺赋值）：变量不可变、无副作用 → 并发安全、行为可预测（不可变性）。
- 三大范式共同约束了什么不能做，而架构的本质正是把「不能做的事」变成架构纪律。
面向对象的多态让「依赖倒置」成为可能——这是整洁架构能成立的技术前提；函数式的不可变性则让并发与分布式（Part 2、3 的地基）安全得多。
从「类怎么写」到「包怎么分」
- SRP 单一职责：一个模块只对一类角色（一个变化原因）负责——不是"只做一件事"，而是"只为一个人变"。
- OCP 开闭原则：对扩展开放、对修改关闭——用接口+多态加新功能，而不是改老代码。
- LSP 里氏替换：子类型必须能替换基类型而不破坏正确性——继承不是"拿来用"，而是"能替换"。
- ISP 接口隔离：不强迫依赖方使用它用不到的方法——接口要小而专。
- DIP 依赖倒置：高层策略不依赖低层细节，两者都依赖抽象——架构层级的核心武器。
- 组件原则：REP（复用/发布同等）、CCP（共同闭包：一起变的放一起）、CRP（共同复用：不被一起用的不硬凑）；外加无环依赖——依赖图中不允许出现环。
把 SRP 理解成"一个类只写一个方法"（错）；把 DIP 理解成"多用接口"（浅）；真正的 DIP 是让依赖箭头从低层指向高层，由业务规则掌控方向。
业务规则永远在圆心
- 四层结构：Entity（企业业务规则）→ Use Case（应用业务规则）→ Interface Adapter（控制器/网关/展示器）→ Framework（数据库、Web、UI、框架）。
- 依赖方向：越靠外越"技术"、越靠内越"业务"；依赖箭头永远指向圆心。
- 跨边界通信：内层定义"边界接口"，外层实现它——数据库、Web、框架都可以被替换而不动业务。
- 延迟决策：数据库、Web、框架都是实现细节，可以留到最后再决定；业务规则先定。
- 边界（Boundary）是最有价值的投资：跨边界用接口+数据模型隔离，让变化只停留在某一层。
好的架构让「策略」和「细节」分离：策略是系统的灵魂，细节（数据库、Web、框架）只是随时可换的零件。
—— 提炼自《架构整洁之道》第 19–22 章「依赖倒置 + 延迟决策」正是 Part 3 微服务拆分、Part 4 架构评估的思想底座——所有架构决策都在回答同一个问题：变化发生在哪里，隔离就在哪里。
一部"加缓存、加机器、加服务"的进化史
- ① 初始阶段：应用与数据部署在同一台服务器，先解决"有没有"。
- ② 应用 / 数据分离：独立应用服务器 + 独立数据库服务器，各自垂直扩展。
- ③ 引入缓存：本地缓存 → 分布式缓存（Memcached/Redis），把热点读挡在数据库之外。
- ④ 应用服务器集群：多台应用 + 负载均衡，水平扩展处理能力。
- ⑤ 数据库读写分离：主库写、从库读，主从复制，把读流量摊开。
- ⑥ 反向代理 + CDN：反向代理缓存请求、CDN 就近分发静态资源。
- ⑦ 分布式存储：分布式文件系统（HDFS 等）+ 分布式数据库，容量不再受单机限制。
- ⑧ NoSQL + 搜索引擎：按场景选型——KV、文档、列族，加上搜索能力。
- ⑨ 业务拆分：按业务域把大系统切成小系统（垂直拆分）。
- ⑩ 分布式服务：把通用能力抽成独立服务（如用户、商品、订单服务）——微服务的雏形。
每个阶段都有代价：缓存有一致性成本、集群有状态管理成本、分布式有网络故障成本。演进要贴着瓶颈走，而不是一步到位。
九种模式，五大目标
- 九种模式：分层、分割、分布式、集群、缓存、异步、冗余、自动化、安全——每个模式解决一类典型问题。
- 性能：响应时间与吞吐量；手段：缓存、异步、CDN、代码与存储优化。
- 可用性：宕机时间趋零；手段：冗余（集群）、监控、自动化故障转移。
- 伸缩性：加机器就能提升能力（水平扩展）；前提：无状态设计。
- 扩展性：加新功能不动老代码；手段：分层、模块化、消息解耦。
- 安全性：XSS、注入、CSRF 等攻击的防御；手段：过滤消毒、参数绑定、Token 校验。
追求极致性能可能伤害可维护性；过度冗余抬高成本。架构的本质是在五大要素之间做权衡，并让权衡可被测量。
交易型系统的七条军规
- 无状态：应用不保存会话状态 → 任何一台机器都能接任何请求，这是水平扩展的前提。
- 拆分：按系统/功能/读写/AOP/模块多维度拆分，把大问题切成小问题。
- 服务化：通用能力抽成服务，独立部署、独立演进。
- 消息队列：服务解耦（一对多消费）、异步处理、流量削峰缓冲——注意处理消息失败与重复。
- 数据异构：用 MQ 监听数据变更，把数据同步到合适的存储（Redis/ES/KV），各系统用自己的数据形态。
- 缓存银弹：浏览器缓存 → APP 缓存 → CDN → 接入层（Nginx）→ 应用层 → 分布式缓存，层层拦截。
- 并发化：无依赖的任务并行执行，缩短单请求链路时间。
墨菲定律：凡是可能出错的事，一定会出错；康威定律：系统的架构就是沟通架构的翻版——两个定律决定了分布式系统必须把"容错"与"对齐组织"写进基因。
—— 出自《亿级流量网站架构核心技术》第 1 章缓存、降级、限流三件套
- 缓存：让大部分请求不到达后端；缓存是性能与可用性的第一道防线。
- 降级：丢卒保帅——关闭非核心功能，保证核心服务可用（哪怕有损）；关键是降级开关要能随时一键切换。
- 限流：防恶意流量与突发流量——恶意流量只打到缓存层；穿透的应用层用 Nginx limit 模块、IP deny 拦截。
- 切流量：机房/机架/服务器故障时快速切换：DNS 切机房入口、HttpDNS（APP 场景）、LVS/HaProxy 切接入层、Nginx 切应用层。
- 可回滚：事务、代码库、部署版本、数据版本、静态资源版本——任何变更都要有"后悔药"。
- 负载均衡五级：HTTP 重定向 → DNS → 反向代理 → IP 层（LVS）→ 数据链路层；算法：轮询、ip_hash、least_conn、一致性哈希。
- 健康检查：TCP 心跳 / HTTP 探测，配合失败重试（max_fails/fail_timeout）自动摘除故障节点。
可用性不是"不出故障"，而是故障时系统仍有兜底：缓存扛、降级保、限流控、流量可切、版本可回滚——五条一起，才叫高可用。
小，且自治
- 七大好处：技术异构性、弹性、扩展、简化部署、与组织结构匹配、可组合性、对可替代性的优化。
- 技术异构性：每个服务可以选最适合自己的技术栈——搜索用 ES、推荐用 Python、核心交易用 Java。
- 弹性与扩展：故障被限制在单个服务；只扩容热门的那个服务，而不是整个系统。
- 简化部署与可组合：小服务独立发布、独立回滚；能力可以被自由组合成新功能。
- 与组织结构匹配：康威定律——服务边界跟着团队边界走，小团队拥有小服务。
- 没有银弹：微服务带来分布式系统的全部难题——网络故障、数据一致性、运维复杂度，代价必须被正视。
微服务的前提是单体已经无法承载团队与流量。没有明确的业务边界就拆，只会把单体问题变成"分布式单体"。
好服务 = 松耦合 + 高内聚
- 松耦合：服务之间尽量少知道彼此——改 A 不需要动 B，A 挂了 B 尽量不受影响。
- 高内聚：强相关的行为放在一起——一个业务能力及其数据，应该在同一个服务内闭环。
- 限界上下文（Bounded Context）：来自 DDD——同一个概念在不同上下文里有不同含义（"订单"在销售、仓储、财务语境下是三种东西）。
- 按业务功能划分：从业务能力出发找边界，而不是"把 controller/service/dao 拆成三个微服务"。
- 过早划分：业务还没摸清就拆，是微服务最常见的失败原因——先收敛边界，再切服务。
- 技术边界是陷阱：按"接口层、业务层、数据层"拆出来的服务，只会放大分布式问题。
从业务能力出发列候选服务清单；给每个服务画出它的数据归属；先用模块化单体验证边界（《微服务设计》的建议），边界稳定了再物理拆分。
让服务"会说话"
- 共享数据库是反模式：表面解耦、实则共享一切——改表结构就牵动所有服务。
- 同步 vs 异步：同步（REST/RPC）直观但链路脆弱；异步（消息）解耦削峰但一致性难。
- RPC 的三大陷阱：技术耦合（语言绑定）、本地调用 ≠ 远程调用（网络延迟/超时）、脆弱性（链上任何一环挂掉整体失败）。
- REST：用 HTTP 语义暴露资源，技术无关、易于消费；注意超媒体与合理的约定数量。
- 事件驱动：服务发布"事件"，其他服务订阅——发布者不知道谁在听，天然解耦。
- 编排 vs 协同：编排=中心指挥（一个服务串流程，简单但中心化）；协同=各自响应事件（去中心但难追踪）。
- 版本管理：能推迟就推迟；必须变时优先向后兼容（加字段、语义版本号），再考虑双版本共存。
本地调用和远程调用并不相同：远程调用有网络延迟、会超时、可能部分成功——把它当本地调用写，是分布式系统最贵的学费。
—— 提炼自《微服务设计》第 4 章最难的两个字：一致、容错
- 数据库 per 服务：数据所有权跟着服务走，才能真解耦；共享库会让"微服务"名存实亡。
- Saga（长事务/补偿事务）：把一个大事务拆成一组本地事务，失败时按逆序执行补偿动作（如"扣款失败→取消订单"）。
- CQRS：读写分离模型——写模型保证一致性，读模型针对查询优化，中间靠事件同步。
- 事件溯源（Event Sourcing）：把状态变化记录为事件流，状态可随时重放——审计友好、逻辑清晰，但心智成本高。
- 熔断器（Circuit Breaker）：下游连续失败时"断开"，快速失败而非拖死调用方；半开试探恢复。
- 重试与隔离：超时 + 有界重试（防雪崩）；舱壁隔离（Bulkhead）——每个依赖独立的连接池/线程池，一个挂了不拖垮全部。
- 可观测三支柱：日志（Logs）、指标（Metrics）、分布式追踪（Traces）——微服务没有它就像蒙眼开车。
超时设上限、重试有上限（且要退避）、依赖要隔离——再加一板斧：能降级就降级（Part 2 的三件套在微服务里同样适用）。
扩展性首先是组织问题
- 组织扩展成本：团队越大，沟通链路越多，个人平均产出下降——规模不经济从"组织"开始。
- 披萨团队规则：团队规模不能大于"两张披萨能喂饱的人数"（约 6–8 人）——小团队沟通成本低、响应快。
- 敏捷型组织结构：在职能型/矩阵型基础上演进——团队自主管理、自给自足，快速响应市场。
- 领导 vs 管理：管理是"推"（pushing，推动执行），领导是"拉"（pulling，设定方向）；领导定目的地与路线图，管理设法到达。
- 股东价值视角：技术团队要能用指标回答"IT 工作对业务意味着什么"——理解业务的挑战、风险与策略。
- 扩展立方体（AKF Scale Cube）：X 轴克隆（水平复制）、Y 轴功能拆分（按业务切服务）、Z 轴数据分片（按数据切分）——扩展的三种基本招式。
一个球队要成功，必须有好队员（人员）、好阵型（组织）、好战术（流程）——系统扩展的道理一模一样。
—— 出自《架构即未来》读书笔记（博客园）「系统架构是沟通架构的翻版」——想要微服务边界清晰，先让团队边界清晰；组织怎么分，系统就怎么长。
架构 = 质量属性的权衡记录
- 质量属性清单：可用性、可修改性、性能、安全性、可测试性、可部署性、可伸缩性等——没有哪个系统能全部拉满。
- 质量属性场景（QA Scenario）：六要素——刺激源、刺激、环境、工件、响应、响应度量；把"要快"翻译成"90% 请求在 200ms 内返回"。
- 架构视图（Views）：模块视图（代码怎么分）、组件-连接视图（运行时怎么协作）、部署视图（跑到哪些机器上）——单一视图永远讲不清架构。
- ATAM（架构权衡分析方法）：通过场景驱动的架构评估，找出风险点（Risk）与权衡点（Tradeoff），在重大投入前发现问题。
- 架构决策要留痕：ADR（架构决策记录）——为什么选 A 不选 B，后人才能"知其所以然"地演进。
架构问题在部署后才发现，修复成本是指数级的。ATAM 的价值是在画大饼之前，先把风险点和权衡点摆上桌面。
演化式架构师：定原则，而不是当独裁者
- 战略目标 → 原则 → 实践：先有战略目标（如"快速上线"），导出原则（如"API 向后兼容"），再落到实践（如"语义化版本"）。
- 三条硬标准：监控（没有监控就没有发言权）、接口（接口契约是团队的宪法）、架构安全性（安全不是事后补丁）。
- 代码治理靠示范：裁剪服务模板、树立范例，而不是靠"禁止令"——好架构是"长"出来的。
- 技术债务管理：债务不可怕，可怕的是无记录的债务；建清单、定偿还计划、设例外流程。
- 能力模型：技术深度 × 业务理解 × 沟通协调 × 决策担当——四象限缺一不可。
- 像领导一样"拉"：设定目的地与路线图（愿景与原则）；像管理者一样"推"：让原则落地为纪律（评审与度量）。
Part 1 教你把系统设计"整洁"（方法论），Part 2 教你把流量扛住（高并发），Part 3 教你把系统拆开（微服务），Part 4 教你把组织带大（演进）——架构之路没有终点，只有下一段路。
依赖倒置DIP
高层策略不依赖低层细节，两者都依赖抽象；依赖方向由调用方掌控。
开闭原则OCP
对扩展开放、对修改关闭：加功能不动老代码。
限界上下文Bounded Context
DDD 概念：一个概念在不同业务上下文有不同语义，上下文即服务边界。
康威定律Conway's Law
系统架构是组织沟通结构的翻版——团队怎么分，系统就怎么长。
墨菲定律Murphy's Law
会出错的事一定会出错——分布式系统默认一切都会失败。
Saga长事务
把跨服务事务拆成局部事务序列，失败时逆序补偿，达到最终一致。
CQRS读写分离模型
写模型保证一致性，读模型针对查询优化，中间用事件同步。
事件溯源Event Sourcing
状态由事件流推导而来，可重放、可审计。
熔断器Circuit Breaker
下游故障时快速失败（断开），超时后半开试探，防雪崩。
幂等Idempotency
同一操作执行多次结果一致——消息重试、重复请求的必备设计。
降级Degradation
丢卒保帅：关闭非核心功能，保证核心可用（哪怕有损）。
限流Rate Limiting
限制单位时间请求量，防恶意流量与突发峰值冲垮系统。
缓存穿透
查询不存在的数据，缓存永远不命中，压力直达数据库——用空值缓存/布隆过滤解决。
缓存雪崩
大量缓存同时失效，请求全部打到数据库——错峰过期 + 多级缓存。
无状态Stateless
应用不保存会话状态，任意节点可接任意请求——水平扩展的前提。
服务发现Service Discovery
服务实例动态注册与发现，配合负载均衡，解决"地址会变"的问题。
API 网关API Gateway
微服务的统一入口：路由、鉴权、限流、聚合——给客户端一个门面。
编排 Orchestration
中心指挥者串起业务流程：简单可控，但中心成为瓶颈点。
协同 Choreography
各服务响应事件自行协作：去中心，但流程难追踪。
可观测性Observability
日志 + 指标 + 分布式追踪，让分布式系统"看得见"。
质量属性场景QA Scenario
六要素描述一个质量需求（刺激源→刺激→环境→工件→响应→度量），让它可验证。
ATAM
架构权衡分析方法：场景驱动的架构评估，识别风险点与权衡点。
扩展立方体AKF Scale Cube
X 克隆、Y 拆分、Z 分片——扩展的三种基本维度。
披萨团队Two-Pizza Team
团队规模以"两张披萨喂饱"为上限（6–8 人），控制沟通成本。
| 书名 | 作者 | 本站在哪一部分 | 正版阅读（微信读书） |
|---|---|---|---|
| 《架构整洁之道》 | Robert C. Martin | Part 1 方法论 | 微信读书 |
| 《大型网站技术架构：核心原理与案例分析》 | 李智慧 | Part 2 高并发 | 微信读书 |
| 《亿级流量网站架构核心技术》 | 张开涛（开涛） | Part 2 高并发 | 微信读书 |
| 《微服务设计》 | Sam Newman | Part 3 微服务 | 微信读书 |
| 《微服务架构设计模式》 | Chris Richardson | Part 3 微服务 | 微信读书 |
| 《架构即未来：现代企业可扩展的Web架构、流程和组织》 | Martin L. Abbott 等 | Part 4 组织与演进 | 微信读书 |
| 《软件架构实践》 | Len Bass 等 | Part 4 组织与演进 | 微信读书 |
本站全部图解为原创 SVG，要点文字为对原书内容的提炼改写。建议通过微信读书等正版渠道阅读全书，支持作者。