## 前言

当系统架构师完成了复杂度的识别，这意味着我们已经拨开了笼罩在系统之上的迷雾，明确了真正的挑战所在。然而，这仅仅是架构长征的起点——真正的考验才刚刚开始。

为何需要设计备选方案？因为架构设计从来不是一道只有一个标准答案的数学题。成熟的架构师需要对现有的技术版图了然于胸，对已经过无数场景验证的架构模式烂熟于心，然后根据对业务的深邃理解，挑选合适的架构模式进行精妙的组合，再对组合后的方案进行恰到好处的调整。这正是架构设计艺术性的体现——它既是科学，也是哲学，更是一种创造性的实践。

## 设计备选方案

### 组合创新的力量

软件技术历经数十年的飞速发展，新技术如雨后春笋般层出不穷。但经过时间大浪淘沙般的考验，已经被各种场景验证过的成熟技术其实更多。例如：

- **高可用领域**：主备方案、集群方案
- **高性能领域**：负载均衡、多路复用
- **可扩展领域**：分层架构、插件化技术

绝大部分时候，我们有了明确的目标后，按图索骥就能够找到可选的解决方案。只有当这种方式完全无法满足需求的时候，才会考虑进行方案的创新。而事实上，方案的创新绝大部分情况下也都是基于已有的成熟技术。

《技术的本质》一书对技术的组合有深刻的阐述：新技术都是在现有技术的基础上发展起来的，现有技术又来源于先前的技术。将技术进行功能性分组，可以大大简化设计过程，这是技术"模块化"的首要原因。技术的"组合"和"递归"特征，将彻底改变我们对技术本质的认识。

### 三种常见的架构设计误区

虽说基于已有的技术或者架构模式进行组合调整，大部分情况下就能够得到我们需要的方案，但这并不意味着架构设计是一件很简单的事情。因为可选的模式有很多，组合的方案更多。因此，如何设计最终的方案，并不是一件容易的事情，这个阶段也是很多架构师容易犯错的地方。

**第一种错误：设计最优秀的方案**

很多架构师在设计架构方案时，心里会默认有一种技术情结：我要设计一个优秀的架构，才能体现我的技术能力！例如，高可用的方案中，集群方案明显比主备方案要优秀和强大；高性能的方案中，淘宝的 XX 方案是业界领先的方案……

根据架构设计原则中"合适原则"和"简单原则"的要求，挑选合适自己业务、团队、技术能力的方案才是好方案；否则要么浪费大量资源开发了无用的系统，要么根本无法实现。

**第二种错误：只做一个方案**

很多架构师在做方案设计时，可能心里会简单地对几个方案进行初步的设想，再简单地判断哪个最好，然后就基于这个判断开始进行详细的架构设计了。

这样做有很多弊端：

- 心里评估过于简单，可能没有想得全面，只是因为某一个缺点就把某个方案给否决了，而实际上没有哪个方案是完美的
- 架构师再怎么牛，经验知识和技能也有局限，有可能某个评估的标准或者经验是不正确的
- 单一方案设计会出现过度辩护的情况，即架构评审时，架构师会竭尽全力去为自己的设计进行辩护

**第三种错误：备选方案过于详细**

有的架构师在写备选方案时，错误地将备选方案等同于最终的方案，每个备选方案都写得很细。这样做的弊端显而易见：

- 耗费了大量的时间和精力
- 将注意力集中到细节中，忽略了整体的技术设计
- 评审的时候其他人会被很多细节给绕进去，评审效果很差

正确的做法是备选阶段关注的是技术选型，而不是技术细节。

### 备选方案设计的黄金法则

架构师需要设计多个备选方案，但方案的数量可以说是无穷无尽的，架构师也不可能穷举所有方案。合理的做法应该遵循以下原则：

**数量法则**：备选方案的数量以 3 ~ 5 个为最佳。少于 3 个方案可能是因为思维狭隘，考虑不周全；多于 5 个则需要耗费大量的精力和时间，并且方案之间的差别可能不明显。

**差异法则**：备选方案的差异要比较明显。例如，主备方案和集群方案差异就很明显，或者同样是主备方案，用 ZooKeeper 做主备决策和用 Keepalived 做主备决策的差异也很明显。但是都用 ZooKeeper 做主备决策，一个检测周期是 1 分钟，一个检测周期是 5 分钟，这就不是架构上的差异，而是细节上的差异了。

**视野法则**：备选方案的技术不要只局限于已经熟悉的技术。很多架构师积累了一些成功的经验，出于快速完成任务和降低风险的目的，可能自觉或者不自觉地倾向于使用自己已经熟悉的技术，对于新的技术有一种不放心的感觉。就像那句俗语说的："如果你手里有一把锤子，所有的问题在你看来都是钉子"。

## 设计备选方案实战

让我们回到"前浪微博"的场景。通过"排查法"识别了消息队列的复杂性主要体现在：高性能消息读取、高可用消息写入、高可用消息存储、高可用消息读取。接下来进行第 2 步，设计备选方案。

**备选方案 1：采用开源的 Kafka**

Kafka 是成熟的开源消息队列方案，功能强大，性能非常高，而且已经比较成熟，很多大公司都在使用。

**备选方案 2：集群 + MySQL 存储**

考虑到团队的开发语言是 Java，架构师选择基于 Netty 开发消息队列系统。由于系统设计的 QPS 是 13800，单台服务器支撑这么高的 QPS 还是有很大风险的，因此架构师选择采取集群方式来满足高性能消息读取。

对于"高可用存储"和"高可用读取"，架构师想到利用 MySQL 的主备复制功能来达到目的。具体方案：

- 采用数据分散集群的架构，集群中的服务器进行分组，每个分组存储一部分消息数据
- 每个分组包含一台主 MySQL 和一台备 MySQL，分组内主备数据复制，分组间数据不同步
- 正常情况下，分组内的主服务器对外提供消息写入和消息读取服务
- 客户端采取轮询的策略写入和读取消息

**备选方案 3：集群 + 自研存储方案**

在备选方案 2 的基础上，将 MySQL 存储替换为自研实现存储方案，因为 MySQL 的关系型数据库的特点并不是很契合消息队列的数据特点，参考 Kafka 的做法，可以自己实现一套文件存储和复制方案。

可以看出，高性能消息读取单机系统设计这部分时并没有多个备选方案可选，备选方案 2 和备选方案 3 都采取基于 Netty 的网络库，用 Java 语言开发，原因就在于团队的 Java 背景约束了备选的范围。

## 总结

- 架构设计备选方案的核心是基于已有成熟技术的组合与调整，而非凭空创造
- 设计最优秀的方案是常见误区，应遵循"合适原则"和"简单原则"
- 备选方案数量以 3~5 个为最佳，过少思维狭隘，过多精力分散
- 备选方案之间的差异要明显，技术选型是关键，细节不是
- 不要局限于熟悉的技术，保持开放的技术视野
- 备选阶段关注技术选型，而非技术细节
- 架构师需要对关键技术有深入理解，不能成为"PPT 架构师"
- 设计备选方案需要结合业务、团队、技术能力等多方面因素
- 备选方案设计是架构设计中最具创造性的环节之一

## 参考资料

- 软件架构基础

架构10：设计备选方案

## 前言

架构设计的第一步是什么？是画架构图？是选技术栈？还是写设计文档？都不是。架构设计的第一步是识别复杂度——只有正确分析出了系统的复杂性，后续的架构设计方案才不会偏离方向。如果对系统的复杂性判断错误，即使后续的架构设计方案再完美再先进，都是南辕北辙，做的越好，错的越多、越离谱。

## 识别复杂度的重要性

架构设计的本质目的是为了解决软件系统的复杂性。在我们设计架构时，首先就要分析系统的复杂性。只有正确分析出了系统的复杂性，后续的架构设计方案才不会偏离方向。

例如，如果一个系统的复杂度本来是业务逻辑太复杂、功能耦合严重，架构师却设计了一个 TPS 达到 50000/秒的高性能架构，即使这个架构最终的性能再优秀也没有任何意义，因为架构没有解决正确的复杂性问题。

架构的复杂度主要来源于"高性能""高可用""可扩展"等几个方面，但架构师在具体判断复杂性的时候，不能生搬硬套，认为任何时候架构都必须同时满足这三方面的要求。实际上**大部分场景下，复杂度只是其中的某一个，少数情况下包含其中两个，如果真的出现同时需要解决三个或者三个以上的复杂度，要么说明这个系统之前设计的有问题，要么可能就是架构师的判断出现了失误**。

## 复杂度识别的常见问题

专栏前面提到过的"亿级用户平台"失败的案例很能说明问题。设计对标腾讯的 QQ，按照腾讯 QQ 的用户量级和功能复杂度进行设计，高性能、高可用、可扩展、安全等技术一应俱全，一开始就设计出了 40 多个子系统，然后投入大量人力开发了将近 1 年时间才跌跌撞撞地正式上线。

上线后发现之前的过度设计完全是多此一举，而且带来很多问题：

- 系统复杂无比，运维效率低下，每次业务版本升级都需要十几个子系统同步升级，操作步骤复杂，容易出错，出错后回滚还可能带来二次问题
- 每次版本开发和升级都需要十几个子系统配合，开发效率低下
- 子系统数量太多，关系复杂，小问题不断，而且出问题后定位困难
- 开始设计的号称 TPS 50000/秒的系统，实际 TPS 连 500 都不到

由于业务没有发展，最初的设计人员陆续离开，后来接手的团队无奈又花了 2 年时间将系统重构，合并成不到 20 个子系统，整个系统才逐步稳定下来。

这个案例的教训是：如果一开始没有正确识别复杂度，就会导致过度设计，而过度设计带来的复杂性反而会成为系统的负担。

## 正确的做法：逐个解决

对于按照复杂度优先级解决的方式，存在一个普遍的担忧：如果按照优先级来解决复杂度，可能会出现解决了优先级排在前面的复杂度后，解决后续复杂度的方案需要将已经落地的方案推倒重来。

这个担忧理论上是可能的，但现实中几乎是不可能出现的，原因在于软件系统的可塑性和易变性。对于同一个复杂度问题，软件系统的方案可以有多个，总是可以挑出综合来看性价比最高的方案。

即使架构师决定要推倒重来，这个新的方案也必须能够同时解决已经被解决的复杂度问题，一般来说能够达到这种理想状态的方案基本都是依靠新技术的引入。例如，Hadoop 能够将高可用、高性能、大容量三个大数据处理的复杂度问题同时解决。

正确的做法是将主要的复杂度问题列出来，然后根据业务、技术、团队等综合情况进行排序，**优先解决当前面临的最主要的复杂度问题**，不要幻想一次架构重构解决所有问题。

## 识别复杂度实战：前浪微博消息队列

我们假想一个创业公司，名称叫"前浪微博"。前浪微博的业务发展很快，系统也越来越多，系统间协作的效率很低：

- 用户发一条微博后，微博子系统需要通知审核子系统进行审核，然后通知统计子系统进行统计，再通知广告子系统进行广告预测，接着通知消息子系统进行消息推送……一条微博有十几个通知，目前都是系统间通过接口调用的
- 用户等级达到 VIP 后，等级子系统要通知福利子系统进行奖品发放，要通知客服子系统安排专属服务人员，要通知商品子系统进行商品打折处理……

新来的架构师在梳理这些问题时，结合自己的经验，敏锐地发现了这些问题背后的根源在于架构上各业务子系统强耦合，而消息队列系统正好可以完成子系统的解耦。

### 背景信息

- 中间件团队规模不大，大约 6 人左右
- 中间件团队熟悉 Java 语言，但有一个新同事 C/C++ 很牛
- 开发平台是 Linux，数据库是 MySQL
- 目前整个业务系统是单机房部署，没有双机房

### 使用排查法识别复杂度

**第一步：排查是否需要高性能**

假设前浪微博系统用户每天发送 1000 万条微博，那么微博子系统一天会产生 1000 万条消息。假设平均一条消息有 10 个子系统读取，那么其他子系统读取的消息大约是 1 亿次。

1000 万和 1 亿看起来很吓人，但对于架构师来说，关注的不是一天的数据，而是 1 秒的数据，即 TPS 和 QPS。一天内平均每秒写入消息数为 115 条，每秒读取的消息数是 1150 条；再考虑系统的读写并不是完全平均的，设计的目标应该以峰值来计算。峰值一般取平均值的 3 倍，那么消息队列系统的 TPS 是 345，QPS 是 3450。

虽然根据当前业务规模计算的性能要求并不高，但业务会增长，因此系统设计需要考虑一定的性能余量。由于现在的基数较低，为了预留一定的系统容量应对后续业务的发展，我们将设计目标设定为峰值的 4 倍，因此最终的性能要求是：**TPS 为 1380，QPS 为 13800**。

TPS 为 1380 并不高，但 QPS 为 13800 已经比较高了，因此高性能读取是复杂度之一。

**第二步：排查是否需要高可用性**

对于微博子系统来说，如果消息丢了，导致没有审核，然后触犯了国家法律法规，则是非常严重的事情；对于等级子系统来说，如果用户达到相应等级后，系统没有给他奖品和专属服务，则 VIP 用户会很不满意，导致用户流失从而损失收入。

综合来看，消息队列需要高可用性，包括消息写入、消息存储、消息读取都需要保证高可用性。

**第三步：排查是否需要高可扩展性**

消息队列的功能很明确，基本无须扩展，因此可扩展性不是这个消息队列的复杂度关键。

### 排查法复杂度识别函数

以下 Python 实现了一个通用的排查法复杂度识别函数：

```python
def analyze_complexity(system_name, features, peak_factor=3, design_factor=4):
    """
    使用排查法识别系统复杂度

    参数:
        system_name: 系统名称
        features: 功能列表，每个功能包含 (名称, 每日量, 读取倍数)
        peak_factor: 峰值倍数（默认3倍）
        design_factor: 设计余量倍数（默认4倍）
    """
    print(f"=== {system_name} 复杂度分析 ===")
    print("=" * 60)

    complexities = []
    total_daily_writes = sum(f[1] for f in features)

    # 计算平均 TPS/QPS
    avg_tps = total_daily_writes / (24 * 60 * 60)
    peak_tps = avg_tps * peak_factor
    design_tps = peak_tps * design_factor

    print(f"\n【步骤1: 排查高性能需求】")
    print(f"每日总写入: {total_daily_writes:,} 条")
    print(f"平均 TPS: {avg_tps:.1f}")
    print(f"峰值 TPS (×{peak_factor}): {peak_tps:.1f}")
    print(f"设计目标 TPS (×{design_factor}): {design_tps:.0f}")

    # 判断高性能复杂度
    if design_tps > 10000:
        complexities.append(("高性能写入", "高", f"TPS {design_tps:.0f} > 10000"))
        print(f"✓ 高性能写入是复杂度: TPS {design_tps:.0f} 较高")
    else:
        complexities.append(("高性能写入", "低", f"TPS {design_tps:.0f} 不高"))
        print(f"△ 高性能写入要求不高: TPS {design_tps:.0f}")

    # 计算总读取量
    total_daily_reads = sum(f[1] * f[2] for f in features)
    avg_qps = total_daily_reads / (24 * 60 * 60)
    peak_qps = avg_qps * peak_factor
    design_qps = peak_qps * design_factor

    print(f"\n每日总读取: {total_daily_reads:,} 次")
    print(f"平均 QPS: {avg_qps:.1f}")
    print(f"峰值 QPS (×{peak_factor}): {peak_qps:.1f}")
    print(f"设计目标 QPS (×{design_factor}): {design_qps:.0f}")

    # 判断高性能读取复杂度
    if design_qps > 10000:
        complexities.append(("高性能读取", "高", f"QPS {design_qps:.0f} > 10000"))
        print(f"✓ 高性能读取是复杂度: QPS {design_qps:.0f} 较高")
    else:
        complexities.append(("高性能读取", "低", f"QPS {design_qps:.0f} 不高"))
        print(f"△ 高性能读取要求不高: QPS {design_qps:.0f}")

    print(f"\n【步骤2: 排查高可用需求】")
    for name, daily_writes, read_multiplier in features:
        if "审核" in name or "支付" in name or "订单" in name:
            complexities.append(("高可用写入", "高", f"{name} 消息丢失不可接受"))
            print(f"✓ 高可用写入是复杂度: {name} 消息丢失不可接受")
            break
    else:
        print("△ 高可用写入要求一般")

    complexities.append(("高可用存储", "高", "消息存储不能丢失"))
    print(f"✓ 高可用存储是复杂度: 消息存储不能丢失")

    print(f"\n【步骤3: 排查可扩展性需求】")
    print("△ 可扩展性要求不高: 功能明确，无特殊扩展需求")

    # 按优先级排序
    print(f"\n【复杂度排序结果】")
    print("=" * 60)
    # 高复杂度排在前面
    complexity_order = []
    for name, level, reason in complexities:
        if level == "高":
            complexity_order.append((name, reason))

    for i, (name, reason) in enumerate(complexity_order, 1):
        print(f"{i}. {name}: {reason}")

    return complexity_order


# 前浪微博消息队列案例
features = [
    ("微博发布", 10_000_000, 10),  # 每日1000万条，10个子系统读取
    ("等级变化", 500_000, 5),      # 每日50万条，5个子系统读取
]

result = analyze_complexity("前浪微博消息队列系统", features)
```

**输出示例：**
```
=== 前浪微博消息队列系统 复杂度分析 ===
============================================================

【步骤1: 排查高性能需求】
每日总写入: 10,500,000 条
平均 TPS: 121.5
峰值 TPS (×3): 364.5
设计目标 TPS (×4): 1458

✓ 高性能写入是复杂度: TPS 1458 较高

每日总读取: 107,500,000 次
平均 QPS: 1244.2
峰值 QPS (×3): 3732.7
设计目标 QPS (×4): 14931

✓ 高性能读取是复杂度: QPS 14931 较高

【步骤2: 排查高可用需求】
✓ 高可用写入是复杂度: 微博发布 消息丢失不可接受
✓ 高可用存储是复杂度: 消息存储不能丢失

【步骤3: 排查可扩展性需求】
△ 可扩展性要求不高: 功能明确，无特殊扩展需求

【复杂度排序结果】
============================================================
1. 高性能读取: QPS 14931 较高
2. 高可用写入: 微博发布 消息丢失不可接受
3. 高可用存储: 消息存储不能丢失
```

这个示例展示了如何系统地使用排查法识别复杂度，最终确定前浪微博消息队列系统的复杂性主要体现在四个方面：高性能消息读取、高可用消息写入、高可用消息存储、高可用消息读取。

## 总结

- 架构设计第1步是识别复杂度，只有正确分析复杂度，后续方案才不会偏离方向；如果对复杂性判断错误，方案越完美越离谱
- 复杂度可能只有一个，也可能是两个，极少三个以上；如果同时需要解决三个以上的复杂度，要么说明系统之前设计有问题，要么架构师判断失误
- "亿级用户平台"过度设计教训：40+子系统→TPS 500都不到→重构为20个子系统；根源是一开始没有正确识别复杂度
- 正确的做法是将主要的复杂度问题列出来，按优先级排序，一个一个解决，不要幻想一次解决所有问题
- 软件系统的可塑性和易变性使得推倒重来几乎不可能发生，因为总有性价比更高的方案可以选择
- 前浪微博消息队列案例使用排查法分析：TPS=1380（不高），QPS=13800（较高），高可用（消息丢失不可接受）
- 复杂度排序结果：高性能读取 > 高可用写入 > 高可用存储 > 高可用读取
- 设计目标不一定要固定为峰值的4倍，不同业务可以是2倍或8倍，但一般不要设定在10倍以上，更不要一上来就按照100倍预估
- 新技术引入可以同时解决多个复杂度问题（如Hadoop解决高可用、高性能、大容量），但这是可遇不可求的
- 识别复杂度对架构师来说是一项挑战，有经验的架构师一看需求就知道复杂度大概在哪里，如果经验不足，只能采取排查法从不同角度逐一分析

## 参考

- 软件架构基础


架构9：设计流程：识别复杂度

## 前言

为什么有的架构师设计方案精美却最终失败？为什么技术最强的团队反而做不出最好的系统？答案藏在架构设计的三大原则之中：合适、简单、演化。这三个原则不是空洞的理论，而是大量成功与失败案例的总结。理解它们，才能真正做出好的架构设计。

## 架构设计的不确定性

编程的结果是确定的——同样的代码，无论谁写、何时执行，结果都应该一致。但架构设计截然不同：同样的系统，A 公司和 B 公司做出来的架构可能差异很大；同样的方案，A 设计师认为该这样做，B 设计师认为该那样做，看起来都有道理。架构设计没有像编程语言那样的语法约束，更多时候是面对多种可能性进行选择。

这种不确定性让架构师常常陷入两难：选最先进的技术还是团队最熟悉的技术？选 Angular 还是 React？选 MySQL 还是 MongoDB？淘宝的电商架构很完善，新做一个电商网站，是否照搬淘宝就可以了？这些困惑的背后，是因为架构设计领域并没有一套通用规范来指导架构师进行选择。

但通过研究架构设计的发展历史、多个公司的架构演进过程（QQ、淘宝、Facebook 等），我发现有几个共性原则隐含其中：**合适原则、简单原则、演化原则**。

## 原则一：合适原则

**合适原则宣言："合适优于业界领先"。**

优秀的技术人员都有很强的技术情结，做方案或架构时总想达到甚至优于业界领先水平——这样才显得优秀，才能在 KPI 总结里骄傲地写上"设计了 XX 方案，达到了和 Google 相同的技术水平"。但现实是，大部分这样想和这样做的架构，最后都以失败告终。

### 三个失败原因

**1. 将军难打无兵之仗**

大公司分工细，一个小系统可能就是一个小组负责。比如某个通信大厂做一个 OM 管理系统就有十几个人，阿里的中间件团队有几十个人。而大部分公司整个研发团队可能就 100 多人，某个业务团队可能就十几个人。十几个人的团队，想做几十个人的团队的事情，难度可想而知。没那么多人，却想干那么多活，是失败的第一个主要原因。

**2. 罗马不是一天建成的**

业界领先的方案并不是一堆天才某个时期灵机一动、加班加点就做出来的，而是经过几年时间的发展才逐步完善和初具规模的。阿里中间件团队 2008 年成立，发展到现在已经十几年了。我们只知道他们抗住了多少次"双 11"，做了多少优秀的系统，但经历了什么样的挑战、踩了什么样的坑，只有他们自己知道。没有那么多积累，却想一步登天，是失败的第二个主要原因。

**3. 冰山下面才是关键**

业界领先的方案其实都是"逼"出来的。业务发展到一定阶段，量变导致质变，出现了新的问题，已有的方式不能应对，需要用新方案来解决，通过创新和尝试，才有了业界领先的方案。GFS 为何在 Google 诞生，而不是在 Microsoft 诞生？因为 Google 有那么庞大的数据，而不是因为 Google 的工程师比 Microsoft 的工程师更聪明。没有那么卓越的业务场景，却幻想灵光一闪成为天才，是失败的第三个主要原因。

真正优秀的架构都是在企业当前人力、条件、业务等各种约束下设计出来的，能够合理地将资源整合在一起并发挥出最大功效，并且能够快速落地。这也是很多 BAT 出来的架构师到了小公司或者创业团队反而做不出成绩的原因——没有了大公司的平台、资源、积累，只是生搬硬套大公司的做法，失败的概率非常高。

## 原则二：简单原则

**简单原则宣言："简单优于复杂"。**

软件架构设计是一门技术活。从历史上看，无论是瑞士的钟表、瓦特的蒸汽机、莱特兄弟发明的飞机，还是摩托罗拉发明的手机，无一不是越来越精细、越来越复杂。因此当我们进行架构设计时，会自然而然地想把架构做精美、做复杂，这样才能体现技术实力，也才能够将架构做成一件艺术品。

由于软件架构和建筑架构表面上的相似性，我们也会潜意识地将对建筑的审美观点移植到软件架构上。我们惊叹于长城的宏伟、泰姬陵的精美、悉尼歌剧院的艺术感、迪拜帆船酒店的豪华感，因此对于我们自己亲手打造的软件架构，我们也希望它宏伟、精美、艺术、豪华。

团队的压力也会促进我们走向复杂的方向，因为大部分人在评价一个方案水平高低时，复杂性是其中一个重要参考指标。例如设计一个主备方案，如果你用心跳来实现，可能大家都认为这太简单了。但如果你引入 ZooKeeper 来做主备决策，可能很多人会认为这个方案更加"高大上"。真正理解 ZAB 协议的人很少，但并不妨碍我们都知道 ZAB 协议很优秀。

这些原因会促使初出茅庐的架构师不自觉地追求架构的复杂性。然而，"复杂"在制造领域代表先进，在建筑领域代表领先，但在软件领域，却恰恰相反，**复杂代表的是问题**。

### 结构复杂性

结构复杂的系统几乎毫无例外具备两个特点：组成复杂系统的组件数量更多，同时这些组件之间的关系也更加复杂。

以组件故障率为例，假设组件的故障率是 10%（有 10% 的时间不可用），那么有 3 个组件的系统可用性是 (1-10%) × (1-10%) × (1-10%) = 72.9%，有 5 个组件的系统可用性是 (1-10%) × (1-10%) × (1-10%) × (1-10%) × (1-10%) = 59%。两者可用性相差 13%。

结构复杂性还存在其他问题：某个组件改动会影响关联的所有组件，这些被影响组件会递归影响更多组件；定位问题比简单系统更加困难，因为组件多，每个组件都有嫌疑，而组件间关系复杂，表现故障的组件可能并不是真正问题的根源。

### 逻辑复杂性

除了结构复杂性，还有逻辑复杂性。如果某个组件的逻辑太复杂，一样会带来各种问题。逻辑复杂的组件，典型特征就是单个组件承担了太多的功能。以电商业务为例，常见的功能有：商品管理、商品搜索、商品展示、订单管理、用户管理、支付、发货、客服……把这些功能全部在一个组件中实现，就是典型的逻辑复杂性。

逻辑复杂几乎会导致软件工程每个环节都有问题：如果淘宝将这些功能全部在单一的组件中实现，系统会很庞大，可能是上百万、上千万的代码规模，"clone"一次代码要 30 分钟；几十、上百人维护这一套代码，某个"菜鸟"不小心改了一行代码，可能导致整站崩溃。

为什么复杂的电路意味着更强大的功能，而复杂的架构却有很多问题？根本原因在于电路设计好后进入生产就不会再变，复杂性只在设计时带来影响；而软件系统在投入使用后，后续还有源源不断的需求要实现，复杂性在整个系统生命周期中都有很大影响。

无论是结构的复杂性，还是逻辑的复杂性，都会存在各种问题，所以架构设计时如果简单的方案和复杂的方案都可以满足需求，**最好选择简单的方案**。《UNIX 编程艺术》总结的 KISS（Keep It Simple, Stupid!）原则一样适用于架构设计。

## 原则三：演化原则

**演化原则宣言："演化优于一步到位"。**

软件架构从字面意思理解和建筑结构非常类似，维基百科对"软件架构"的定义中有一段话描述了这种相似性：从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。然而，字面意思上的相似性却掩盖了一个本质上的差异：建筑一旦完成（甚至一旦开建）就不可再变，而软件却需要根据业务的发展不断地变化。

古埃及的吉萨大金字塔，4000 多年前完成的，到现在还是当初的架构。中国的明长城，600 多年前完成的，现在保存下来的长城还是当年的结构。美国白宫，1800 年建成，200 年来进行了几次扩展，但整体结构并无变化。

对比一下 Windows 系统的发展历史：Windows 1.0（1985 年）和 Windows 8（2012 年），如果对比这两个系统的架构，会发现它们其实是两个不同的系统了。Android 的发展历史同样如此，Android 6.0 和 Android 1.6 的差异也很大。

对于建筑来说，永恒是主题；而对于软件来说，变化才是主题。软件架构需要根据业务的发展而不断变化。设计 Windows 和 Android 的人都是顶尖的天才，即便如此，他们也不可能在 1985 年设计出 Windows 8，不可能在 2009 年设计出 Android 6.0。

如果没有把握"软件架构需要根据业务发展不断变化"这个本质，在做架构设计时就很容易陷入一个误区：试图一步到位设计一个软件架构，期望不管业务如何变化，架构都稳如磐石。为了实现这样的目标，要么照搬业界大公司公开发表的方案，要么投入庞大的资源和时间来做预测和分析。无论哪种做法，后果都很明显：投入巨大，落地遥遥无期。

考虑到软件架构需要根据业务发展不断变化这个本质特点，软件架构设计其实更加类似于大自然"设计"一个生物，通过演化让生物适应环境，逐步变得更加强大：首先生物要适应当时的环境，其次生物需要不断地繁殖，将有利的基因传递下去，将不利的基因剔除或者修复。

## 可用性计算示例

以下 Python 示例展示了组件数量对系统可用性的影响：

```python
def calculate_availability(component_count, individual_availability=0.90):
    """计算系统整体可用性，假设每个组件可用性相同且独立"""
    return individual_availability ** component_count

# 示例：对比不同组件数量的系统可用性
print("组件故障率 10%，各组件独立")
print("=" * 40)

for n in [1, 2, 3, 5, 10]:
    avail = calculate_availability(n, 0.90)
    downtime = (1 - avail) * 365 * 24 * 60  # 年故障分钟数
    print(f"{n} 个组件: 可用性={avail:.2%}, 年故障约 {downtime:.0f} 分钟")

print()
print("对比: 单组件 99% vs 90% 可用性")
print("=" * 40)
for avail in [0.99, 0.90]:
    for n in [1, 3, 5]:
        result = calculate_availability(n, avail)
        print(f"单组件可用性 {avail:.0%}, {n} 个组件: 整体可用性={result:.4f}")
```

**输出示例：**
```
组件故障率 10%，各组件独立
========================================
1 个组件: 可用性=90.00%, 年故障约 52560 分钟
2 个组件: 可用性=81.00%, 年故障约 9878 分钟
3 个组件: 可用性=72.90%, 年故障约 14212 分钟
5 个组件: 可用性=59.00%, 年故障约 21504 分钟
10 个组件: 可用性=34.87%, 年故障约 32846 分钟

对比: 单组件 99% vs 90% 可用性
========================================
单组件可用性 99%, 3 个组件: 整体可用性=0.9703
单组件可用性 99%, 5 个组件: 整体可用性=0.9510
单组件可用性 90%, 3 个组件: 整体可用性=0.7290
单组件可用性 90%, 5 个组件: 整体可用性=0.5905
```

这个示例清楚说明了为什么简单原则强调组件数量越多系统可用性越低。在实际架构设计中，我们需要权衡功能拆分带来的独立性与可用性下降之间的矛盾。

## 总结

- 架构设计结果不确定，与编程的确定性形成鲜明对比，架构师需要学会在多种可能性中做出选择
- **合适原则**：优秀架构在企业当前人力、条件、业务约束下设计，能合理整合资源并快速落地，"将军难打无兵之仗、罗马不是一天建成、冰山下面才是关键"是三个主要失败原因
- **简单原则**：软件领域复杂代表问题而非先进，结构复杂性（组件越多故障率越高：3组件72.9% vs 5组件59%）和逻辑复杂性（单组件功能太多→上百万行代码）都会带来严重问题
- **演化原则**：建筑永恒而软件变化，Windows/Android 都经历了巨大演变，软件架构需跟随业务演化，无法一步到位
- 架构设计的本质目的是解决软件系统复杂度带来的问题，三大原则指导我们做出正确选择
- 不要试图一步到位设计完美架构，罗马不是一天建成的，架构需要在业务发展中逐步演进
- 合适原则优先考虑——先满足业务当前需求；简单原则次之——挑选简单方案快速落地；演化原则第三——适当预测业务发展
- 引入新技术或创造新技术是实现低成本的主要手段，但中小公司一般靠引入新技术，大公司才有可能自己创造新技术

## 参考

- 软件架构基础
- 《UNIX 编程艺术》，KISS 原则
- 淘宝技术发展历史
- QQ 亿级用户架构演进

架构8：架构设计三原则

## 前言

除了高性能和高可用之外，架构设计还面临三个重要的复杂度来源：低成本、安全和规模。这三者各有其独特的挑战和应对策略。理解它们的本质，有助于架构师在设计中做出更明智的决策。

## 低成本：架构设计的附加约束

当架构方案只涉及几台或十几台服务器时，成本通常不是重点关注目标。但如果架构方案涉及几百上千甚至上万台服务器，成本就会变成一个非常重要的考虑点。

例如：A 方案需要 10000 台机器，B 方案只需要 8000 台机器，单从比例来看节省了 20%，但从数量来看，B 方案能节省 2000 台机器。按照每台机器每年约 2 万元成本计算，一年就能节省 4000 万元——这笔钱足以给 100 人的团队每人发 40 万元奖金。

**低成本的本质**：设计"高性能"和"高可用"的架构时，通用手段都是增加更多服务器；而低成本正好与此相反，需要减少服务器数量才能达成。因此，低成本本质上是与高性能和高可用冲突的。

基于这个原因，**低成本很多时候不是架构设计的首要目标，而是附加约束**。通常的流程是：先根据高性能、高可用的要求设计架构，然后评估是否满足成本目标，如果不行则重新设计。

**低成本给架构设计带来的主要复杂度体现在：往往只有"创新"才能达到低成本目标**。这里的"创新"包括两种形式：

**引入新技术**：

- NoSQL（Memcache、Redis 等）——解决关系型数据库无法应对高并发访问的问题
- 全文搜索引擎（Sphinx、Elasticsearch、Solr）——解决关系型数据库 like 搜索的低效问题
- Hadoop——解决传统文件系统无法应对海量数据存储和计算的问题

**创造新技术**：

- Facebook 为解决 PHP 的低效问题，开发了 HipHop PHP（将 PHP 翻译为 C++）和 HHVM（将 PHP 翻译为字节码）
- 新浪微博将传统的 Redis/MC + MySQL 扩展为 Redis/MC + SSD Cache + MySQL 方式
- Linkedin 为处理每天 5 千亿的事件，开发了高效的 Kafka 消息系统

引入新技术的主要复杂度在于需要去熟悉新技术，并且将新技术与已有技术结合起来。创造新技术则复杂度更高，需要自己去创造全新的理念和技术，且与旧技术相比需要有质的飞跃。

## 安全：功能安全与架构安全

安全本身是一个庞大而又复杂的技术领域，一旦出问题，对业务和企业形象影响非常大。

从技术角度来讲，安全可以分为两类：

**1. 功能安全（"防小偷"）**

常见的功能安全攻击包括 XSS 攻击、CSRF 攻击、SQL 注入、密码破解等。这些攻击的本质是因为系统实现有漏洞，黑客利用漏洞潜入系统进行破坏或盗取。

功能安全更多是和具体的编码相关，与架构关系不大。虽然现在很多开发框架都内嵌了常见的安全功能，能够减少安全相关功能的重复开发，但框架只能预防常见的安全漏洞，无法预知新的安全问题，而且框架本身也可能存在漏洞（如 Apache Struts2 多次爆出的远程代码执行高危漏洞）。

功能安全是一个"攻"与"防"的矛盾，只能在这种攻防大战中逐步完善，不可能在系统架构设计时一劳永逸地解决。

**2. 架构安全（"防强盗"）**

如果说功能安全是"防小偷"，那么架构安全就是"防强盗"。强盗会直接用大锤将门砸开，或者用炸药将围墙炸倒——很多时候就是故意搞破坏，对系统的影响要大得多。

传统的架构安全主要依靠防火墙。防火墙通过将网络划分成不同的区域，制定出不同区域之间的访问控制策略来控制不同信任程度区域间传送的数据流。

但在互联网领域，防火墙的应用场景并不多。原因在于：

- 互联网业务具有海量用户访问和高并发的特点，防火墙性能不足以支撑
- 互联网领域的 DDoS 攻击规模很大，2016 年知名安全研究人员布莱恩·克莱布斯的安全博客网站遭遇的 DDoS 攻击，带宽达 665Gbps
- 即使花几百万元买防火墙设备，当出口带宽被耗尽时，业务在用户看来还是不可用的

基于上述原因，互联网系统的架构安全更多依靠运营商或云服务商强大的带宽和流量清洗能力，较少自己来设计和实现。

## 规模：量变引起质变

规模带来复杂度的主要原因是"量变引起质变"，当数量超过一定的阈值后，复杂度会发生质的变化。

**1. 功能复杂度：指数级增长**

以一个简单的抽象模型计算：假设系统间的功能都是两两相关的，系统的复杂度 = 功能数量 + 功能之间的连接数量。

连接数量的计算公式：n × (n-1) / 2

```
3 个功能的系统复杂度 = 3 + 3 = 6
8 个功能的系统复杂度 = 8 + 28 = 36
```

复杂度不是线性增长，而是呈指数级增长，主要原因在于随着系统功能数量增多，功能之间的连接呈指数级增长。

**2. 数据复杂度：质变临界点**

即使数据没有达到大数据规模，增长也可能给系统带来复杂性。以 MySQL 为例，单表数据量一般在 5000 万行左右。如果单表数据达到 10 亿行，会产生很多问题：

- 添加索引会很慢，可能需要几个小时，期间数据库表无法插入数据
- 修改表结构和添加索引耗时很长
- 即使有索引，性能也会很低
- 数据库备份耗时很长

当 MySQL 单表数据量太大时，必须考虑将单表拆分为多表，这个拆分过程也会引入更多复杂性。

## Python 示例：功能数量与复杂度关系

下面通过 Python 示例演示功能数量与复杂度的关系：

```python
"""
功能数量与复杂度关系示例
用于演示 n 个功能之间的连接数如何呈指数级增长

复杂度公式：complexity = n + n*(n-1)/2 = n*(n+1)/2
- n: 功能数量
- n*(n-1)/2: 功能间的两两连接数
"""


def calculate_complexity(n: int) -> tuple[int, int, int]:
    """
    计算 n 个功能的复杂度

    Returns:
        (功能数, 连接数, 总复杂度)
    """
    connections = n * (n - 1) // 2
    total = n + connections
    return n, connections, total


def print_complexity_table():
    """打印复杂度表格"""
    print("功能数量 | 连接数  | 总复杂度 | 增长趋势")
    print("-" * 50)

    prev_total = 0
    for n in [3, 5, 8, 10, 15, 20, 30, 50]:
        n_count, connections, total = calculate_complexity(n)
        growth = f"+{total - prev_total}" if prev_total > 0 else ""
        print(f"{n_count:^8} | {connections:^6} | {total:^7} | {growth}")
        prev_total = total

    print("\n结论：")
    print("- 功能数从 3 增长到 50（增长约 17 倍）")
    print("- 连接数从 3 增长到 1225（增长约 408 倍）")
    print("- 总复杂度从 6 增长到 1275（增长约 213 倍）")
    print("- 连接数的增长速度远超功能数，这就是'量变引起质变'")


def demo_connection_growth():
    """演示连接数的指数级增长"""
    print("\n=== 连接数增长演示 ===")

    # 计算不同功能数量下的连接数
    test_sizes = [5, 10, 20, 50, 100]
    print("\n功能数 | 连接数 | 连接数/功能数比值")
    print("-" * 40)

    for size in test_sizes:
        connections = size * (size - 1) // 2
        ratio = connections / size
        print(f"{size:^6} | {connections:^6} | {ratio:^10.1f}")


if __name__ == "__main__":
    print_complexity_table()
    demo_connection_growth()

    # 预期输出：
    # 功能数量 | 连接数  | 总复杂度 | 增长趋势
    # -------------------------------------------------
    #    3    |   3    |    6     |
    #    5    |   10   |    15    | +9
    #    8    |   28   |    36    | +21
    #    10   |   45   |    55    | +19
    #    15   |  105   |   120    | +65
    #    20   |  190   |   210    | +90
    #    30   |  435   |   465    | +255
    #    50   |  1225  |  1275    | +810
    #
    # 结论：
    # - 功能数从 3 增长到 50（增长约 17 倍）
    # - 连接数从 3 增长到 1225（增长约 408 倍）
    # - 总复杂度从 6 增长到 1275（增长约 213 倍）
    # - 连接数的增长速度远超功能数，这就是'量变引起质变'
```

运行结果：

```
功能数量 | 连接数  | 总复杂度 | 增长趋势
-------------------------------------------------
    3    |   3    |    6     |
    5    |   10   |    15    | +9
    8    |   28   |    36    | +21
    10   |   45   |    55    | +19
    15   |  105   |   120    | +65
    20   |  190   |   210    | +90
    30   |  435   |   465    | +255
    50   |  1225  |  1275    | +810

结论：
- 功能数从 3 增长到 50（增长约 17 倍）
- 连接数从 3 增长到 1225（增长约 408 倍）
- 总复杂度从 6 增长到 1275（增长约 213 倍）
- 连接数的增长速度远超功能数，这就是'量变引起质变'


=== 连接数增长演示 ===

功能数 | 连接数 | 连接数/功能数比值
----------------------------------------
  5    |   10   |        2.0
  10   |   45   |        4.5
  20   |  190   |        9.5
  50   |  1225  |       24.5
  100  |  4950  |       49.5
```

这个示例清晰地展示了功能数量增长带来的复杂度爆炸：当功能数从 10 增长到 100（10 倍），连接数却从 45 增长到 4950（110 倍）。这就是架构设计中"量变引起质变"的典型现象。

## 总结

- 低成本本质上是与高性能和高可用冲突的，是架构设计的附加约束而非首要目标
- 低成本的主要实现手段是"创新"，包括引入新技术（NoSQL、搜索引擎等）或创造新技术（Facebook HipHop、Linkedin Kafka 等）
- 功能安全（防小偷）主要与编码相关，是逐步完善的过程，无法一劳永逸解决
- 架构安全（防强盗）针对蓄意破坏，防火墙在互联网场景下因性能和成本问题应用不多，互联网更多依靠运营商或云服务商的流量清洗能力
- 规模带来复杂度的核心原因是"量变引起质变"
- 功能复杂度呈指数级增长：n 个功能带来 n×(n-1)/2 个连接，总复杂度 = n×(n+1)/2
- MySQL 单表数据量建议控制在 5000 万行以内，超过需要拆表
- 数据量过大带来的问题包括：添加索引慢、修改表结构慢、索引性能低、备份耗时长等
- 拆表会引入新的复杂性：拆表规则选择、查询如何处理等问题
- 规模问题需要与高性能、高可用、高扩展、高伸缩性统一考虑，这是架构设计中的综合挑战

## 参考

- 软件架构基础


架构7：低成本安全与规模

## 前言

在软件系统中，应对需求变化是一项永恒的挑战。可扩展性正是解决这一挑战的核心能力——当新需求出现时，系统不需要或仅需少量修改就可以支持，无须整个系统重构或重建。本文深入分析可扩展性复杂度的来源，帮助读者理清预测变化与应对变化之间的微妙关系。

## 什么是可扩展性

可扩展性（Scalability）指系统为了应对将来需求变化而提供的一种扩展能力。当有新的需求出现时，系统不需要或者仅需要少量修改就可以支持，无须整个系统重构或者重建。

由于软件系统固有的多变性，新的需求总会不断被提出，因此可扩展性显得尤其重要。在软件开发领域，面向对象思想的提出就是为了解决可扩展性带来的问题；后来的设计模式，更是将可扩展性做到了极致。

设计具备良好可扩展性的系统，有两个基本条件：

- 正确预测变化
- 完美封装变化

但要达成这两个条件，本身也是一件复杂的事情。

## 预测变化的复杂性

为什么预测变化是一件复杂的事情？因为预测本身就意味着不确定性。

如果架构师按照"唯一不变的是变化"这个标准去衡量，每个设计方案都要考虑可扩展性。例如，架构师准备设计一个简单的后台管理系统，需要考虑：用 MySQL 存储数据时，是否要考虑后续用 Oracle？用 HTTP 做接口协议时，是否要支持 ProtocolBuffer？甚至是否要考虑 VR 技术对架构的影响？

这种做法会导致两个极端问题：

**问题一：过度考虑，不堪重负**

如果每个设计点都考虑可扩展性，架构师会不堪重负，架构设计也会异常庞大且最终无法落地。

**问题二：完全不考虑，上线即重构**

如果架构师完全不做预测，可能系统刚上线，马上就来新需求需要重构，前期投入的工作量全部白费。

**问题三：预测本身可能出错**

"预测"这个词本身就暗示了不可能每次都准确。如果预测的事情出错，期望中的需求迟迟不来，甚至被明确否定，那么基于预测做的架构设计就没什么作用。

综合分析，预测变化的复杂性在于：不能每个设计点都考虑可扩展性，不能完全不考虑可扩展性，且所有的预测都存在出错的可能性。对于架构师来说，如何把握预测的程度和提升预测结果的准确性，是一件很复杂的事情，没有通用的标准可以简单套用。

## 应对变化方案一：变化层与稳定层分离

假设架构师经验丰富，看问题非常准，能够准确预测所有的变化，是否就意味着可扩展性很容易实现？也没那么理想！因为预测变化是一回事，采取什么方案来应对变化，又是另外一个复杂的事情。

第一种应对变化的常见方案是将"变化"封装在一个"变化层"，将不变的部分封装在一个独立的"稳定层"。

无论采取哪种形式（变化层依赖稳定层，或稳定层依赖变化层），通过剥离变化层和稳定层的方式都会带来复杂性：

1. **系统需要拆分出变化层和稳定层**：对于哪些属于变化层，哪些属于稳定层，很多时候并不是像示例中那样明确。不同的人有不同的理解，可能导致架构设计评审时吵翻天。

2. **需要设计变化层和稳定层之间的接口**：对于稳定层来说，接口肯定是越稳定越好；但对于变化层来说，在有差异的多个实现方式中找出共同点，并且保证当加入新的功能时原有的接口设计不需要太大修改，这是一件很复杂的事情。

## 应对变化方案二：抽象层+实现层

第二种常见的应对变化的方案是提炼出一个"抽象层"和一个"实现层"。抽象层是稳定的，实现层可以根据具体业务需要定制开发，当加入新的功能时，只需要增加新的实现，无须修改抽象层。这种方案典型的实践就是设计模式和规则引擎。

以装饰者模式为例，类关系图如下：

```
Component（抽象组件）
 ├── TextView（具体组件）
 └── Decorator（抽象装饰者）
 ├── BorderDecorator（具体装饰者）
 ├── ScrollBarDecorator（具体装饰者）
 └── BackgroundDecorator（具体装饰者）
```

装饰者模式的规则包括：

1. Component 和 Decorator 类
2. Decorator 类继承 Component 类
3. Decorator 类聚合了 Component 类

这个规则一旦抽象出来后就固定了，不能轻易修改。装饰者模式相比传统的继承来实现功能，确实灵活很多——能够灵活地给 TextView 增加额外功能（边框、滚动条、背景图片等），这些功能上的组合不影响规则，只需要按照规则实现即可。

但装饰者模式相对普通的类实现模式，明显要复杂多了。本来一个函数或者一个类就能搞定的事情，现在要拆分成多个类，而且多个类之间必须按照装饰者模式来设计和调用。

规则引擎和设计模式类似，都是通过灵活的设计来达到可扩展的目的，但"灵活的设计"本身就是一件复杂的事情。

## Python 示例：抽象层+实现层模式

下面通过一个简单的插件/过滤器系统演示"抽象层+实现层"模式：

```python
"""
抽象层 + 实现层模式示例：插件过滤器系统
用于演示如何通过抽象层和实现层分离，实现可扩展性
"""

from abc import ABC, abstractmethod
from typing import List


# ============ 抽象层（稳定层） ============
class PluginFilter(ABC):
 """抽象过滤器接口 - 稳定层"""

 @abstractmethod
 def process(self, data: str) -> str:
 """处理数据"""
 pass

 @abstractmethod
 def get_name(self) -> str:
 """获取过滤器名称"""
 pass


class FilterPipeline:
 """过滤器管道 - 组合多个过滤器"""

 def __init__(self):
 self._filters: List[PluginFilter] = []

 def add_filter(self, filter_impl: PluginFilter):
 """添加过滤器实现（无需修改抽象层）"""
 self._filters.append(filter_impl)

 def process(self, data: str) -> str:
 """按顺序执行所有过滤器"""
 result = data
 for filter_impl in self._filters:
 result = filter_impl.process(result)
 return result


# ============ 实现层（变化层） ============
class UpperCaseFilter(PluginFilter):
 """具体实现：大写转换过滤器"""

 def process(self, data: str) -> str:
 return data.upper()

 def get_name(self) -> str:
 return "UpperCaseFilter"


class TrimFilter(PluginFilter):
 """具体实现：去首尾空格过滤器"""

 def process(self, data: str) -> str:
 return data.strip()

 def get_name(self) -> str:
 return "TrimFilter"


class ReplaceFilter(PluginFilter):
 """具体实现：替换过滤器"""

 def __init__(self, old: str, new: str):
 self._old = old
 self._new = new

 def process(self, data: str) -> str:
 return data.replace(self._old, self._new)

 def get_name(self) -> str:
 return f"ReplaceFilter('{self._old}'->'{self._new}')"


# ============ 新增功能（扩展实现层，无需修改抽象层） ============
class MarkdownFilter(PluginFilter):
 """新增的 Markdown 转 HTML 过滤器 - 演示可扩展性"""

 def process(self, data: str) -> str:
 # 简单 Markdown 转换
 import re
 data = re.sub(r'\*\*(.+?)\*\*', r'\1', data)
 data = re.sub(r'\*(.+?)\*', r'\1', data)
 return data

 def get_name(self) -> str:
 return "MarkdownFilter"


# ============ 使用示例 ============
if __name__ == "__main__":
 # 创建管道
 pipeline = FilterPipeline()

 # 添加过滤器实现
 pipeline.add_filter(TrimFilter())
 pipeline.add_filter(UpperCaseFilter())
 pipeline.add_filter(ReplaceFilter(" ", "_"))

 # 处理数据
 data = " hello world "
 result = pipeline.process(data)
 print(f"原始数据: '{data}'")
 print(f"处理结果: '{result}'")

 # 动态添加新的过滤器（无需修改抽象层）
 pipeline.add_filter(MarkdownFilter())
 data2 = "**bold** and *italic*"
 result2 = pipeline.process(data2)
 print(f"\n原始数据: '{data2}'")
 print(f"处理结果: '{result2}'")

 # 预期输出：
 # 原始数据: ' hello world '
 # 处理结果: 'HELLO_WORLD'
 #
 # 原始数据: '**bold** and *italic*'
 # 处理结果: 'bold and italic'
```

运行结果：

```
原始数据: ' hello world '
处理结果: 'HELLO_WORLD'

原始数据: '**bold** and *italic*'
处理结果: 'BOLD AND ITALIC'
```

这个示例展示了"抽象层+实现层"模式的核心优势：当需要新增功能时（如 MarkdownFilter），只需要增加新的实现类，无需修改抽象层（PluginFilter 接口）和管道类（FilterPipeline）。这正是开闭原则（对扩展开放，对修改关闭）的体现。

## 总结

- 可扩展性是系统应对未来需求变化的能力，新需求出现时系统不需要或仅需少量修改就可以支持
- 实现良好可扩展性需要满足两个基本条件：正确预测变化、完美封装变化
- 预测变化的复杂性体现在三个方面：不能每个点都考虑（不堪重负）、不能完全不考虑（上线即重构）、预测本身可能出错
- 方案一"变化层与稳定层分离"：通过剥离变化层和稳定层来应对变化，但需要解决接口设计和分层边界的问题
- 方案二"抽象层+实现层"：抽象层稳定，实现层可定制扩展，典型实践是设计模式和规则引擎
- 装饰者模式通过 Component+Decorator 规则实现灵活组合，但相比普通类实现复杂度更高
- 可扩展性的"灵活设计"本身就是复杂的事情，需要在灵活性和复杂度之间取得平衡
- 过度追求可扩展性会导致架构臃肿，过度忽视可扩展性会导致频繁重构
- 架构师需要根据业务实际情况判断可扩展性设计的代价，选择合适的设计方案
- 好的可扩展性设计应该遵循开闭原则：对扩展开放，对修改关闭

## 参考

- 软件架构基础