课程地图:八组共 31 个概念

一张地铁线路图:先看到全部线路,再一站一站地坐过去。

架构不是一堆技术——而是一组动手写代码之前要问的问题。每个问题在业内都有自己的名字:Trade-offs、Coupling、Idempotency、ADR。本课把它们归成八组——第 1–8 章依次讲这八组。

怎么读这门课

护照:每本的栏目都一样,所以容易比较。

每个概念都按同一套方式讲:它的规范名称(记住它——这是你要去搜索的词,也是面试里会被问到的词)、一个生活中的画面、一张图,以及一张带栏目的卡片:是什么、为什么、例子、陷阱(人们通常在哪里出错)和关联概念。每章以它的关键问题收尾;全课以检查清单和速查表收尾。

Problem Framing — 质疑任务,而不只是质疑方案

病人进门就要一张处方。好医生先问哪里疼——也许会发现,他点名要的那种药本来就开错了。

当有人说"做 X"时,工程师问"我该怎么做 X"。架构师问的是**"我们为什么需要 X,有没有别的东西能解决真正的问题"**。这就是 problem framing(界定问题)。任务常常本身就提错了——而某人点单要来的那个方案,一年后变成了问题本身。

Long-term Thinking — 以年为单位的视野,为后果负责

工程师为周六要搬进来的那家人盖房子。架构师则问:"等他们有了第三个孩子呢?等母亲搬来同住呢?等他们想把一楼出租呢?"

工程师解决被提出来的那个问题。架构师解决三年后它会变成的样子那个问题。这意味着:为还没用上的能力做设计,同时刻意舍弃那些听起来优雅、却永远用不上的能力。

木匠把钉子钉歪了,一天就能修好。架构师把承重墙放错了位置,房子修不了——只能将就着住。

所以架构师要为后果负责,而不是为代码负责。工程师的错误,一周就能修好。架构师的错误,公司要为它付好几年的账——付在技术债里、付在流失的团队里、付在错过的机会里。架构师必须在第一行代码写下之前就想清楚,并且有勇气在架构扛不住真实需求时叫停工程。

Trade-offs — 每个决策都有得有失

自行车比走路快,但下雨会淋湿。汽车淋不着,但会堵在路上。地铁不堵,但不能送到家门口。

工程师选技术时,常常想找"最好的"。这是幻觉。架构师知道:任何选择都是在好几条轴线上的取舍——开发速度对可维护性,简单对灵活,现在的成本对三年后的成本。把轴线说出来、有意识地选择,就是架构工作。

Simplicity (KISS) — 简单的方案几乎总是更对

瑞士军刀什么都能干,但都干得不好。一把好刀,比军刀里所有的兄弟都切得好。

工程师怕漏掉需求,就把系统塞满将来可能用得上的一切。架构师知道:每一项没人用的能力,都是开发上的一笔长期税。复杂度要有意识地引入,有理由才引入;默认选——简单、容易改的方案。这条原则常被称为 KISS —— Keep It Simple, Stupid。

Reversibility — 难以撤销的决策值得更多关注

在餐厅,点错的菜可以退。婚礼上说出的"我愿意",退不了。

架构决策并不都一样——出错的代价不同。选编程语言或数据库,几乎无法撤销。选日志库,一天就能换掉。架构师把不成比例的时间花在不可逆的决策上,可逆的则快速推进。业内常把它们叫作单向门(one-way door)和双向门(two-way door)。

Technical Debt — 是有意识的选择,不是偷懒

企业贷款没问题,只要你知道什么时候、怎么还。没有还款计划的贷款,是通往破产的路。

有时此刻正确的做法,是先交付一个以后得重写的东西。这就是 technical debt(技术债)。这很正常。不正常的是不承认它是债。 架构师会写下:做了哪些取舍、为什么、什么时候必须回头处理。

Decomposition — 架构师的核心技能

一头鲸鱼没法整个吃下去。切成能放进嘴里的小块,就可以了。

大系统是无法理解的。Decomposition(分解)就是把它切成几部分的技能。好的架构,是一组小部件,每个都能单独看懂。如果解释一个组件还得牵出另外三个——这个分解就是坏的。

Cohesion & Coupling — 内部高内聚,外部低耦合

一套好公寓:厨房围绕一个目的组织(灶台挨着水槽),和邻居只共用一面墙。

一个模块内部,所有东西都应该围绕一件事——这是高内聚。模块之间——通过清晰的接口、接触降到最少——这是低耦合。如果你改了一个模块,却得去动另外五个——它们之间的耦合就太高了。

Layers & the Dependency Rule — 分层讲的是依赖的方向

房子的楼层:三楼立在二楼上,二楼立在一楼上,一楼立在地基上。你不能把地基放到三楼上。

在好的架构里,业务逻辑不知道数据库、网页界面或框架的存在。内层不依赖外层——这就是依赖规则(dependency rule)。需要换数据库或框架时,业务逻辑原封不动。这就是一句话讲完的 Clean Architecture。

Interface over Implementation — 接口比实现更重要

你不在乎大楼里电梯是什么牌子。你在乎的是按钮的用法始终一样、门开得可靠、声音安静。

一个模块和另一个模块对话时,重要的是它们之间的契约(接口),而不是对方内部怎么造的(实现)。先设计边界(API、类的接口、消息格式),再做实现。实现可以随便换;契约只有在完全清楚代价时才能改。

Monolith vs Microservices — 是成熟度的问题,不是潮流

一个厨师在小厨房里做一道菜,比十个厨师在 Slack 上商量着做还快。每小时一百道菜,十个厨师就做得更好。

单体(monolith)是整体部署的一个应用。微服务(microservices)是许多小服务,各自独立部署。微服务解决的是组织规模和负载的问题,不是代码质量的问题。小团队上微服务,是没人要的复杂度。架构师从单体起步,真的出现痛点时再拆,而不是"因为流行"。

Data Model — 它比其他一切都活得久

房子的地基,比一个世纪里盖在它上面的所有墙和屋顶都活得久。

语言会过时,框架会更替,界面会被重画十遍。一开始定下的数据模型会留下来——因为在运行中的系统上改它,代价极高。它是架构师最先花时间的东西,也是最后才急着去改的东西。

Single Source of Truth — 每个事实只住在一个地方

如果家里每个人都有自己的购物清单,会有两个人去买牛奶,没人去买面包。

同一份信息放在两个地方,必然走向不一致。**single source of truth(SSOT,单一事实来源)**原则:架构师要确定系统里每个事实住在哪里。如果数据被复制了(比如为了性能),就必须明确:哪个是事实来源,哪个是缓存或投影。

State — 是复杂度;越少越好

干净的桌面让工作更轻松。杂乱的桌面逼你记住东西在哪,还不断让你分心。

存在某处的每一份状态,都是可能失去同步、丢失、或与其他状态矛盾的东西。好的架构追求无记忆的函数(stateless,无状态)和生命周期短的变量。状态只留在真正需要它的地方——通常是数据库。

Transactions — 意图的原子性

转账是两个动作,但只有一个意图。要么两次写入都发生了,要么都没发生。只做一半就是灾难。

当几个改动必须作为一个整体发生时,就需要事务(transaction)。这种性质叫原子性(atomicity)。架构师知道系统里哪些操作是原子的、哪些可能只失败一半,以及如何与之共处。在分布式系统里,这成了核心问题(two-phase commit、saga、idempotency)。

Cache — 第二份“真相”,而且它会说谎

冰箱上的日历比看手机快。但如果有人在手机上改了日程——冰箱上的那份就已经在说谎了。

缓存(cache)带来速度,却拿走了新鲜度的保证。架构师始终要清楚:缓存了什么、缓存多久、缓存说谎了会怎样。缓存最难的问题不是怎么加——而是怎么让它失效(cache invalidation)。

API Contract — 系统的边界是契约,不是代码

国与国的边界不是一道栅栏——而是一套规则:什么可以带过去、谁可以入境、需要什么护照。

API、消息格式、文件格式——这些是对所有使用者的承诺。改契约,就是改承诺,代价很高。好的架构师设计契约时,会让它能扩展而不破坏现有的客户端(加字段,绝不删字段)。这种性质叫向后兼容(backward compatibility)。

Sync vs Async — 在时间上选择怎样耦合

打电话:双方必须同时在线。写信:收信人方便的时候再读。

同步(synchronous)调用把两个服务在时间上绑在一起:接收方挂了,发送方也卡住。通过队列的异步(asynchronous)消息打破了这种绑定:发送方把信放下就继续往前走。这带来韧性,但也增加复杂度——延迟、重复、顺序问题。

Idempotency — 一个操作可以放心地重复执行

有人叫电梯去三楼。就算十个人再按一遍同一个按钮,电梯还是去三楼,什么也不会坏。

在真实的系统里,调用会被重试——因为超时、网络故障、重启。幂等(idempotent)的操作,重复执行结果不变。一个重试起来很危险的操作,是一颗定时炸弹。 架构师默认把关键操作(支付、消息处理)做成幂等的。

External Dependencies — 永远是风险

如果晚饭靠街对面的披萨店——没什么大不了,还有备选。如果靠全城唯一的肉类供应商——就是要命的事。

每一个外部依赖——API、服务、库——都可能宕机、变慢,或者改了它的契约。架构师要决定出现这些情况时会怎样:整个系统倒下,还是降级继续运行?通常值得把外部依赖隔离在你自己的一层(adapter,适配器)后面——这样以后才能替换。

Security — 不是一个功能,而是系统的生活方式

在博物馆里,安全不是门口的一个摄像头——而是层层设防:闸机、保安、每个展厅的摄像头、展柜上的锁。

安全(security)没法在最后才补上。它要建在每一层:认证、授权、加密、隔离、审计、最小权限。这种分层的做法叫 defense in depth(纵深防御)。架构师从第一天就考虑它,在每个决策上都问:"如果攻击者从这里进来了呢?"

载三个人的出租车,不该像高铁那样跑。高铁也开不进小巷。

"让它快一点"是毫无意义的需求。架构师用数字来表述性能(performance):每秒多少请求(throughput,吞吐量),能容忍多大延迟(latency),高峰时系统表现如何,超过上限会发生什么。过早优化是浪费;完全不考虑则是灾难。

Scalability — 不重写也能增长的能力

设计时就留了加盖二楼余地的房子,可以不拆就扩建。没留这个余地的房子——只能推倒重建。

Scalability(可扩展性):系统必须朝两个方向增长——更多的用户(横向——加服务器)和更多的功能(模块化——加模块而不破坏旧的)。这要在设计时就埋进去,而不是事后补。

Reliability — 系统出故障时的表现

好船不是不会沉的船(那样的船不存在)——而是有十个隔舱的船,一个被撞破了,其余的仍然浮着。

系统的每个部分终究都会坏。Reliability(可靠性)不是"永远不坏"——而是"坏了也能扛住"。架构师不试图阻止故障——而是设计系统怎样扛过故障:故障隔离、重试、优雅降级、fallback。首要规则:一个组件的故障,不能搞垮整个系统。

Observability — 看不见的东西,你修不了

一辆车,没有油量表、没有温度计、没有机油压力指示灯。一路开到彻底趴窝。

Observability(可观测性):系统必须讲出自己的状态——日志(logs)、指标(metrics)、链路追踪(traces)。凌晨三点出了问题,你只有几分钟去找原因。如果一开始没有设计可观测性,事后再加就晚了——你连该看哪里都不知道。

Evolvability — 为变化做好准备,比今天正确更重要

在一座新城里,马路修得比今天需要的更宽。十年后车多了,窄路就得拆掉重修。

架构师不试图预测未来的每一个功能(做不到)。他们留出余地,让新功能能加进来而不破坏现有的东西。这种性质叫 evolvability(可演进性)。实践中意味着:边界清晰、契约可扩展、把"做什么"和"怎么做"分开。

从旧房子搬到新房子,是个持续几个月的过程。你不能把东西全扔了再全买一遍。

当系统需要改变时(新数据库、新协议、新数据模型)——这不是"从头重写",而是"带着系统走完一段过渡"。这就是 migration(迁移)。真实的系统在变更期间一直在运行。架构师从一开始就考虑迁移的路径,否则过渡就成了不可能的事。

YAGNI & Deletion — 删除比添加更重要

衣柜不能无限扩大。有时必须扔掉旧的,才能给新的腾地方。

任何成功的系统都会积累死代码、没人用的功能、过时的集成。这是每个开发者每天都在交的税。 架构师会定期问:"我们能删掉什么?"——有时这就是一年里最有用的架构决策。

最结实的墙,是从来不用拆的墙,因为后面没有被塞进任何多余的东西。

有时正确的架构决策,是不做架构决策。不要"为了将来"引入一层抽象。不要"以后某天会用到"就拆分单体。不要"以防万一"就建一套插件系统。这条原则叫 YAGNI —— You Aren't Gonna Need It(你不会需要它)。好的架构师知道什么时候该说"先不做"或"我们不需要这个"。

ADR — 架构决策要写下来,否则就丢了

口头的遗嘱,随立遗嘱的人一起消失。写下来的,能传好几代人。

每一个重要的架构决策都需要记录:选了什么、有哪些备选、为什么否掉、接受了哪些妥协。这份文档现在用不上——它是一年后用的,那时来了新人,问"为什么这里做得这么怪?"标准格式是 ADR(Architecture Decision Record,架构决策记录)。

C4 Model — 一张图胜过千言万语

用文字描述怎么走到一栋房子,又长又常常没用。给人看一张地图,一秒钟就够。

架构师手边总有一张系统的图:有哪些组件、怎么连接、边界在哪里。不求完美——能用就行。它用来向新人快速解释,也让你能看清系统的全貌。**C4 模型(Context、Container、Component、Code)**简单,对大多数情况已经够用。

好医生用病人听得懂的话解释诊断。坏医生满口医学术语,病人点点头,什么也没听懂。

如果架构师只会向其他工程师解释决策,他们就丢掉了一半的工作。业务、产品、法务、安全——所有的干系人(stakeholders)都需要理解后果。把技术决策翻译成业务语言(成本、风险、时间),是架构师的核心技能之一。

对什么请求都答应的外科医生,会失去病人。好的外科医生会在手术会致命时拒绝。

团队常常提出听起来合理、却会造成长期问题的要求。架构师必须敢于反驳、解释风险,有时还要守住底线——即使不受欢迎。同时也要——敢于承认自己错了,当反方的论据更有力时,改变决定。

这些概念如何相连

一个工具箱:没有钉子,锤子没用;没有锤子,钉子也没用。

本课的概念不是孤立存在的。一个决策从 Problem Framing 开始,当作 Trade-off 来权衡,检查它的 Reversibility,再写进 ADR。系统用 Decomposition 来切,切得好不好用 Cohesion & Coupling 来评判,各部分在 Interface 处相遇。数据的拷贝住在 Single Source of Truth 之下,异步世界里的重试则要求 Idempotency。