# 前言
本文从 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原则告诉我们，架构即不断正交分解，组合是乘法，继承是加法。
* 核心系统伤害值公式告诉我们，核心系统越干净，增加新功能越容易。
* 模块耦合度公式告诉我们，依赖外部成熟模块比依赖不成熟模块更安全。

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

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

## 参考资料

- 软件架构基础


架构31：架构思维：设计准则

# 前言

架构的第一步是什么？很多人会脱口而出：画图、选型、搭框架。但真正在水中游过泳的人才知道，下水之前，最重要的是看清水流的方向。

需求分析，就是这潭水里最容易被忽略的暗礁。

# 为何要做需求分析

做软件的目的，是满足用户需求。这个答案简单到几乎没有人会质疑。但真正的问题在于：用户需求是什么？你真的清楚吗？

需求分析的必要性，体现在三个层面。

## 理解用户，是一切的起点

用户需求不是一份问卷调查能够穷尽的。用户说出的话，往往已经带着他所熟悉的技术方案的烙印。举个通俗的例子：用户说"我需要一匹更快的马"，但他的真实需求是"更快到达目的地"。从"马"到"速度"到"到达"，这是三次跳跃，每一次跳跃都是一次需求的重新定义。

架构师如果只听到"马"，那么费尽周折引进千里马，却发现用户真正需要的是一列火车——这种错位，是灾难性的。

## 边界厘清，决定了产品能做什么、不能做什么

用户需求想清楚了，并不代表产品边界就清晰了。任何行业的用户需求满足，必然存在行业分工。我们做什么，合作伙伴做什么，谁负责连接，谁负责交付——这些边界如果不能清晰划定，产品就会像一块无限膨胀的海绵，最终失去形状。

架构设计需要对子系统进行切分，而切分的依据，正是经过归纳与抽象后的用户需求。边界不清的系统，模块之间的耦合必然如同乱麻。

## 防止过度设计，是需求分析最重要的副产品

什么是过度设计？尚未发生的事情，你提前为它做足了准备——这就是过度设计。

判断是否过度设计并不容易，它要求对需求未来的演化有精准的预判力。而这种预判力，恰恰来自于扎实的需求分析。脱离需求谈扩展性，是架构师最容易踩进的泥潭：为了一个"也许会用到"的功能，搭起了一套"永远不会被调用"的框架，代码复杂度陡增，维护成本悄然攀升，等到真正需要重构的时候，才发现地基已经锈迹斑斑。

# 需求分析，究竟在分析什么

需求分析的过程，必然涉及以下这些内容的思考。

面向的核心用户人群是谁？用户的原始需求是什么，最核心的问题是哪几个？在这个领域里，已经有哪些玩家，上下游有哪些类型的公司？在遇到我们之前，用户是如何解决他们的问题的，我们的替换方案又是什么？

进而，我们的产品创造的价值点是什么？用户最关注的核心指标是什么？用户需求潜在的变化在哪些地方，哪些是变化点，哪些是稳定点？

这里有一个值得细细品味的概念：**稳定点与变化点**。

稳定点，是系统不变的核心能力。无论用户需求如何演进，有些东西是相对稳定的，它们构成了产品的基石。变化点，则是那些可能随着业务发展而调整的部分，需要我们在架构层面预留扩展的空间。

但这里有一个极其关键的前提：**讨论变化点和稳定点时，必须有明确的坐标系**。从不同视角出发，稳定点和变化点的判断可能完全不同。

以计算机为例：设计一台计算机，外部设备的多样性是变化点。但如果我们今天是在设计一台显示器，外部设备的多样性就不再是讨论的焦点，变化点和稳定点完全不一样了。所以，所谓变化点，本质上是一次产品边界的确立过程——我做什么，把什么交给合作伙伴，又通过什么接口与合作伙伴配合。

# 架构师不能袖手旁观

有一种观点认为：需求分析是产品经理的活，架构师只管实现。这种分工听起来合理，但细想之下却经不起推敲。

架构师的核心特色就是，工作内容范围不要设置边界

## 需求的深层理解，很难被完整传递

产品文档是产品经理与用户沟通后的二次加工，是需求的提炼与再包装。无论产品经理多么优秀，原汁原味的用户诉求在传递过程中总会发生损耗。就像一道菜经过层层转手，最后端上桌的味道，已经和厨师最初调制的有所不同。

架构师自己走近用户，去体会用户的述求，这一步不可省略。更重要的是，大部分人并不会仔仔细细阅读他人写的文档。如果团队文档的平均质量不高，阅读者的心态也会受影响——他们可能只扫一眼标题就跳过正文，这进一步加剧了信息传递的失真。

## 产品设计，需要架构师的深度参与

产品经理需要有技术高度。他不必深刻了解技术原理，但必须深刻理解新技术的边界——某项技术能够做什么，不能做什么，顶级产品经理甚至比实现这项技术的开发人员还要清楚。认为产品经理不需要理解技术，是一种普遍存在的误解，但未必符合这个岗位的内在诉求。

产品定义过程需要反复推敲琢磨，并最终成型。这个过程，单靠产品经理是不够的。架构师在技术实现侧的深度参与，能够补全产品经理可能缺乏的技术广度。两者在产品这座桥的两端相向而行，最终必然殊途同归。

**产品经理和架构师是一体两面**。两者都关心用户需求与产品定义，只是出发角度不同。

# 如何做好需求分析

方法论层面的总结，往往不如心态层面的提醒来得重要。

## 心态第一，心里装着用户

除了在心里对需求反复推敲的严谨态度之外，对用户反馈的尊重之心也至关重要。用户说出来的需求，往往是经过他们自己加工后的方案，而非原始诉求。多问几个"为什么"，多推敲几次，把它还原到不带任何技术实现假设的根源需求。

根源需求可能对应非常多的技术方案。用户反馈的每一个"点"，只是他们站在自身立场上给出的解法，而这些解法未必是最优解。架构师的任务，是回到根源，看清本质，然后从技术视角给出更优雅的解答。

但问题在于，有一类需求决策起来非常困难：不做，可能丢失这个客户；做，如果放宽标准，产品的需求就会被无限放大，最终做出一个四不像的东西。厘清这一类边界，需要团队坐下来反复拷问，不断明确响应需求的正确姿势。

## 对问题刨根究底，找到根源需求

根源需求的挖掘，是需求分析中最见功力的部分。用户反馈需求时，通常已经带着他自己熟悉的方案烙印。这种经过二次加工的需求，需要我们一层层剥开伪装，回到最原始的诉求。

一个常见的情形：用户说"需要支持批量导入"。表面上看，这是一个功能需求。但当我们追问"为什么需要批量导入"，答案可能是"每次手动录入太慢"。再追问"为什么慢"，可能发现是"数据量太大"。继续挖掘，根源可能是"现有系统响应速度太慢，操作一次需要等待三十秒"。

你看，从"批量导入"到"系统响应速度"，这是完全不同的两个问题域。找到了根源需求，我们才可能给出真正优雅的解决方案——也许不是做批量导入，而是优化系统的响应时间，让单条录入也足够快。

## 对需求进行归纳整理

在理清需求之后，需要对需求进行归纳整理。一方面，将需求归类到不同的子类别中，形成清晰的需求结构；另一方面，形成对变化点和稳定点的基本判断。

这里需要强调的是：**产品功能必须是收敛的，必须是可完成的**。如果某个子类别的需求呈现出发散而无法收敛的趋势，团队一定要停下来反复推敲。一边是用户不断提出的新需求，一边是产品边界不断被突破，这个矛盾如果不能及时化解，系统就会陷入无休止的泥沼。

# 产品定义：需求分析的终点

需求分析的目标和最终结果，是形成清晰的产品定义。

产品定义，并不等同于产品需求的归类。产品是桥，一端连接用户需求，一端连接先进技术，所以产品定义不可能做到和技术方案完全无关。

产品定义的要素，包括以下几个方面。

**定义产品中的元素，以及这些元素的各类操作方式。** 如果从技术视角来理解，这就是定义对象和方法。但产品视角下的对象和方法，与技术视角并不完全一一对应——一个技术上的方法，从产品需求角度可能会有多条路径的操作方式来达到相同的目的。

**确认产品如何满足用户需求。** 用户的使用场景未必全部是产品所能直接满足的，面向特定的行业，可能需要相应的行业解决方案，把产品整合进去。这里需要保持开放的心态，优先寻找合作伙伴来完成这类行业的需求覆盖，而不是试图把一切都纳入产品本身。

**考虑市场策略。** 产品如何进入市场，和既有市场格局中的其他主流解决方案的关系是什么？我们希望获取的用户，大部分已经有一个既有的产品在满足他们的需求。在考虑如何让客户从既有方案迁移到我们的产品时，产品边界的确定会复杂很多。在一些极其关键的市场，我们有可能会把迁移需求视作产品需求的一部分；但更多的情况下，产品只为市场上的主流方案提供迁移路径，而不是完整的迁移方案。

## 总结

需求分析，是架构设计的地基。地基不稳，上层建筑再华丽也会摇摇欲坠。

需求分析的核心要点如下：

1. 需求分析并非纯技术工作，它关乎用户需求的梳理、产品的清晰定义和演变方向的预判。
2. 架构师在需求分析上应至少投入三分之一的时间。
3. 产品经理和架构师是一体两面，两者从不同的方向出发，在产品这座桥的中间相遇。
4. 做好需求分析需要三个关键态度：心态第一心里装着用户、刨根究底找到根源需求、对需求进行归纳整理区分变化点与稳定点。
5. 稳定点是系统的核心能力，变化点需要对应地进行扩展性设计，但必须先明确系统边界——不同坐标系下，分类完全不同。
6. 需求分析的终点是产品定义，明确产品元素、产品边界，以及与上下游合作伙伴的分工。
7. 产品是桥，连接用户需求与先进技术，架构师对工作不设边界，深度参与产品设计，而非被动接受需求文档。
8. 防止过度设计是需求分析最重要的副产品，提前为不会发生的事做足准备，是一种隐性浪费。
9. 学习架构需要悟心，多花时间去思考，而不是把时间花在记忆和劳动力上。

## 参考资料

- 软件架构基础

架构30：架构思维：需求分析

# 前言

软件开发领域有一个流传已久的原则：DRY——Don't Repeat Yourself。翻译成更通俗易懂的话就是：不要重复造轮子。开源项目的诞生，本质上就是为了实现这个目标——让开发者们不要重复发明已经存在的轮子，尤其是在互联网这样分秒必争的战场，速度就是生命线。引入一个成熟的开源项目，可以节省大量的人力和时间，让业务得以快速奔跑。这是多么美好的事情！

然而，现实往往比理想骨感得多。开源项目固然为我们节省了时间和人力，但它带来的问题同样不少。几乎每一位技术人都踩过开源软件的坑——轻则导致系统宕机半小时，重则丢失几十万条数据，更灾难性的情况是全部数据付之东流。

更令人头疼的是，开源世界其实是最不遵守DRY原则的地方。相似的轮子遍地开花：你有MySQL，我有PostgreSQL；你有MongoDB，我有Cassandra；你有Memcached，我有Redis；你有Gson，我有Jackson……放眼望去，的选择实在太多，而如何选择就成了一门艺术。

答案在于：不要重复发明轮子，但要找到合适的轮子。但如果你的车是保时捷，可别给它装上拖拉机的轮子。

# 选：如何选择一个开源项目

## 聚焦是否满足业务

架构师在选择开源项目时，最大的头疼问题之一就是相似的开源项目太多，而且后面的总是宣称自己比前面的更优秀。有的架构师在选择时无所适从，总是担心选了A项目而错过了B项目。

解决这个困境的方式是：聚焦于是否满足业务，而不需要过于关注开源项目本身是否优秀。

以Tokyo Tyrant的教训为例。在开发一个社交类业务时，团队使用了TT（Tokyo Tyrant）开源项目，因为它既能做缓存取代Memcached，又有持久化存储功能，看起来非常强大，于是就在业务里大量使用。但后来的使用过程让人郁闷至极：TT并不能完全取代MySQL，因此存在两份存储，设计时每次都要讨论究竟什么数据放MySQL、什么数据放TT；功能上bug不少，有的甚至是致命的，例如所有数据不可读；功能虽强大，但需要花费较长时间熟悉各种细节，不熟悉而随便用很容易踩坑。

事后反思，业务其实Memcached加MySQL完全能够满足需求，而且大家都熟悉，根本不需要引入TT。

这个教训告诉我们：如果你的业务要求1000 TPS，那么一个20000 TPS和一个50000 TPS的开源项目是没有区别的。有的架构师可能会担心TPS不断上涨怎么办？其实不必过于担心，架构是可以不断演进的，等到真的需要那么高的时候再来进行架构重构。设计决策应当遵循架构设计原则中的“合适原则”和“演化原则”。

## 聚焦是否成熟

很多新的开源项目往往会声称自己比以前的项目更加优秀：性能更高、功能更强、引入更多新概念……看起来都很诱人。但它们都有意无意地隐藏了一个负面问题：更加不成熟。

不管多优秀的程序员写出来的项目都会有bug。千万不要以为Windows、Linux、MySQL的开发者不够顶级，这些系统一样存在很多bug。不成熟的开源项目应用到生产环境，风险极大：轻则宕机，重则宕机后重启都恢复不了，更严重的是数据丢失都找不回来。

以TT为例，团队真的遇到过异常断电后文件被损坏、重启也恢复不了的故障。虽然每天做了备份，用1天前的数据进行恢复，但当天的数据全部丢失了。后来花费大量时间和人力去看源码，自己写工具恢复了部分数据。幸好这些数据不是金融相关的，否则就有大麻烦了。

所以在选择开源项目时，**尽量选择成熟的开源项目，降低风险**。可以从这几个方面考察开源项目是否成熟：版本号方面，除非特殊情况，否则不要选0.X版本的，至少选1.X版本的，版本号越高越好；使用的公司数量方面，一般开源项目都会把采用了自己项目的公司列在主页上，公司越大越好、数量越多越好；社区活跃度方面，看看社区是否活跃，发帖数、回复数、问题处理速度等都是重要指标。

## 聚焦运维能力

大部分架构师在选择开源项目时，基本上都是聚焦于技术指标，例如性能、可用性、功能，而几乎不会去关注运维方面的能力。但如果要将项目应用到线上生产环境，**运维能力是必不可少的一环**，否则一旦出问题，运维、研发、测试都只能干瞪眼。

可以从这几个方面去考察运维能力：开源项目日志是否齐全，有的开源项目日志只有寥寥几行，出了问题根本无法排查；开源项目是否有命令行、管理控制台等维护工具，能够看到系统运行时的情况；开源项目是否有故障检测和恢复的能力，例如告警、切换等。

如果是开源库，例如Netty这种网络库，本身不具备运维能力，那么就需要在使用库的时候将一些关键信息通过日志记录下来。

# 用：如何使用开源项目

## 深入研究，仔细测试

很多人用开源项目，其实是完完全全的“拿来主义”：看了几个Demo，把程序跑起来就开始部署到线上应用了。这就好像看了一下开车指南，知道了方向盘是转向、油门是加速、刹车是减速，然后就开车上路了一样，其实是非常危险的。

Elasticsearch的案例：团队使用Elasticsearch，基本是拿来就用，倒排索引是什么都不太清楚，配置都是用默认值，跑起来就上线了。结果遇到节点ping时间太长、剔除异常节点太慢的问题，导致整站访问挂掉。

MySQL的案例：很多团队最初使用MySQL时也没有怎么研究过，经常有业务部门抱怨MySQL太慢了。但经过定位，发现最关键的几个参数（例如innodb_buffer_pool_size、sync_binlog、innodb_log_file_size等）都没有配置或者配置错误，性能当然会慢。

正确的研究测试方法包括：通读开源项目的设计文档或者白皮书，了解其设计原理；核对每个配置项的作用和影响，识别出关键配置项；进行多种场景的性能测试；进行压力测试，连续跑几天，观察CPU、内存、磁盘I/O等指标波动；进行故障测试，包括kill、断电、拔网线、重启100次以上、切换等。

## 小心应用，灰度发布

假如我们做了深入的研究和测试，发现没什么问题，是否就可以放心大胆地应用到线上了呢？即使研究再深入、测试再仔细，都要对线上环境和风险有敬畏之心，小心驶得万年船。

还是以TT为例，团队在应用之前专门安排一个高手看源码、做测试，做了大约1个月，但最后上线还是遇到各种问题。线上生产环境的复杂度，真的不是测试能够覆盖的。

经验就是先在非核心的业务上用，然后有经验后慢慢扩展。灰度发布策略可以极大地降低风险——先让一小部分用户使用新版本，观察是否出现问题，然后逐步扩大范围。

## 做好应急，以防万一

即使前面的工作做得非常完善和充分，也不能认为万事大吉。尤其是刚开始使用一个开源项目，运气不好可能遇到一个之前全世界的使用者从来没遇到的bug，导致业务都无法恢复。

MongoDB丢失数据的案例：某个业务使用了MongoDB，结果宕机后部分数据丢失，无法恢复，也没有其他备份，人工恢复都没办法，只能一个一个处理用户投诉，导致DBA和运维从此以后都反对使用MongoDB。

对于重要的业务或者数据，使用开源项目时，最好有另外一个比较成熟的方案做备份。例如，如果要用MongoDB或者Redis，可以用MySQL做备份存储。这样做虽然复杂度和成本高一些，但关键时刻能够救命。

# 改：如何基于开源项目做二次开发

## 保持纯洁，加以包装

当我们发现开源项目有的地方不满足需求时，自然会有一种去改改的冲动。但是怎么改是个大学问。

一种方式是投入几个人从内到外全部改一遍，将其改造成完全符合业务需求。但这样做有几个严重问题：投入太大，一般来说，Redis这种级别的开源项目，真要自己改，至少要投入2个人，搞1个月以上；改的太多，即使原有开源项目继续演进，也无法合并了，因为差异太大。

建议是不要改动原系统，而是开发辅助系统：监控、报警、负载均衡、管理等。以Redis为例，如果想增加集群功能，不要去改动Redis本身的实现，而是增加一个proxy层来实现。Twitter的Twemproxy就是这样做的，而Redis到了3.0后本身提供了集群功能，原有的方案简单切换到Redis 3.0即可。

如果实在想改到原有系统，建议直接给开源项目提需求或者bug。弊端就是响应比较缓慢，如果实在太急那就只能自己改了；如果不是太急，建议做好备份或者应急手段即可。

## 发明你要的轮子

这一点可能让你大跌眼镜，怎么讲了半天，最后又回到了“重复发明你要的轮子”呢？

其实选与不选开源项目，核心还是一个成本和收益的问题。并没有完全适合你的轮子！软件领域和硬件领域最大的不同就是软件领域没有绝对的工业标准。硬件领域你造一个尺寸与众不同的轮子，其他车都用不上；但软件领域可以造很多相似的轮子，基本上能到处用。

开源项目为了能够大规模应用，考虑的是通用的处理方案，而不同的业务其实差异较大，通用方案并不一定完美适合具体的某个业务。

例如Memcached通过一致性Hash提供集群功能，但某些业务的缓存如果有一台宕机，整个业务可能就被拖慢了，这就要求提供缓存备份的功能。但Memcached又没有，而Redis当时又没有集群功能。于是团队投入2-4个人花了大约2个月时间，基于LevelDB的原理，自己做了一套缓存框架支持存储、备份、集群的功能，后来又在这个框架的基础上增加了跨机房同步的功能，很大程度上提升了业务的可用性水平。

所以，如果有钱有人有时间，投入人力去重复发明完美符合自己业务特点的轮子也是很好的选择！

这个角度和我们先去使用开源并不冲突，为了架构设计最激极尽志方案，我们需要从开源项目上衍生最合适我们项目和产品的代码仓库

## 总结

- 开源项目的选择应聚焦于是否满足业务需求，而非追求技术上的“最新最强”
- 成熟度是选择开源项目的关键指标，0.X版本风险较高，应优先选择1.0以上版本
- 运维能力是不可忽视的考察点，日志、管理工具、故障恢复能力缺一不可
- 使用开源项目前必须进行深入研究，包括设计原理、关键配置项和各种场景测试
- 即使研究测试再充分，上线时仍需保持敬畏之心，采用灰度发布策略
- 重要业务的数据存储必须有备份方案，以防开源项目出现灾难性问题
- 二次开发时应优先采用包装层而非修改原系统，保持跟随原项目演进的能力
- 当通用开源项目无法满足业务特殊需求时，投入资源自研可能是更好的选择
- 选择开源项目与架构设计一样，需要遵循“合适原则”和“演化原则”

## 参考资料

- 软件架构基础

架构29：架构思维：Don't Repeat 

# 前言

古人兵法有云：“谋定而后动，知止而有得。”这句话道出了一个深刻的道理——真正的智者，从不贸然出击，而是在行动之前，已经将全局了然于胸，将每一步棋都提前布局妥当。架构重构亦如是。

在之前的文章中，我们探讨了“有的放矢”与“穿针引线”两个思维办法，学会了从纷繁复杂的问题中识别关键的复杂度问题，并有的放矢地通过架构重构来解决。然而，当真正站在重构的门槛上时，你或许会发现一个尴尬的事实：即使你清楚地知道问题所在，却依然无法落地。因为很多条件尚不具备，因为有的问题没解决之前就无法动手术。

这正是第三式心法“谋定后动”的真谛——分段实施的策略艺术。

# 核心复杂度分析与策略制定

当我们对系统进行深入分析和思考后，可能从最初的100个问题中筛选出50个需要在架构重构中解决的。其中一些是基础能力建设或准备工作，另一些才是架构重构的核心工作。面对这50个问题，很多人会陷入一个误区：每次挑一个解决，期望最终把所有问题都解决。这种做法操作简单，但效果却很差。

为什么分段实施比“一锅端”更有效？原因有三。

第一，不区分优先级会导致资源分散。所有问题一视同仁，没有集中有限资源去解决最重要或最关键的问题，做了大半年回头一看，好像做了很多事情，却没取得什么阶段性的成果。团队会逐渐失去信心，相关人员对项目的评价也会降低。

第二，不将问题分类会导致效率低下。相似问题没有统筹考虑，方案可能出现反复，徒增工作量。

第三，业务版本的压力会驱使团队专门挑容易的实施。到了稍微难一点的问题，就因为复杂度高、投入大而被搁置，最终达不到重构的真正目的。

以X系统为例。在架构师加入之前，其实也已经整理了系统存在的问题，涵盖可用性、性能、安全、用户体验等多个大项，每个大项又包含十几二十个子项。然而实施时基本是“挑软柿子捏”，觉得哪个好落地、占用资源不太多就做哪个。结果半年过去了，做了很多功能，整体却没什么进展。

后来成立了一个专门的项目组，在原有问题清单的基础上，识别出架构的核心复杂度体现在庞大的系统集成了太多功能、可扩展性不足。但同时，系统的可用性也不高，经常出线上问题，耗费大量人力处理。经过分析发现，如果要做架构重构，系统需要处于一个比较稳定的状态，不能经常出线上问题。而当时可用性不高的原因多种多样：有的是硬件资源不够，有的是系统组件使用不合理，有的是架构本身存在问题。

基于这些分析，制定了总体策略：真正的架构重构在第三阶段，前两个阶段都是为第三阶段做准备。如果没有前两个阶段的铺垫就直接开始第三阶段，架构重构方案需要糅合很多前期事项，会导致方案不聚焦，而且异常复杂。

# 分段实施的四大原则

## 优先级排序

将明显且比较紧急的事项优先落地，解决目前遇到的主要问题。例如，扩容在多个系统中都是最优先实施的。因为如果不扩容，系统隔三差五就会出现响应超时报警，一会儿是过载报警，一会儿是大面积不可用……这些问题耗费大量的人力和精力，团队根本没空做其他事情。

## 问题分类

将问题按照性质分类，每个阶段集中解决一类问题。例如，第二阶段可以将多个底层系统切换到公司统一的公共组件，提升整体可用性。分类的目的在于聚合相似问题，统一制定方案，统一实施，避免方案反复。

## 先易后难

这点与很多人的直觉不太一样。有的人认为应该先攻克最难的问题，所谓“擒贼先擒王”，解决最难的问题后其他问题就不在话下。这样看起来很美好，但实际上不可行。

首先，一开始就做最难的部分，会发现想要解决这个最难的问题，要先解决其他容易的问题。其次，最难的问题解决起来耗时都比较长，占用资源比较多，如果一开始做最难的，可能做了一两个月还没有什么进展和成果，会影响相关人员对项目的评价和团队士气。第三，刚开始的分析并不一定全面，所以一开始对最难的或者最关键的事项的判断可能会出错。

采取“先易后难”的策略，能够很大程度上避免这些问题。随着项目推进，一些相对简单的问题逐渐解决，会发现原来看起来很难的问题已经不那么难了，甚至有的问题可能都消失了。先易后难能够比较快地看到成果，虽然成果可能不大，但至少能看到一些成效，对后续的项目推进和提升团队士气有很大好处。随着项目的进行，原来遗漏的点，或者分析和判断错误的点，会逐渐显示出来，及时根据实际情况进行调整，能够有效地保证整个重构的效果。

## 循序渐进

按照前三个步骤划分了架构重构的实施阶段后，就需要评估每个阶段所需要耗费的时间。很可能会出现有的阶段耗时只需1个月，而有的却需要6个月。虽然这可能确实是客观事实，但通常情况下，按照固定的步骤和节奏更有利于项目推进。经验是每个阶段最少1个月，最长不要超过3个月。如果评估超过3个月的，那就再拆分为更多阶段。

每个阶段又可以细分为任务子集。当任务子集比较小的时候，多个任务子集可以并行；当任务子集比较大的时候，就当成一个独立的里程碑推进。

# 分段实施的价值

分段实施将问题根据优先级、重要性、实施难度等划分为不同的阶段，每个阶段聚焦于一个整体的目标，集中精力和资源解决一类问题。这种做法有几个显著好处。

每个阶段都有明确目标，做完之后效果明显，团队信心足，后续推进更加容易。每个阶段的工作量不会太大，可以和业务并行开发。每个阶段的改动不会太大，降低了总体风险。

回到X项目的例子，采用三阶段策略后，第一阶段的“救火”完成后，系统很少再有因为机器过载、缓存响应慢、虚拟机挂死等问题导致的故障了。完成第二阶段的事项后，因为组件、外部系统故障导致系统故障的问题也很少了。完成前两个阶段后，团队终于可以安心地做第三阶段的“服务化”工作了。

S系统的重构做法也类似，但S系统当时面临的主要问题是可用性不高，并没有系统耦合的问题。所以策略是“先救火、后优化、再重构”：“救火”阶段做了扩容和Nginx一键切换功能；“优化”阶段将一些明显的可用性问题解决；“重构”阶段将原来的单点数据库改为多中心。

## 总结

- 架构重构不能“一锅端”，必须采用分段实施的策略，将大问题分解为可管理的小阶段
- 优先处理紧急且重要的事项，解决主要矛盾后才能为后续工作创造条件
- 将问题按性质分类，相似问题统一处理可以显著提高效率，避免方案反复
- 采用“先易后难”的策略能够在早期就看到成果，有效提升团队士气和信心
- 每个阶段建议控制在1-3个月内，过长的阶段应进一步拆分
- 阶段目标必须明确可见，让团队看到阶段性成果才能保持动力
- 每个阶段结束时应该进行复盘，根据实际情况调整后续阶段的计划
- 分段实施的核心价值在于降低风险、提高效率、保持团队信心

## 参考资料

- 软件架构基础