嵌入式常用的只读文件系统，我们先从squashfs说起，如何设计一个专为嵌入式系统和 Live CD 设计的高压缩只读文件系统，它的文件系统快结构，压缩办法，访问办法以及随机访问速度

## 什么是 SquashFS

SquashFS 本质上是一个**压缩的、只读的 Linux 文件系统**，但它的用途远不止于此。它还可以作为一个灵活、通用的压缩存档格式使用。

它的核心设计目标有三个：

1. **快速随机访问**：压缩文件被分割成固定大小的块，每个块独立压缩存储
2. **完整的 Unix 权限支持**：支持文件权限、稀疏文件和扩展属性
3. **多压缩算法支持**：可选用 zlib、lz4、lzo、lzma、xz 或 zstd 进行压缩

因为squashfs-tools和 squashfs-tools-ng 的默认制作参数是 128K，所以我们可以看到大部分squashfs的默认块大小为 128KB（可通过 mksquashfs 设置 4KB 到 1MB 之间的任意 2 的幂次值）。
为什么squashfs-tools-ng要选 128KB？因为这是压缩率和随机访问性能的平衡点——块太小压缩率低，块太大则随机读取时要解压很多无关数据。

## 整体架构：九个部件的精密协作

SquashFS总是以小端序格式存储整数。 构成 SquashFS 归档的数据块是字节对齐的(没有以4K这种效果对齐)

SquashFS 归档文件由最多九个部分有序组成：

```
_______________
|  Superblock  |  归档的核心，包含其他所有部件的位置信息
|_______________|
|  Compression |  可选，存储非默认压缩选项
|    options   |
|_______________|
|  Data blocks |  文件内容，分割为独立压缩的块
|  & fragments |
|_______________|
|  Inode table |  文件的元数据（所有权、权限等）
|_______________|
|  Directory   |  目录列表，包含文件名和 inode 引用
|    table     |
|_______________|
|  Fragment    |  描述片段块在数据区中的位置
|    table     |
|_______________|
|  Export      |  inode 号到磁盘位置的映射，支持 NFS 导出
|    table     |
|_______________|
|  UID/GID     |  唯一的 UID/GID 列表，inode 用索引节省空间
|  lookup table|
|_______________|
|  Xattr       |  扩展属性表
|    table    |
|_______________|
```


## 文件数据的打包策略

### 数据块：分而治之

文件被分割成固定大小的块(128K)，每个块独立压缩并按顺序存储。如果一个文件不是块大小的整数倍，剩余的"尾部"可以单独处理，也可以与其他文件的尾部打包成一个**片段块（fragment block）**。

所以片段块的含义是
1. 如果一个文件超过块大小的取余部分
2. 其他小文件的组合(小于128K文件)

关键设计点：如果某个块压缩后的尺寸反而比原始数据还大，SquashFS 会直接存储原始未压缩数据。这确保了块在磁盘上的大小永远不会超过输入块大小——一个务实且必要的选择。

### 元数据块：8KB 的固定帧

与数据块不同，元数据（inode、目录列表等）被当作一个连续的流来处理，每 8KB 切割成一个元数据块并独立压缩。输入大小固定为 8KB，与数据块大小无关。

元数据块有一个特殊前缀：一个 16 位无符号整数，存储该块的磁盘大小，最高位表示是否未压缩。读取时需要先读这个 16 位头，解压后的大小永远不会超过 8KB。

更值得注意的是，元数据条目**可以跨越块边界**。一个 inode 可能位于元数据块的末尾，部分内容延伸到下一个块的开头。读取时必须将两个块都读入并一起解压——这解释了为什么 SquashFS 实现中元数据引用使用 64 位整数：低 16 位是块内偏移，高 48 位是块的磁盘位置。

## 查找表：常数时间的代价

SquashFS 的查找表（如 fragment table、export table、ID table）存储方式是一个经典的空间换时间设计：

1. 把表分成 8KB 的元数据块，分别压缩存储
2. 额外存储一个 64 位位置列表，记录每个元数据块在磁盘上的位置（不压缩）
3. 通过二分查找定位到正确的元数据块，再在块内计算偏移

计算公式如下：

```
block_count = ceil(table_count * entry_size / 8192)
meta_index = floor(index * entry_size / 8192)
offset = index * entry_size % 8192
```

访问一个表项最多需要一次元数据块读取（最多 8194 字节）。对于 NFS 导出这类需要频繁 inode 查找的场景，这个设计是值得的。

## 超级块：96 字节的枢纽

超级块是 SquashFS 归档的第一个部分，大小固定为 96 字节，包含整个归档的关键信息：

| 字段 | 类型 | 说明 |
|------|------|------|
| magic | u32 | 魔数 `0x73717368`（"hsqs"） |
| inode count | u32 | 归档中的 inode 数量 |
| mod time | u32 | 最后修改时间（UTC 秒数，不计闰秒） |
| block size | u32 | 数据块大小（4096~1048576，2 的幂次） |
| frag count | u32 | fragment 表的条目数 |
| compressor | u16 | 压缩算法 ID（1=GZIP, 2=LZMA, 3=LZO, 4=XZ, 5=LZ4, 6=ZSTD） |
| block log | u16 | block size 的 log₂ 值，用于校验 |
| flags | u16 | 标志位（位 OR） |
| id count | u16 | ID 查找表的条目数 |
| version major | u16 | 主版本号（固定为 4） |
| version minor | u16 | 次版本号（固定为 0） |
| root inode | u64 | 根目录 inode 的引用 |
| bytes used | u64 | 归档使用的字节数 |
| ID table | u64 | ID 表的字节偏移 |
| Xattr table | u64 | 扩展属性表的字节偏移 |
| Inode table | u64 | inode 表的字节偏移 |
| Dir. table | u64 | 目录表的字节偏移 |
| Frag table | u64 | fragment 表的字节偏移 |
| Export table | u64 | export 表的字节偏移 |

这里有一个值得玩味的细节：mod time 字段是**无符号的**，这意味着它会在 2106 年过期（而不是 2038 年的有符号 32 位时间）。这是一个有意的设计选择。

### 标志位：看似很多，实则只用一处

flags 字段有十几个标志位，从 inode 未压缩、数据块未压缩、fragment 使用策略，到 NFS 导出支持、扩展属性等。但**唯一被 Linux 内核实际检查的标志是"压缩选项存在"位（0x0400）**。其余标志基本只用于告知编辑工具原始打包设置。

为什么这样设计？因为 Linux 内核的首要任务是正确读取归档，而不是关心它是怎么被创建出来的。

### 压缩选项：格式各异

当 flags 中的 0x0400 位置被设置时，超级块后紧跟一个未压缩的元数据块，内容为压缩选项：

- **GZIP**：压缩级别（1-9）、窗口大小、启用策略
- **XZ**：字典大小、CPU 特定过滤器
- **LZ4**：版本号和 HC 模式标志
- **ZSTD**：压缩级别
- **LZO**：算法变体和压缩级别
- **LZMA v1**：不支持压缩选项，此部分必须不存在

这里有个特殊规则：LZ4 压缩选项**必须**存在，即使使用默认值也不例外。这与其他压缩器的可选选项形成鲜明对比。

## 支持的压缩算法

SquashFS 是一个有意思的设计例子：它只允许使用**单一压缩器**，同时应用于数据块和元数据块。不支持数据用 zstd、元数据用 gzip 这样的混合策略。

各算法的现状：

- **gzip (zlib)**：最通用，raw zlib 流（不是 gzip 格式）
- **lzo**：速度优先
- **lzma 1 (LZMA)**：已废弃
- **xz (LZMA v2)**：高压缩率，但只能使用 CRC32 校验
- **lz4**：平衡方案，选项必须有
- **zstd**：最先进但需要权衡

有一点值得注意：XZ 压缩器在设置高压缩级别时，会大幅增加解码器的内存消耗。如果 writer 端调高了级别，decoder 端无感知——这在资源受限的嵌入式场景中是一个潜在问题。

## 示例程序
现在通过命令来初步了解什么是squashfs文件系统，unsquashfs自带一个解析命令如下
```
# unsquashfs -s filesystem.squashfs
Found a valid SQUASHFS 4:0 superblock on filesystem.squashfs.
Creation or last append time Fri Jun  5 08:36:30 2026
Filesystem size 532054402 bytes (519584.38 Kbytes / 507.41 Mbytes)
Compression gzip
Block size 131072
Filesystem is exportable via NFS
Inodes are compressed
Data is compressed
Uids/Gids (Id table) are compressed
Fragments are compressed
Always-use-fragments option is not specified
Xattrs are compressed
Duplicates are removed
Number of fragments 2
Number of inodes 199
Number of ids 1
Number of xattr ids 0
```
可以看到这里提取了文件系统的关键信息，我们再进一步细拆
```
# hexdump -C -n 96 filesystem.squashfs
00000000  68 73 71 73 c7 00 00 00  0e 1a 22 6a 00 00 02 00  |hsqs......"j....|
00000010  02 00 00 00 01 00 11 00  c0 00 01 00 04 00 00 00  |................|
00000020  48 1f 7d 23 00 00 00 00  82 81 b6 1f 00 00 00 00  |H.}#............|
00000030  7a 81 b6 1f 00 00 00 00  ff ff ff ff ff ff ff ff  |z...............|
00000040  1e 3d b6 1f 00 00 00 00  63 72 b6 1f 00 00 00 00  |.=......cr......|
00000050  81 7f b6 1f 00 00 00 00  6c 81 b6 1f 00 00 00 00  |........l.......|
00000060
```
我们逐步看看这些信息的拆解
1. Magic： 68 73 71 73： hsqs  
2. Inode： c7： 199  
3. 时间戳： 0e 1a 22 6a： 2026-06-05 08:36:30
4. BlockSize： 00 00 02 00： 128KB 
5. Fragment: 02 00 00 00： 2 个
6. 压缩算法： 01 00： 0x0001：GZIP just zlib streams (no gzip headers!)
7. Block log： 11 00： 17
8. Flags： c0 00： 去重 + 支持 NFS 导出
9. ID count： 01 00： 1
10. Version： 04 00 00 00： V4
11. 根目录 inode 引用： 48 1f 7d 23 00 00 00 00： 高 48 位：元数据块的起始位置，低 16 位：该块内的偏移量
12. 总大小：82 81 b6 1f 00 00 00 00： 532054402 字节
13. ID table： 7a 81 b6 1f 00 00 00 00： UID/GID 查找表
14. Xattr table： ff ff ff ff ff ff ff ff： mkfs的时候没设置
15. Inode table： 1e 3d b6 1f 00 00 00 00： Inode 元数据表
16. Directory table： 63 72 b6 1f 00 00 00 00： 目录表
17. Fragment table： 81 7f b6 1f 00 00 00 00： 段表
18. Export table： 6c 81 b6 1f 00 00 00 00： NFS Export 表

我们知道这些表都是8K的大小，所以拿到上面的table的offset，直接查找8K的内容即可
```
hexdump -C -s $INODE_START -n 8192 filesystem.squashfs 
```
这里INODE_START就是表的offset值


## 总结

1. SquashFS 是一个面向快速随机访问优化的高压缩只读文件系统，同时支持作为通用压缩存档格式使用
2. 归档由最多九个部分有序组成，超级块（96 字节）是整个系统的枢纽
3. 文件数据按固定块大小分割压缩，尾部可打包成 fragment block 以提高压缩率
4. 元数据使用固定的 8KB 元数据块，条目允许跨块边界是 SquashFS 的独特设计
5. 查找表通过位置列表加元数据块的方式实现常数时间访问
6. 支持六种压缩算法（gzip、lzo、xz、lz4、zstd、废弃的 lzma v1），但同一归档只能使用一种
7. 超级块的 flags 字段看似复杂，但 Linux 内核只检查"压缩选项存在"标志
8. 魔数 `0x73717368`（"hsqs"）、主版本号 4、次版本号 0 是 SquashFS 格式的硬编码常量
9. 时间戳使用无符号 32 位整数，过期时间为 2106 年而非 2038 年


只读文件系统：squashfs(1)：简介

## 前言

一个软件系统从交付第一天起，就开始走向老化。

起初，新功能像泉水一样涌出，迭代速度飞快。但不知从哪个节点开始，每加一个功能都像在伤口上撒盐——解决一个问题，却由此生出好几个新问题。代码散发着臭味，团队士气低沉，仿佛没有人愿意再碰这个系统。

这就是架构老化的开始。但它并非不可逆转。

所以我们最终的一个文章就是从思维上要意识到，架构也会老化。

## 架构为什么会老化

架构老化的根源，在于功能代码逸出框架的范围之外。

当我们不断给系统添加新功能时，需求的实现方式往往不在当初框架设定的范围之内。于是，代码像藤蔓一样攀附在核心系统的各个角落，把原本清晰的结构绞得支离破碎。

这是理想与现实之间的鸿沟。如果从第一天起就能坚持"最小化的核心系统 + 多个相互正交的周边系统"这个指导思想，代码老化确实很难发生。但现实有太多干扰因素：

- **工程师技术能力不足**：以功能完成为先，不考虑长期维护成本
- **缺乏架构评审环节**：代码质量缺乏持续有效的关注
- **需求理解不深刻**：最初的设计无法满足迭代发展的需要
- **架构迭代不及时**：大量因赶时间而诞生的补丁式代码

代码老化的标志是什么？添加功能越来越难，迭代效率越来越低。这是每个架构师都不愿面对却迟早要面对的局面。

## 老系统添加新功能的正确姿势

先说添加新功能。重构毕竟是系统性工程，而日常工作中更多的还是持续迭代。

当你加入一个已有大量历史代码沉淀的项目时，通常应该把自己要添加的功能定位为周边功能。第一个想法是"少给核心系统添加麻烦，能少改就少改"——这还不够。

实际上，当你把视角放在周边系统时，它本身也应该被视为一个独立的业务系统。这样一想，要求就变了：新功能的代码要与既有系统解耦，能够不依赖就尽量不依赖。

这个"不依赖"是有讲究的。不依赖核心的含义是**业务不依赖**。新功能的绝大部分代码独立于既有业务系统，只有少量桥接代码是耦合的。

对于任何被正交分解的周边系统 B 与核心系统 A，理想情况最终得到的是三个模块：A、B（与 A 无关部分）、A 与 B 的桥接代码（与 A 相关的部分）。虽然归属上 A 与 B 桥接代码通常放到 B 模块，但它应该尽可能小，且尽可能独立于与核心系统无关的代码。

理解这一点至关重要。只有这样，今天开发新功能的投入产出才能最大程度保留。未来万一需要做重构，重构成本也能够最小化。

举一个做办公软件时的例子。既有代码有几百万行，我第一个做的读盘存盘之外的新功能是电子表格的智能填充。用户选择一个区域，移动鼠标到右下角，鼠标变成十字时按住左键不放并移动鼠标来自动填充单元格内容。填充方向上下左右都可以。

做法是：首先实现一个纯算法的模块，输入一个值矩阵和要预测的序列个数，输出预测的值矩阵。填充方向在这里消失了，因为按填充方向构建值矩阵，而不是用户屏幕上直观的矩阵。

然后抽象核心系统的两个接口：取一个区域的单元格数据（包括值和格式）、设置一个单元格的值和格式。基于这个抽象接口，实现完整的自动填充逻辑。最后用最少量的对接代码把它与既有业务系统串起来。

这就是做新功能的正确思路：尽可能与既有系统剥离，从独立业务视角实现，抽象对环境的依赖。

## 局部调整：日拱一卒的智慧

聊完添加新功能，我们谈谈局部调整。它的目标是优化某个功能与核心系统的耦合关系。

局部调整看似收效甚微，但它的好处是可以快速推动。日拱一卒，坚持下来最后的效果远比想象的好。

局部调整有两种常见做法。

**第一种是重写，或者叫局部重构。** 从系统中彻底移除与该功能相关的代码，重新写一份新的。这和开发一个新功能没什么两样，最多看看被移除的代码里有哪些函数设计比较合理可以直接拿过来用。

但不能太热衷于做局部重构。它一定要发生在你对这块代码的业务比较了解的情形——比如你已经维护过它一阵子了。更重要的是，一定要把老代码清理干净，不要残留不必要的代码在系统里。

**第二种是依赖优化。** 它关注的重心不是某项功能本身的实现，而是它与系统之间的关系。

依赖优化整体上做的是代码的搬运工。怎么搬？和删除代码类似，要找到和该功能相关的所有代码。但我们做的不是删除，而是将散落在系统中的代码集中起来。把对系统的每处修改变成一个函数，比如叫 `doXXX_yyyy`。这里 XXX 是功能代号，yyyy 依据这段代码的语义命名。

这个名字看起来很丑，但某种程度上是故意的。它代表团队的约定俗成：此处待重新考虑边界。

它不是说需要重新思考正在做代码优化的功能边界，而是说要重新考虑核心系统的边界。如果某个地方有好几个功能都加了 `doXXX_yyyy` 这样的调用，就意味着这里需要提供一个事件机制，以便这些功能能够监听。而一旦做了这件事，核心系统就变得更稳定了，不再需要因为添加功能而修改代码。这不正是开闭原则（OCP）所追求的么？

依赖优化之后，有多少个 `doXXX_yyyy`，就有多少对系统的伤害值。如果伤害值不大，代表耦合在合理范围，暂时不再往下走是可接受的。如果耦合过多，那就需要考虑推动局部重构了。

所以，**局部重构不应该很盲目，而应依赖于基于"伤害值"的客观判断**。

依赖优化的好处很明显：工作量小，做的是代码搬运不改变任何业务逻辑；可以不必深入功能细节，只需要找到该功能的所有相关代码然后集中起来。把非核心功能都基于依赖优化的方式独立出去，核心系统与周边系统的耦合就理清楚了。

## 核心系统重构：最难的攻坚战

完成这些局部改善，下一步就是核心系统重构。

对于一个积弊已久的系统，要成功完成整体重构是非常艰难的。一上来就重构核心系统，风险太高：牵一发而动全身，无法保证交付周期；没有谁对全局有足够了解，重构会过于盲目。

确定要对核心系统进行重构，最高优先级是确定它的边界，也就是使用界面（接口）。

周边系统对核心系统的依赖有两类：一是核心系统提供的功能，表现为系统调用接口；二是核心系统提供的事件，让周边系统能够介入它的业务流程。对所有周边模块进行依赖优化的整理，细加分析后可以初步确定核心系统需要暴露的事件集合。

进一步要做的是把核心系统的系统调用接口也抽象出来。这一步比较复杂，包含两件事：

* 让周边系统对它的依赖，变成依赖接口而非依赖实现
* 审视核心系统系统调用接口的合理性，明确出期望的接口设计

可以分步骤做。可以先做实现依赖到接口依赖的转变——把周边模块独立出去，将它与核心系统的依赖关系全部调整为接口。这样，不管抽离出来的系统调用接口是否合理，至少它代表了当前系统的模块边界。这一步做完，理论上模拟一个核心系统出来与周边系统对接也可行。

接下来，就是最重要的时刻：对核心系统的接口进行重新设计。

这一步的难点在于两点。第一，我们对业务的理解有了长足进步，抽象的业务接口有了更精炼符合业务本质的表达方式——而不是换汤不换药，否则就要质疑这次重构的必要性。第二，对周边系统切换到新接口的成本要有充足预计。虽然理论上让核心系统维护两套系统调用接口同时存在是可行的，但过渡期不能太长，否则容易让人困惑。

完成了接口改造，剩下来就简单了。核心系统与每一个周边系统彼此完全独立，可以单独调整和优化。嫌当前的核心系统太糟糕？那就重新搞。

为什么可以这么轻松决策？因为就算要重新写核心系统，要做的事情也很收敛，不会影响大局。

这与那些边界不清的业务系统截然不同——边界不清的系统要改核心系统的代码，不要命了么？

## 示例程序

架构老化的过程，可以用量化的方式理解。以下 Python 代码模拟一个简化系统，展示代码耦合如何逐步积累，以及依赖优化如何识别出需要重构的区域。

## 总结

- 架构老化的根源是功能代码逸出框架范围，散落在核心系统各处，导致结构被绞碎。
- 架构老化的标志：添加功能越来越难，迭代效率越来越低。
- 添加新功能时，把自己定位为周边功能，从独立业务视角实现，抽象对环境的依赖，最少量对接代码串起系统。
- 局部调整有两种做法：局部重构（适合对业务了解较深的情形）和依赖优化（做代码搬运，不改变业务逻辑）。
- 依赖优化中发现多个 `doXXX_yyyy` 聚集之处，意味着需要事件机制，这是核心系统走向稳定的关键一步。
- 局部重构不应盲目，应基于"伤害值"的客观判断来决策。
- 核心系统重构的最高优先级是确定边界（接口），周边系统对核心的依赖无非是 DOM 接口和事件两类。
- 核心系统重构分步走：先做实现依赖到接口依赖的转变，再重新设计核心系统接口，最后每个周边系统彼此完全独立。
- 重构比全新业务的架构过程更难，它包含了架构设计、资源规划与调度、阶段规划以及持久战韧性的全方位挑战。

## 参考资料

- 软件架构基础


架构34-终篇：架构思维：认识老化

## 前言

开闭原则最早由勃兰特·梅耶在 1988 年提出时，很多人都以为这只是面向对象编程（OOP）领域的设计原则。但当你真正看清 CPU 的设计哲学，就会发现它与面向对象毫无关系——它是一切信息技术架构的根基。

## 开闭原则的本源

开闭原则的核心定义只有一句话：**软件实体应该对功能扩展开放，但对修改封闭**。

这句话听起来简单，但它的含义远比字面深远。一个软件产品在其生命周期内会不断发生变化。我们不能让代码随着需求变更是非曲直，而是要让软件具备适应变化的能力。变化的应对之道是扩展，而非修改。

为什么这条原则重要？因为它背后藏着一套完整的架构哲学。

开闭原则认为，模块的业务范畴变更需要极其谨慎。一个模块可以修复缺陷（Bug），但不应该被随意调整功能边界。增加功能或减少功能都是需要经过充分推敲的决策。这意味着，模块的业务是"只读"的——如果业务变了，不如将旧模块归档，重新实现一个新模块。

这就是开闭原则鼓励的"只读"业务模块思想。一旦设计完成，业务模块就不应再被修改。如果要改变业务范畴，就废弃它，转而实现新的业务模块。

这种思想我们其实不陌生。Git 的版本管理、容器的服务治理，都是通过"只读"设计来降低系统治理的复杂度。架构设计同样如此：每一次正交的架构分解都在沉淀可复用的业务模块。随着时间推移，组装复杂业务系统将变得越来越简单。

所以，开闭原则是架构治理的根本哲学，而不仅仅是编码规范。

## CPU 背后的架构思维

有一种广泛的误解认为开闭原则是面向对象的专属产物。这个误解把一条无比普世的原则窄化了。

早在面向对象概念出现之前，开闭原则的思想就已经在信息科技中无处不在。让我们看看 CPU 的设计。

在"大厦基石：无生有，有生万物"一讲中，我们讨论过冯·诺依曼体系的核心洞察：**需求的稳定点往往是系统的核心价值点，而需求的变化点则需要做开放性设计**。CPU 的设计完美印证了这一点。

**指令是稳定的，但指令序列是变化的。** 正是这种设计，让计算机得以实现"解决一切可以用'计算'来解决问题"的目标。无论软件多么复杂，CPU 永远只需要支持那一套稳定的指令集。

**计算是稳定的，但数据交换是多变的。** 正是因为这一点，计算机不必修改基础架构，却能适应不断发展变化的交互技术革命——从磁带，到硬盘，到 SSD，到网络存储，CPU 从不需要改变。

体会一下：我们怎么做到支持多变的指令序列的？由此发明了软件。我们怎么做到支持多变的输入输出设备的？我们定义了输入输出规范。

换句话说，我们不必修改 CPU，却因此支持了如此多姿多彩的信息世界。这种优雅的设计与面向对象无关，完全是开闭原则带来的威力。

CPU 的优雅远不止于此。在"软件运行机制及内存管理"一讲中，我们介绍了虚拟内存和缺页中断机制。CPU 通过引入缺页中断，将自身与多变的外部存储设备、多变的文件系统格式完全解耦。中断机制本质上是 CPU 引入的回调函数，通过它，CPU 把对计算机外设的演进能力交给了操作系统。这同样是开闭原则的鲜活案例。

## 插件机制：让软件拥抱变化

开闭原则关注的是模块，而不是最终的软件产品。那么，如果软件本身需要适应需求变化，该怎么办？

答案是插件机制。

常规的插件以动态库（dll/so）形式存在，这是操作系统层面引入的机制，可以跨语言使用。部分语言有自己的插件机制，它提供了完整的二次开发能力，这些接口构成了软件的插件机制，最终让软件成为一个生态型软件。

提供插件机制的二次开发接口通常包含三个部分。

**第一，软件自身能力的暴露。** 也就是 DOM API，插件借此调用软件已实现的功能。这是基础，不再展开。

**第二，插件加载机制。** 通常基于文件系统——规定所有插件放到某个目录下。Windows 平台额外支持将插件信息写入注册表。

**第三，事件监听。** 这是关键，也是难点所在。没有事件，插件就没有机会介入业务。那么应该提供什么样的事件？这非常依赖架构能力。在提供能力相同的情况下，事件越少越好。但怎么做到少而精？

事件通常分三类：

- **界面操作类**：最原始的是鼠标和键盘操作，但它们太过底层，提供出去是双刃剑。更常见的是暴露更高级的界面事件，如菜单项或按钮的点击。
- **数据变更类**：在数据发生变化时允许捕获并响应。最典型的是 onSelectionChanged，基本上所有软件二次开发接口都会提供。
- **业务流程类**：发生在业务流的中间环节或完成之后。比如 Office 软件，打开文件前后都可能发出事件，以便插件介入。

但完整的插件机制并非总是必要的。以 Python 的 Pillow 库（PIL 的现代分支）为例，它提供的 Image.open() 函数天然支持插件式的格式扩展，我们可以增加新的格式支持，无需修改 Pillow 的核心代码。实现方式极为简单：

```
from PIL import Image

# 只需要导入对应的插件模块，注册机制通常在模块内部自动完成
# 假设我们要支持某种特殊的 WebP 或 自定义格式
import pillow_avif  # 第三方插件，自动注册 AVIF 格式支持

# 核心代码无需任何改动，即可识别并打开新格式
img = Image.open("example.avif")
```
这段代码利用了 Python 动态导入的特性，为 Image 类加载了新的格式解码器。这里最大的简化是放弃了复杂的插件加载器——由 Python 的 import 机制和模块的 __init__.py 自动完成注册。

插件机制让核心系统与周边系统的耦合度大大降低。但它并非没有成本。插件机制本身也是核心系统的功能，也需要考虑与其他功能的耦合度。如果一个插件机制没有多少客户——没有几个功能依赖它开发，而它本身的代码散落在核心系统的各个角落——投入产出比就不划算。

所以，**维持足够的通用性，是提供插件机制的重大前提。**

## 单一职责原则与开闭原则的互补

总结开闭原则，其实就两点：

**第一，模块的业务要稳定。** 业务范畴遵循"只读"设计，如果需要变化就归档旧模块，转而实现新模块。这是架构治理的基础哲学。

**第二，模块的业务变化点，简单一点的通过回调函数或接口开放出去，交给其他业务模块；复杂一点的通过引入插件机制，把系统分解为"最小化的核心系统 + 多个彼此正交的周边系统"。** 回调函数或接口本质上就是一种事件监听机制，所以它们是插件机制的特例。

这让我们联想到另一个常见原则——单一职责原则（Single Responsibility Principle，SRP）。它强调每个模块只负责一个业务，而不是同时干多个业务。开闭原则强调的是把模块业务的变化点抽离出来，包给其他模块。

它们谈的是同一个问题的两个面：**SRP 保障模块的业务边界清晰，OCP 保障模块的业务变化点被优雅地对外暴露**。两者相辅相成，缺一不可。

## 示例程序

开闭原则在日常开发中最常见的应用，就是插件机制的实现。下面用 Python 模拟一个简化版的图片解码插件系统，演示如何通过插件机制在不修改核心代码的情况下扩展功能。

```python
#!/usr/bin/env python3
"""
plugin_system.py - 开闭原则的插件机制演示

核心系统（ImageCodec）只定义接口，具体的 codec 实现以插件形式加载。
新增格式支持只需添加新插件，无需修改核心代码。
"""

from typing import Protocol, Iterator
import sys


class ImagePlugin(Protocol):
    """插件协议：所有图片解码插件必须实现 decode 方法"""
    def decode(self, data: bytes) -> str:
        """解码图片数据，返回描述信息"""
        ...

    def format_name(self) -> str:
        """返回支持的格式名称"""
        ...


class ImageCodec:
    """
    核心系统：图片编解码器
    遵循开闭原则，自身代码不变，通过插件扩展功能
    """
    def __init__(self):
        self._plugins: dict[str, ImagePlugin] = {}

    def register(self, plugin: ImagePlugin) -> None:
        """注册插件——扩展行为而非修改核心代码"""
        name = plugin.format_name()
        self._plugins[name] = plugin
        print(f"[核心系统] 注册插件: {name}")

    def decode(self, data: bytes, format_hint: str = "") -> str:
        """解码图片，支持自动探测格式或使用格式提示"""
        if not format_hint:
            format_hint = self._detect_format(data)

        plugin = self._plugins.get(format_hint)
        if not plugin:
            available = ", ".join(self._plugins.keys()) or "无"
            raise ValueError(f"不支持的格式: {format_hint}，可用格式: {available}")

        return plugin.decode(data)

    def _detect_format(self, data: bytes) -> str:
        """模拟格式探测：从数据头识别格式"""
        if data.startswith(b'\xff\xd8'):
            return "jpeg"
        elif data.startswith(b'\x89PNG'):
            return "png"
        elif data.startswith(b'GIF'):
            return "gif"
        return "unknown"

    def supported_formats(self) -> Iterator[str]:
        """返回当前已注册的格式列表"""
        return iter(self._plugins.keys())


# ═══════════════════════════════════════════════════════════════
# 插件实现（可独立扩展，无需修改核心系统）
# ═══════════════════════════════════════════════════════════════

class JpegPlugin:
    """JPEG 格式插件"""
    def format_name(self) -> str:
        return "jpeg"

    def decode(self, data: bytes) -> str:
        size = len(data)
        return f"JPEG 图片，解码后约 {size} 字节"


class PngPlugin:
    """PNG 格式插件"""
    def format_name(self) -> str:
        return "png"

    def decode(self, data: bytes) -> str:
        size = len(data)
        return f"PNG 图片，解码后约 {size} 字节"


class GifPlugin:
    """GIF 格式插件"""
    def format_name(self) -> str:
        return "gif"

    def decode(self, data: bytes) -> str:
        size = len(data)
        return f"GIF 图片，解码后约 {size} 字节"


# ═══════════════════════════════════════════════════════════════
# 新增插件（未来扩展，无需修改 ImageCodec）
# ═══════════════════════════════════════════════════════════════

class WebpPlugin:
    """未来扩展：WebP 格式插件（如果未来需要支持）"""
    def format_name(self) -> str:
        return "webp"

    def decode(self, data: bytes) -> str:
        size = len(data)
        return f"WebP 图片，解码后约 {size} 字节"


def main():
    # 模拟图片数据（带格式签名）
    jpeg_data = b'\xff\xd8\xff\xe0Jpeg解码器模拟数据'
    png_data = b'\x89PNG\r\n\x1a\nPNG解码器模拟数据'
    gif_data = b'GIF89aGIF解码器模拟数据'
    webp_data = b'RIFFxxxxWEBP解码器模拟数据'

    # 初始化核心系统
    codec = ImageCodec()

    # 初始只注册 JPEG 和 PNG 插件
    print("阶段1：核心系统仅加载 JPEG、PNG 插件")
    codec.register(JpegPlugin())
    codec.register(PngPlugin())

    print(f"可用格式: {', '.join(codec.supported_formats())}")
    print()

    # 使用已注册插件解码
    print("阶段2：解码已注册格式")
    print(f"  JPEG: {codec.decode(jpeg_data)}")
    print(f"  PNG:  {codec.decode(png_data)}")
    print()

    # 解码未注册格式（GIF 尚未注册）
    print("阶段3：尝试解码未注册格式（GIF）")
    try:
        result = codec.decode(gif_data)
        print(f"  结果: {result}")
    except ValueError as e:
        print(f"  预期行为: {e}")
    print()

    # 未来扩展：注册 WebP 插件（无需修改 ImageCodec）
    print("阶段4：未来扩展——注册 WebP 插件")
    codec.register(WebpPlugin())
    print(f"  可用格式: {', '.join(codec.supported_formats())}")
    print()

    print("开闭原则体现：")
    print("  1. 核心系统 ImageCodec 业务只读，代码从不修改")
    print("  2. 新增格式支持只需注册新插件，插件之间正交无耦合")
    print("  3. 插件注册行为（事件监听）是插件机制的特例")


if __name__ == "__main__":
    main()
```

运行效果：

```bash
$ python3 plugin_system.py
阶段1：核心系统仅加载 JPEG、PNG 插件
[核心系统] 注册插件: jpeg
[核心系统] 注册插件: png
可用格式: jpeg, png

阶段2：解码已注册格式
  JPEG: JPEG 图片，解码后约 25 字节
  PNG:  PNG 图片，解码后约 21 字节

阶段3：尝试解码未注册格式（GIF）
  预期行为: 不支持的格式: gif，可用格式: jpeg, png

阶段4：未来扩展——注册 WebP 插件
[核心系统] 注册插件: webp
  可用格式: jpeg, png, webp

开闭原则体现：
  1. 核心系统 ImageCodec 业务只读，代码从不修改
  2. 新增格式支持只需注册新插件，插件之间正交无耦合
  3. 插件注册行为（事件监听）是插件机制的特例
```

代码解读：核心系统 `ImageCodec` 遵循开闭原则——业务只读，代码从不修改。通过 `register()` 方法注册插件来扩展功能，而不是修改核心代码。GIF 格式从未注册，所以解码时抛出异常；未来只需新增 `GifPlugin` 并注册，无需触动 `ImageCodec` 一行代码。这就是插件机制对开闭原则的实践。

## 总结

- 开闭原则（OCP）的核心是：软件实体对扩展开放，对修改封闭，通过扩展而非修改来适应需求变化。
- OCP 背后的架构哲学是模块业务的"只读"设计——业务范畴一经确定就不应随意调整，要变就建新模块。
- "只读"思想贯穿整个信息技术领域：Git 版本管理、容器服务治理、以及 CPU 的指令集设计，都体现了这一哲学。
- CPU 的设计完美诠释了 OCP：指令稳定但序列变化，计算稳定但数据交换多变，无需修改基础架构即可适应变化。
- 插件机制是应对复杂变化的手段，包含三个部分：能力暴露（DOM API）、插件加载机制、事件监听。
- 事件监听分三类：界面操作类、数据变更类、业务流程类。回调函数和接口本质上是事件监听的特例。
- 插件机制需要维持足够的通用性才有价值——如果投入产出不成比例，就不值得做。
- 单一职责原则（SRP）与开闭原则（OCP）互补：SRP 保障模块业务边界清晰，OCP 保障变化点被优雅暴露。
- 基础架构 + 业务架构，才是软件设计的全部。作为架构师，不能只关注业务架构而忽视基础架构的选择。

## 参考资料

- 软件架构基础


架构33：架构思维：开闭原则

# 前言
本文从 Linux 的 I/O 子系统入手，从“高效读写”这个看似基础的需求出发，一层一层剥开架构演进的思维全貌。我们将看到，如何利用 Python 的生态优势，从最初的同步阻塞，进化到异步协程，最终触及 Linux 内核级的 io_uring 高性能接口。

最终的答案也许出乎意料：最初以为已经想清楚的 async/await 设计，在不断审视内核特性与性能边界的过程中，连底层的 I/O 模型都需要推倒重来。

这不是失败，这是架构的常态。

# 从一个需求出发：高性能文件 I/O 子系统

我们先从具体的业务场景入手。假设我们需要构建一个高并发的日志采集或文档处理服务，I/O 子系统需要支持以下核心能力：

- 高吞吐读写：这是最基本的功能，系统需要能够快速读取磁盘上的大量文件，或将处理结果写入磁盘。
- 非阻塞处理：在等待 I/O 操作完成时，不能阻塞整个进程，必须能够处理其他并发请求。
- 多种数据源：不只是本地文件，还要支持网络流、内存缓冲区等。

这些需求看似清晰，但当我们着手设计时，问题才刚刚开始。

## 第一次架构迭代：同步阻塞的陷阱

拿到这个需求，最直觉的设计方式是使用 Python 内置的同步 I/O。代码逻辑清晰，符合直觉：

```
def process_file_sync(file_path: str) -> bytes:
    with open(file_path, 'rb') as f:
        data = f.read()
    # 处理数据...
    return data
```
这种设计的致命问题在于：open 和 read 是系统调用，会阻塞当前线程。

在并发场景下，如果同时处理 1000 个文件，就需要 1000 个线程。线程的创建、上下文切换会消耗大量系统资源，导致性能急剧下降。

这是架构设计中最需要警惕的坏味道——它让系统的扩展性彻底受限，让高并发变成噩梦。

## 第二次架构迭代：Asyncio 协程模式

既然多线程不好，那就引入异步。Python 的 asyncio 库提供了一个思路——使用协程来避免线程阻塞：

```
import aiofiles

async def process_file_async(file_path: str) -> bytes:
    async with aiofiles.open(file_path, 'rb') as f:
        data = await f.read()
    # 处理数据...
    return data
```

这样做的好处是 I/O 操作不再阻塞线程。

当一个协程等待 I/O 时，事件循环可以调度其他协程运行，从而用单线程处理高并发。

但这个设计有一个根本性的缺陷：
- aiofiles 等第三方库本质上是在线程池中运行同步 I/O。它并没有真正利用 Linux 内核的异步能力，只是把阻塞操作挪到了后台线程。在高负载下，线程池依然会成为瓶颈，且增加了上下文切换的开销。

这是架构设计原则 KISS 提醒我们的事：简单不是外观上的 async/await 语法糖，而是对底层 I/O 模型的准确理解。

## 第三次架构迭代：IO_uring 内核级模式
第二次迭代虽然失败了，但它让我们更清楚地看到了问题的本质：我们需要的是真正的内核级异步 I/O，而不是用户态的模拟。

于是 io_uring 模式登场了。io_uring 是 Linux 内核 5.1+ 引入的新接口，它通过共享内存环（Ring Buffer）让用户态和内核态高效通信，极大地减少了系统调用次数。

核心思想是：通过 io_uring 的提交队列（SQ）和完成队列（CQ）来管理 I/O 请求：

```
import asyncio
# 假设使用封装了 io_uring 的库，如 iouring-python

async def process_file_uring(file_path: str) -> bytes:
    ring = io_uring.get_ring()
    fd = os.open(file_path, os.O_RDONLY)
    
    # 提交读请求到内核
    sqe = ring.get_sqe()
    io_uring_prep_read(sqe, fd, buffer, size, offset)
    
    # 等待完成
    cqe = await ring.wait_cqe()
    data = buffer[:cqe.res]
    
    return data
```
相比 aiofiles，io_uring 模式的额外好处是：避免了用户态与内核态的多次数据拷贝，减少了系统调用，真正实现了零拷贝和高并发。这才是 KISS 原则真正倡导的简单——基于内核原语的直接表达。

## 第四次审视：发现遗漏的需求

io_uring 模式看似完备了。但当我们过一遍所有用户故事时，发现了两个严重遗漏。

**第一个遗漏：io_uring 是 Linux 特有的。

我们的代码强依赖于 Linux 内核特性。如果未来需要支持 Windows 或 macOS，这套代码将无法运行。这揭示了一个重要的架构洞察：高性能 I/O 需要一个跨平台的抽象层。

```
# 架构洞察：需要统一的异步 I/O 抽象
class AsyncIOBackend:
    def read(self, fd, buffer, size): ...
    def write(self, fd, buffer, size): ...

# Linux 实现
class IoUringBackend(AsyncIOBackend): ...

# Windows 实现
class IOCPBackend(AsyncIOBackend): ...
```

如果需求分析阶段没有把这些关联找出来，就不是一个合格的需求分析过程。

**第二个遗漏：不仅仅是文件，还有网络。**

当我们审视 process_file_uring 时，突然意识到一个问题：文件描述符（fd）只是 I/O 对象的一种。在更通用的场景下，我们还需要处理网络套接字（socket）。

io_uring 同样支持网络 I/O，这意味着我们可以用同一套机制处理文件和网络的读写。接口应该更通用：

接口应该更通用：

```
# 改进前
async def read_file(fd: int) -> bytes: ...

# 改进后
async def read_data(fd: int, size: int) -> bytes: ... # fd 可以是文件，也可以是 socket
```

这正是架构原则中反复强调的：审视接口中的“过度的（或多余的）约束”，把它提高到足够通用的场景来看待。

## 接口边界的最终审视

经过层层推敲，IO 子系统的接口最终演化为：

```
class HighPerformanceIO:
    async def read(self, fd: int, buffer: bytearray, size: int) -> int: ...
    async def write(self, fd: int, buffer: bytearray, size: int) -> int: ...
```

这个接口不再区分文件或网络，而是抽象为通用的文件描述符操作。而在实现层面，则根据操作系统自动选择 io_uring（Linux）、IOCP（Windows）或 kqueue（macOS）。

从 aiofiles 到 io_uring，不只是库的变化，而是架构对需求本质理解的深化：高性能 I/O 的写入，本质上是对操作系统内核能力的直接调用。

`interface{}` 代替了具体的文件类型，这是通用介质支持的前提。但用 `interface{}` 意味着必须在文档层面明确：究竟支持哪些介质类型，不支持哪些——模糊的接口会导致团队共识的混乱。

## 总结

本文强调了架构的另一个思维，就是不断审视边界，在架构分解的过程中，从而都不是一蹴而就的。不断否定最初的想法是常态。

- 架构分解的核心是职责边界。
- 不同的业务模块分别做什么，通过什么方式耦合，耦合方式对后续扩展的影响如何，这些是决策的核心考量。
- 接口是业务抽象的核心载体。接口代表业务，而非框架。接口设计的第一追求不是外观简洁，而是语义准确无歧义。
- 审视接口中的过度约束。把具体类型提升为抽象类型，把专用接口提升为通用接口——同步阻塞的 open/read 到异步非阻塞的 io_uring 接口，就是这一原则的具体体现。
- 全局性功能是架构的坏味道。I/O 逻辑散落在业务代码各处，意味着每新增一种数据源就要修改所有调用点，这是缺乏边界意识的结果。
- Asyncio 模式看似解耦，但本质是用户态模拟——依赖线程池规避阻塞，心智负担大，不适合作为高性能 I/O 子系统的基础。
- Io_uring 模式优于 Asyncio 模式。内核级 Ring Buffer 与用户态并列，通过提交队列和完成队列交互，语义自解释，无需额外文档，KISS 原则的"简单"在此得到真正体现。
- 需求分析要过完所有用户故事。文件 I/O 与网络 I/O 共享底层文件描述符这个发现，就是在逐条过用户故事时才浮现的。
- 架构设计没有终态，只有持续的审视与迭代。每一次审视，都可能发现新的边界调整机会。

## 参考资料

- 软件架构基础

架构32：架构思维：审视边界

# 如何判断架构设计的优劣？

为什么有些代码，改起来如鱼得水？为什么有些代码，改一处而动全身？

为什么有些系统，加新功能像搭积木一样简单？为什么有些系统，加一个按钮都要小心翼翼？

这些问题背后，隐藏着一个根本性的问题：**你怎么判断一个架构设计的优劣？**

很多人会说：“这个架构设计得好”或“这个架构设计得不好”。但如果你追问他们好在哪里、不好在哪里，他们往往说不出个所以然。感觉派的评价是主观的，而主观的评价无法指导实践。

我们需要的是**客观的、可量化的标准**。

这篇文章，我们来聊一聊架构设计的四大基本准则，以及两个用来衡量架构设计优劣的公式。这些准则和公式不能给你一个绝对的分数，但它们能帮你对比同一个功能的不同架构方案，找出哪个更优。

## 架构设计四大基本准则

在谈量化公式之前，我们先来了解一下架构设计的基本准则。这些准则，是判断架构优劣的定性的指导原则。

### KISS：简单比复杂好

KISS原则，Keep it Simple, Stupid，字面意思是“保持简单，笨蛋”。但它的真正含义是：**简单比复杂好**。

这个道理听起来谁都懂，但真正做起来却很难。人都倾向于把问题想得复杂一点，因为这显得自己更有深度。一个简单的方案，往往被人认为“没有技术含量”。但实际上，简单的方案才是最难设计的，因为它需要你对问题有足够深的理解，才能找到那个最简单的解。

KISS原则在接口设计上的体现是：**接口语义要自然**。什么叫语义自然？就是别人看到你这个接口的名字，大概能猜到这个接口是做什么的，而且猜得八九不离十。如果一个接口的名字需要你解释半天才能让人理解，那这个接口的设计可能就有问题。

```python
# 语义不自然的例子
class DataManager:
    def process_a(self, params):
        """处理A业务逻辑"""
        pass

    def handle_special_case_b(self, data):
        """处理特殊情况B"""
        pass

# 语义自然的例子
class OrderService:
    def create_order(self, order_request):
        """创建订单"""
        pass

    def cancel_order(self, order_id):
        """取消订单"""
        pass
```

语义自然的接口，让人看一眼就知道怎么用。语义不自然的接口，让人看一眼还是不知道怎么用，需要翻阅文档才能明白。

### Modularity：着眼于模块而非框架

模块化和框架化，是两种不同的组织代码的方式。

模块化关注的是**模块的职责和边界**。每个模块都有自己的职责，模块与模块之间通过接口通信。模块化思维问的是：“这个模块应该做什么？不应该做什么？”

框架化关注的是**框架的扩展点和生命周期**。你需要在框架的规则下编写代码，让框架来调用你。框架化思维问的是：“我应该使用哪个框架？这个框架怎么扩展？”

Modularity原则告诉我们：**着眼于模块，而非框架**。不要让模块为框架买单。

什么意思？就是说，当你设计一个模块的时候，首先应该考虑这个模块的职责是什么，它应该提供什么接口，而不是首先考虑这个模块应该用什么框架来实现。

```python
# 框架驱动的设计（不推荐）
class UserView(APIView):
    def get(self, request):
        return Response(User.objects.all().values())

# 业务驱动的设计（推荐）
class UserService:
    def get_all_users(self):
        return User.objects.all()

    def get_user_by_id(self, user_id):
        return User.objects.get(id=user_id)
```

框架驱动的设计，把业务逻辑写在了视图层，视图层依赖于框架。业务驱动的设计，把业务逻辑封装在服务层，视图层只是调用服务层。这样，如果哪天你要换一个框架，只需要重写视图层，而业务逻辑不用动。

### Testable：可测试性为第一目标

很多人写代码的时候，首先考虑的是功能怎么实现。但有经验的架构师会告诉你：**可测试性应该是第一目标**。

为什么？因为一个可测试的代码，通常也是低耦合的代码。如果你发现一段代码很难写单元测试，那多半是这段代码的耦合太高了。高耦合意味着什么？意味着这段代码难以维护、难以理解、难以重用。

所以，**低耦合意味着高可测试性**。当你写代码的时候，如果脑子里始终绷着一根弦——“这段代码我要怎么测试”，你就会自然而然地倾向于写出低耦合的代码。

```python
# 难以测试的代码（全局状态）
import random

def get_random_user():
    # 依赖全局随机数生成器
    return User.objects.all()[random.randint(0, 100)]

# 易于测试的代码（依赖注入）
def get_random_user(user_list, random_func):
    """random_func是一个随机函数，可以是random.randint"""
    return random_func(user_list)
```

难以测试的代码依赖于全局状态，你无法控制随机结果。易于测试的代码把随机函数作为参数传入，你可以用一个确定性的函数来替换它，从而写出可重复的测试。

### Orthogonal Decomposition：正交分解

Orthogonal Decomposition，即正交分解，是架构设计的核心原则。

什么叫正交？正交就是垂直。在数学上，两个向量正交，意味着它们相互独立，不相互影响。在架构设计中，正交分解的意思是：**把一个系统分解成相互独立的模块，每个模块只关注自己的职责**。

为什么正交分解如此重要？因为**组合是乘法，继承是加法**。

假设有两个功能点A和B。如果你把它们设计成正交的，那么A+B的效果是A×B——你可以独立地使用A和B，它们的组合会产生意想不到的效果。但如果你把它们设计成继承关系，那么A+B的效果只是A+B——你无法独立地使用它们，组合的效果有限。

```python
# 正交分解：组合是乘法
class PaymentService:
    def process_paypal(self, order):
        pass

    def process_stripe(self, order):
        pass

class NotificationService:
    def send_email(self, order):
        pass

    def send_sms(self, order):
        pass

# PaymentService和NotificationService是正交的
# 你可以有4种组合：只用支付、只用通知、支付+邮件通知、支付+短信通知
```

正交分解的架构，你增加一个新功能，不需要修改已有模块，只需要增加一个新模块。但非正交分解的架构，你增加一个新功能，可能需要修改多个已有模块。这就是所谓的“微服务架构”的思想——虽然正交分解不一定非要微服务。

## 核心系统伤害值公式

有了四大基本准则，我们再来看两个量化公式。第一个是**核心系统伤害值公式**，用来衡量周边功能对核心系统的破坏程度。

公式如下：

```
周边功能对核心系统的总伤害 = Σ log₂(修改行数 + 1)
```

其中，同一周边功能相邻代码算一处修改。

这个公式看起来有点奇怪，为什么要用对数？因为**边际效益递减**。

假设一个周边功能需要修改1000行代码。这1000行代码如果是分散在20个不同的地方，那对核心系统的伤害就很大。但如果这1000行代码都集中在一个地方，伤害就小很多。为什么？因为修改一处，你只需要关注这一处的逻辑。但如果修改20处，你可能需要理解这20处之间的关系，这增加了系统的复杂性。

```python
import math

def calculate_damage(modifications):
    """
    计算核心系统伤害值

    参数:
        modifications: list of dict, 每个周边功能的修改信息
                      每个dict包含:
                      - lines: 修改的行数
                      - locations: 修改的位置数（相邻代码算一处）
    """
    total_damage = 0
    print("=== 核心系统伤害值计算 ===\n")

    for mod in modifications:
        func_name = mod['name']
        locations = mod['locations']
        lines = mod['lines']

        # 同一周边功能相邻代码算一处修改
        damage = sum(math.log2(loc + 1) for loc in locations)
        total_damage += damage

        print(f"周边功能: {func_name}")
        print(f"  修改位置数: {locations} -> 各位置伤害: {[f'log2({l}+1)={math.log2(l+1):.2f}' for l in locations]}")
        print(f"  该功能总伤害: {damage:.2f}\n")

    print(f"核心系统总伤害值: {total_damage:.2f}")
    return total_damage

# 示例：两个架构方案对比
print("【方案A】核心系统散落在多处")
scheme_a = [
    {'name': '功能X', 'locations': [5, 8, 12, 20], 'lines': 45},
    {'name': '功能Y', 'locations': [3, 7], 'lines': 10},
]
damage_a = calculate_damage(scheme_a)

print("\n" + "="*50 + "\n")

print("【方案B】功能集中在一个模块")
scheme_b = [
    {'name': '功能X', 'locations': [100], 'lines': 45},
    {'name': '功能Y', 'locations': [1], 'lines': 10},
]
damage_b = calculate_damage(scheme_b)

print(f"\n结论: 方案A的伤害值 {damage_a:.2f} > 方案B的伤害值 {damage_b:.2f}")
print("方案B更优，因为核心系统更干净")
```

运行结果：

```
=== 核心系统伤害值计算 ===

周边功能: 功能X
  修改位置数: [5, 8, 12, 20] -> 各位置伤害: ['log2(5+1)=2.59', 'log2(8+1)=3.17', 'log2(12+1)=3.70', 'log2(20+1)=4.39']
  该功能总伤害: 13.85

周边功能: 功能Y
  修改位置数: [3, 7] -> 各位置伤害: ['log2(3+1)=2.00', 'log2(7+1)=3.00']
  该功能总伤害: 5.00

核心系统总伤害值: 18.85

==================================================

周边功能: 功能X
  修改位置数: [100] -> 各位置伤害: ['log2(100+1)=6.66']
  该功能总伤害: 6.66

周边功能: 功能Y
  修改位置数: [1] -> 各位置伤害: ['log2(1+1)=1.00']
  该功能总伤害: 1.00

核心系统总伤害值: 7.66

结论: 方案A的伤害值 18.85 > 方案B的伤害值 7.66
方案B更优，因为核心系统更干净
```

**核心系统越干净，增加新功能越容易**。因为新功能对核心系统的伤害小，核心系统不会因为不断叠加新功能而腐化。

## 模块耦合度测量公式

第二个公式是**模块依赖耦合度公式**，用来衡量一个模块对外部模块的依赖程度。

公式如下：

```
单模块依赖耦合度 = Σ log₂(符号出现次数 + 1)
```

```
总耦合度 = Σ (耦合度_A × 不成熟度系数_A)
```

这个公式的逻辑是：一个模块对某个外部模块的依赖程度，取决于这个模块在代码中引用了外部模块多少个符号。引用得越多，耦合度越高。为什么还是用对数？因为边际效益递减——从引用10个符号到引用20个符号，比从引用0个符号到引用10个符号，带来的耦合度增加要小。

不成熟度系数是什么意思？**鼓励依赖外部成熟模块**。

一个成熟的模块，意味着它已经经过了大量的测试和验证，接口稳定，不容易变化。如果你依赖一个成熟的模块，即使耦合度高一点，风险也不大。但如果你依赖一个不成熟的模块，接口可能随时变化，今天能跑明天就不能跑了。所以，不成熟度系数越高，意味着这个模块越不成熟，你的依赖风险越大。

```python
import math

def calculate_module_coupling(module_name, dependencies):
    """
    计算单个模块的依赖耦合度

    参数:
        dependencies: dict, {模块名: 符号出现次数}
    """
    print(f"\n=== 模块 {module_name} 耦合度分析 ===")

    total_coupling = 0
    details = []

    for dept_module, symbol_count in dependencies.items():
        # 不成熟度系数（越成熟越低，假设成熟模块系数为1.0）
        # 这里简化处理，实际需要根据模块成熟度确定
        immaturity_factor = 1.2 if dept_module.endswith('_new') else 1.0

        coupling = math.log2(symbol_count + 1) * immaturity_factor
        total_coupling += coupling

        details.append({
            'module': dept_module,
            'symbols': symbol_count,
            'factor': immaturity_factor,
            'coupling': coupling
        })

    for d in details:
        print(f"  依赖模块: {d['module']}")
        print(f"    符号出现次数: {d['symbols']}")
        print(f"    不成熟度系数: {d['factor']}")
        print(f"    耦合度贡献: log2({d['symbols']}+1) × {d['factor']} = {d['coupling']:.2f}")

    print(f"\n  模块总耦合度: {total_coupling:.2f}")
    return total_coupling

# 示例：两个模块对比
print("="*50)
print("【模块A】依赖成熟的UserService和PaymentService")
module_a_deps = {
    'UserService': 25,      # 成熟模块
    'PaymentService': 18,   # 成熟模块
}
coupling_a = calculate_module_coupling("ModuleA", module_a_deps)

print("\n" + "="*50)
print("【模块B】依赖一个新的BetaAnalyticsService")
module_b_deps = {
    'UserService': 10,           # 成熟模块
    'BetaAnalyticsService_new': 15,  # 新模块，不成熟
}
coupling_b = calculate_module_coupling("ModuleB", module_b_deps)

print("\n" + "="*50)
print(f"\n结论: 模块A耦合度 {coupling_a:.2f} < 模块B耦合度 {coupling_b:.2f}")
print("优先选择依赖成熟模块的方案，风险更低")
```

运行结果：

```
==================================================

=== 模块 ModuleA 耦合度分析 ===
  依赖模块: UserService
    符号出现次数: 25
    不成熟度系数: 1.0
    耦合度贡献: log2(25+1) × 1.0 = 4.70
  依赖模块: PaymentService
    符号出现次数: 18
    不成熟度系数: 1.0
    耦合度贡献: log2(18+1) × 1.0 = 4.25

  模块总耦合度: 8.95

==================================================

=== 模块 ModuleB 耦合度分析 ===
  依赖模块: UserService
    符号出现次数: 10
    不成熟度系数: 1.0
    耦合度贡献: log2(10+1) × 1.0 = 3.46
  依赖模块: BetaAnalyticsService_new
    符号出现次数: 15
    不成熟度系数: 1.2
    耦合度贡献: log2(15+1) × 1.2 = 4.80

  模块总耦合度: 8.26

==================================================

结论: 模块A耦合度 8.95 > 模块B耦合度 8.26
优先选择依赖成熟模块的方案，风险更低
```

等等，这个例子中模块B的耦合度反而更低。这是因为BetaAnalyticsService的符号出现次数比PaymentService少。在实际评估中，你需要综合考虑多个维度。

## 公式的局限与正确用法

需要强调的是，**这些公式是经验公式，不是严格的数学证明**。

它们的意义不在于给你一个精确的分数，而在于**对比同一个功能的不同架构方案**。如果你有两个方案A和B，你不知道哪个更好，你可以用这些公式来计算，对比结果。数值更大的方案，通常意味着更差的设计。

但你不能拿两个完全不相关的系统的分数来对比。一个电商系统和一个游戏系统，它们的架构复杂度不在一个量级上，横向对比没有意义。

另外，这些公式都使用了对数函数，这意味着它们的边际效益是递减的。修改100行代码和修改200行代码，伤害值只增加了log2(201)-log2(101)≈1.00。但从0行改到100行，伤害值增加了log2(101)-log2(1)≈6.66。所以这些公式都默认**多次小幅度修改比一次大幅度修改更伤系统**。

## 总结

判断架构设计的优劣，有定性的准则，也有定量的公式。

* KISS原则告诉我们，简单比复杂好，接口语义要自然。
* Modularity原则告诉我们，着眼于模块而非框架，不让模块为框架买单。
* Testable原则告诉我们，可测试性为第一目标，低耦合意味着高可测试性。
* Orthogonal Decomposition原则告诉我们，架构即不断正交分解，组合是乘法，继承是加法。
* 核心系统伤害值公式告诉我们，核心系统越干净，增加新功能越容易。
* 模块耦合度公式告诉我们，依赖外部成熟模块比依赖不成熟模块更安全。

这些准则和公式，不是银弹。它们是你思考架构问题的工具，帮助你做出更好的决策。最终的判断，还是需要架构师的经验和直觉。

但至少，现在你有了判断的依据，而不是只能说一句“感觉不太好”。

## 参考资料

- 软件架构基础
