模式是一个答案的名字,不是一条规则

下棋时你不会每盘都重新发明开局。你认出"这是西西里防御"——于是已经知道它大致会通往哪里。

架构模式(architectural pattern) = 反复出现的问题 + 经过验证的解决形状 + 已知的代价。当你说"服务需要对别处发生的事情做出反应",这已经是一个被解决、被命名的问题——Event-driven architecture 模式。懂这套目录,意味着你不再重新发明,而是开始做选择。

架构模式 ≠ 设计模式

设计模式是你怎么摆放一个房间里的家具。架构模式是整栋房子的平面图。

设计模式(design patterns)——Factory、Observer、Strategy——活在一个模块的代码内部。架构模式决定系统里有哪些大"盒子"、它们之间有哪些连线:什么被单独部署、谁和谁对话、数据住在哪里。这门课讲的是平面图,不是家具。

地图:六组 17 个模式

地铁线路图:先看清整条线路,再一站一站地坐。

这门课的所有模式分成六组。每组回答一个问题:怎么组织单个应用、依赖指向哪里、怎么切分系统、各部分怎么通信、怎么在数据里保存真相,以及罕见问题需要哪些形状。

怎么读每个模式

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

接下来每个模式都是同样的结构:英文名(记住它——这就是术语)、一个生活中的画面、一张图,以及一张卡片,包含这些栏目:问题(哪里痛)、思路(怎么解决)、例子、代价(你要付出什么)、何时使用,以及和其他模式的关联。最重要的规则:不存在最好的模式,只有合适的模式,而每个模式都有一张账单,要在签字之前读明白。

Layered Architecture —— 分层架构

一家餐厅:大堂接单,厨房做菜,储藏室存货。服务员不下厨,厨师不跑地窖——每个人只和下面那一层打交道。

最常见的模式。代码被切成一层层横向的层(layers),请求从上往下穿过它们。每一层只知道它下面那一层。

Modular Monolith —— 模块化单体

一栋公寓楼:一个屋顶、一个大门,但每套公寓有自己的墙和门。没人穿过邻居的卧室去走楼梯。

仍然是一个应用,但内部按业务含义切成一个个模块(modules)——计费、商品目录、账户。模块之间只通过公开接口对话,不碰别人的表。

MVC / MVVM —— 让屏幕离脑子远一点

一座剧场:剧本、演员和导演、舞台和灯光,是不同的活儿。换布景不用重写整出戏。

这些模式在界面和数据与规则之间立起一道墙,这样改变某样东西长什么样,不会弄坏它做什么。

Hexagonal Architecture —— 端口与适配器

一台游戏机有标准接口。游戏不在乎你插的是手柄、方向盘还是街机摇杆——它只读"输入"。

装着业务逻辑的核心声明一组端口(ports)——像"保存订单"或"扣款"这样的接口。外面的**适配器(adapters)**针对具体技术实现这些端口。Driving adapters 调用核心(HTTP API、CLI、测试),driven adapters 被核心调用(数据库、支付、邮件)。

Clean / Onion Architecture —— 依赖一律指向内

一颗洋葱:心在正中,外面裹着一层层。剥掉外皮不会伤到心——而心并不依赖外皮。

同样的原则,画成一圈圈同心圆。中心是实体(entities),外面一圈是用例(use cases),再外面是适配器,最外层是 framework 和数据库。核心规则是 dependency rule:每一支依赖箭头都指向中心。

Microservices —— 微服务

一座美食广场:每个摊位有自己的厨房、菜单和收银台。披萨摊忙起来就多加两个厨师;沙拉摊不需要。

系统被拆成一个个小服务(services):每个拥有一项业务能力和自己的数据库,单独部署、单独伸缩。服务之间通过网络对话——HTTP 或消息总线。

Serverless —— 按需运行的函数

与其养一辆闲着的车,不如叫出租车,只在计价器跑着的时候付钱。

你写一些小函数(functions),云在事件发生时运行它们,自己从零伸缩到上千个副本再缩回去,按每次运行收费。

Request–Response —— 问完就等

在柜台点单:你问,你站着等,拿到咖啡才往前走。

客户端发出请求(request),然后等待响应(response)。这是同步通信:REST、gRPC、一次数据库查询。

Event-driven Architecture —— 宣布它,让监听者各自反应

一间新闻编辑室:新闻一出,体育、天气、广告各自做出反应。播报员不等他们,甚至不知道谁在听。

组件不去调用别人,而是发布一个事件(event)——一个已经发生的事实:"OrderPlaced"。谁感兴趣,谁就订阅并做出反应。两种形式:broker(事件自由地传开)和 mediator(由一个协调者按顺序推进各步)。

Message Queue 与 Pub/Sub —— 各部分之间的邮局

邮局替你存着信,直到收件人准备好。你把信扔进邮筒就走了;他醒来时再读。

**消息队列(message queue)**或 pub/sub broker 站在发送方和接收方之间,这样它们不必同时在线。在队列里,一条消息由一个 worker 取走;在 pub/sub 里,一条消息会发给所有订阅者。

Pipe-and-Filter —— 给数据装一条流水线

一条灌装线:洗瓶、灌装、封盖、贴标。每个工位只做一件事,然后把瓶子传下去。

数据流过一串独立的步骤——过滤器(filters),由**管道(pipes)**连接起来。每个 filter 只做一种转换。

CQRS —— 写模型和读模型分开

图书馆有一份用来找书的快速目录,还有一间单独的后屋,把书归档上架。查找为一件事优化,存放为另一件事优化。

CQRS(Command Query Responsibility Segregation)把写模型——改变数据的命令(commands)——和读模型——取出数据的查询(queries)——分开。每一边都可以单独优化、单独伸缩。

Event Sourcing —— 存历史,而不是存状态

银行不只存你的余额,而是存下每一笔收入和支出。余额只是它们的总和。丢了余额,按账本重算就行。

不去覆盖当前状态,而是存一条事件流(event log),只往末尾追加。当前状态通过**重放(replay)**事件得到。

Saga —— 一个可以倒回去的长操作

订一趟旅行:机票、酒店、租车。租车没订成——你就取消酒店和机票。没有一个"全部撤销"的按钮,只能一步一步倒回去。

当一个业务动作要经过好几个各有自己数据库的服务时,没法做成一个共同的事务。Saga 是一串本地事务;某一步失败时,就运行补偿动作(compensations),撤销前面的步骤。

Microkernel —— 小核心加插件

一把电钻:一个马达,十几个钻头。钻还是那把钻——活儿需要什么就换什么钻头。

一个极简的**核心(core)提供基础,其余一切都以插件(plugins)**的形式加入,插件接到核心上,彼此互不依赖。

Space-based Architecture —— 数据放内存,没有瓶颈

一座体育场有二十个售票窗口,每个都有自己的一份座位图——而不是只有一个窗口排着长队。

当唯一的数据库在巨大负载下成为瓶颈时,工作被分给许多 processing units,每个都把数据放在内存里。内存在它们之间同步(data grid),数据稍后再异步写进数据库。

Peer-to-Peer —— 没有中心

一场百乐餐:每个人既是厨师又是客人。没有餐厅,没有服务员——这群人自己喂饱自己。

节点——peers——直接互相通信,没有中心服务器。每个节点同时是客户端和服务器。

模式之间是有关联的

一栋房子同时用到承重墙、水管和电线——而不是"唯一正确的那种建筑模式"。

模式不会单独存在。模块化单体会长成微服务;微服务需要事件、队列和 saga;Hexagonal 和 Clean 是同一个想法;CQRS 和 Event Sourcing 成对出现。

一个真实的系统,可能对外是一个模块化单体,每个模块里是 Clean Architecture,界面用 Request–Response,慢吞吞的副作用走事件,重活前面挡一个队列。问题不是"哪个模式",而是**"哪些模式,放在哪里"**。

从最简单的形状起步

你不会为了盖一间小木屋去浇一座体育场的地基。

几乎每个系统都该作为 Modular Monolith 起步,并挣得它的复杂度。Microservices、CQRS、Event Sourcing、Space-based——都是对规模和团队大小问题的回答,而这些问题你也许永远不会有。最便宜的分布式系统,是你没造的那个。