技术演进中的开发沉思-106 Linux服务编程系列：高性能服务器程序框架（上）
从桌面开发到支撑千万级用户的微服务，我始终觉得：高性能服务器的设计，和高效工厂的搭建逻辑如出一辙 —— 要先确定 “和客户怎么协作”（服务器模型），再规划 “整体工作流程”（编程框架），接着选 “最快的物料处理方式”（I/O 模型），最后定 “生产线怎么调度”（事件处理模式）。今天，我们梳理的内容，拆成 “工厂设计” 的四个核心环节，用 “技术细节 + 生活场景 + 实践案例”，把高性能框架讲透。
一、服务器模型
任何服务器启动前，都要先确定 “和客户端怎么交互”—— 就像工厂要先定 “是客户上门提货，还是工厂送货上门”，不同的协作模式，决定了后续的资源分配。
1.1 C/S 模型：“客户 - 门店” 式协作
C/S（Client/Server，客户端 / 服务器）模型是最经典的 “客户上门” 模式，就像我们去奶茶店买奶茶：客户（手机 App、浏览器）是 “上门的顾客”，服务器（后端服务）是 “奶茶店”—— 顾客先下单（发送请求），奶茶店接单制作（处理请求），最后把奶茶递给顾客（返回响应）。
核心特点（技术细节）
- 角色固定：客户端只发请求、收响应（顾客只点单、拿奶茶），服务器只处理请求、返回结果（奶茶店只做奶茶、不主动找顾客）。
- 通信主动 - 被动：客户端主动发起连接（顾客主动进店），服务器被动监听端口（奶茶店开门等顾客）。
- 资源集中：业务逻辑、数据都存在服务器（奶茶配方、原料都在店里），客户端轻量（顾客不用带原料）。
实际场景（我的经历）
早年做 Web 1.0 时代的新闻网站时，用的就是 C/S 模型：用户用浏览器（客户端）输入网址，浏览器向服务器发起 HTTP 请求（下单），服务器从数据库查新闻数据、生成 HTML 页面（做奶茶），再把页面返回给浏览器（递奶茶）。后来做移动互联网 App，客户端换成了手机 App，但逻辑没变 ——App 发 API 请求，服务器处理后返回 JSON 数据，就像 “奶茶店改成外卖，顾客用手机下单，店里做好送上门”，本质还是 C/S 协作。
优缺点（工厂视角）
- 优点：服务器好管理（奶茶店只需要管好店里的事），数据安全（原料和配方不外露），适合需要统一管控的场景（比如电商订单、银行转账）。
- 缺点：服务器压力大（奶茶店人多会排队），客户端没法直接交互（顾客之间不能互相借奶茶）。
1.2 P2P 模型：“邻里互助” 式协作
P2P（Peer-to-Peer，对等网络）模型是 “没有固定门店” 的协作模式，就像小区里的 “邻里互助”：你有一袋米，我有一瓶油，我们直接互相交换（客户端之间直接通信），不用经过超市（服务器）。
核心特点（技术细节）
- 角色平等：每个节点（Peer）既是客户端也是服务器（邻居既可以要东西，也可以给东西）—— 比如 A 节点可以向 B 节点要文件，B 节点也可以向 A 节点要文件。
- 通信双向：节点之间可以直接发起连接（邻居之间可以直接敲门），不用依赖中心服务器（不用经过超市）。
- 资源分散：数据、计算资源分布在各个节点（米、油在邻居家里），不是集中在某台服务器（不在超市）。
实际场景（我的经历）
2000 年初做文件共享工具时，用过 P2P 模型：用户 A 要下载一部电影，不用从中心服务器下载，而是直接从其他已经下载了这部电影的用户 B、C、D 的电脑上 “分片下载”——A 从 B 那拿 1-10 分钟的片段，从 C 那拿 11-20 分钟的片段，最后拼起来，就像 “邻居 A 要做米饭，从邻居 B 那借米，从邻居 C 那借锅，不用去超市”。后来做实时视频会议，也用了 P2P 的思路：两个用户之间直接传输视频流，不用经过服务器转发，延迟比 C/S 模型低很多，就像 “邻居之间直接说话，不用通过居委会转达”。
优缺点（工厂视角）
- 优点：减轻中心服务器压力（不用建大超市），节点越多速度越快（邻居越多，能借的东西越多），适合大文件传输、实时交互（比如视频会议、区块链）。
- 缺点：节点管理难（邻居太多不好联系），安全性差（可能遇到给 “坏东西” 的邻居），适合对管控要求不高的场景。
二、服务器编程框架
确定了 “协作模式” 后，就要规划 “服务器怎么一步步处理请求”—— 就像工厂确定了 “客户上门” 后，要规划 “顾客进店→点单→制作→取货” 的流程，这个流程就是 “编程框架”。
核心流程（技术细节，通用框架）
不管是 C/S 还是 P2P 模型，服务器编程框架都离不开这 5 步，就像工厂的 “标准作业流程（SOP）”：
1.初始化（开店准备）：
- 创建 socket（准备接待顾客的柜台）。
- 绑定端口（给柜台编个号，方便顾客找到）。
- 设置 socket 选项（比如 SO_REUSEADDR，柜台可以快速复用）。
- 监听端口（柜台开门，开始等顾客）。
- 接收连接（迎接顾客）：
- 调用 accept () 函数（服务员上前接待顾客），获取与客户端的连接 socket（顾客的专属订单）。
- （高并发场景）会用线程池、进程池提前准备 “服务员”，避免顾客等太久。
2.处理请求（制作商品）：
- 读取客户端发送的数据（拿到顾客的订单内容）。
- 解析请求（看懂订单：比如要一杯珍珠奶茶，少糖少冰）。
- 执行业务逻辑（按订单做奶茶：煮珍珠、泡茶叶、加奶）。
- 复杂场景会调用数据库、缓存（去仓库拿原料），或者调用其他服务（让其他车间帮忙）。
3.返回响应（交付商品）：
- 把处理结果封装成响应格式（把奶茶装杯、贴标签）。
- 调用 write () 函数把响应发给客户端（把奶茶递给顾客）。
4.释放资源（清理现场）：
- 关闭连接 socket（顾客离开，清理柜台）。
- （如果用了线程池）把线程放回池里（服务员回到待命状态）。
实际代码示例（简化框架）
早年写一个简单的 TCP 服务器时，用的就是这个框架，代码片段如下：
#include
#include
#include
#include
#include
#include
#define PORT 8080
#define BUF_SIZE 1024
// 步骤3：处理请求（模拟做奶茶）
void handle_request(int client_fd) {
char buf[BUF_SIZE] = {0};
// 读请求（拿订单）
ssize_t n = read(client_fd, buf, BUF_SIZE);
if (n < 0) {
perror("read failed");
return;
}
printf("Received request: %s
", buf); // 比如收到"order: milk tea"
// 执行业务逻辑（做奶茶）
char response[BUF_SIZE] = "Response: milk tea ready (less sugar, less ice)";
// 写响应（递奶茶）
write(client_fd, response, strlen(response));
}
int main() {
int listen_fd, client_fd;
struct sockaddr_in server_addr, client_addr;
socklen_t client_len = sizeof(client_addr);
// 步骤1：初始化（开店准备）
// 1.1 创建socket（柜台）
if ((listen_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
perror("socket failed");
exit(EXIT_FAILURE);
}
// 1.2 设置SO_REUSEADDR（快速复用柜台）
int opt = 1;
if (setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)) < 0) {
perror("setsockopt failed");
exit(EXIT_FAILURE);
}
// 1.3 绑定端口（柜台编号）
server_addr.sin_family = AF_INET;
server_addr.sin_addr.s_addr = INADDR_ANY; // 监听所有网卡
server_addr.sin_port = htons(PORT); // 端口8080
if (bind(listen_fd, (struct sockaddr*)&server_addr, sizeof(server_addr)) < 0) {
perror("bind failed");
exit(EXIT_FAILURE);
}
// 1.4 监听端口（开门等顾客）
if (listen(listen_fd, 5) < 0) { // 等待队列长度5
perror("listen failed");
exit(EXIT_FAILURE);
}
printf("Server listening on port %d...
", PORT);
// 步骤2-5：循环接收连接、处理请求（持续接待顾客）
while (1) {
// 步骤2：接收连接（接待顾客）
if ((client_fd = accept(listen_fd, (struct sockaddr*)&client_addr, &client_len)) < 0) {
perror("accept failed");
continue;
}
printf("New client connected
");
// 步骤3：处理请求（做奶茶）
handle_request(client_fd);
// 步骤5：释放资源（清理柜台）
close(client_fd);
printf("Client disconnected
");
}
close(listen_fd);
return 0;
}
框架的核心价值（工厂视角）
这个框架就像工厂的 SOP，不管是做奶茶还是做汽车，都要按 “准备→接待→制作→交付→清理” 的步骤来 —— 服务器编程也一样，不管是 Web 服务器、数据库服务器还是游戏服务器，核心流程都离不开这 5 步。不同的是，高性能服务器会在 “处理请求” 环节做优化（比如用线程池、I/O 多路复用），就像工厂会用流水线代替手工制作，提高效率。
三、I/O 模型
服务器处理请求的核心是 “读写数据”（I/O 操作），就像工厂处理 “原料和成品”—— 怎么高效地 “拿原料（读数据）”“送成品（写数据）”，决定了服务器的性能上限。Linux 下有 5 种 I/O 模型，我按 “工厂物料处理效率” 从低到高排序，结合我的经历慢慢说。
1. 阻塞 I/O（Blocking I/O）
这是最基础的 I/O 模型，就像工厂里的服务员：去仓库拿原料（读数据）时，站在仓库门口一直等，直到拿到原料才回来；送成品到物流站（写数据）时，也站在物流站门口等，直到确认送达才离开 —— 在等待期间，服务员什么都做不了。
技术细节
- 调用 read ()/write () 函数后，进程会 “阻塞”（暂停运行），直到数据准备好（原料到了）或数据写完（成品送完），才继续执行。
- 比如用阻塞 I/O 写的服务器，accept () 后调用 read ()，如果客户端没发数据，服务器进程就会卡在 read () 那里，没法处理其他客户端的请求 —— 就像服务员去拿原料，一直没回来，其他顾客只能排队等。
我的经历（踩过的坑）
早年做第一个 TCP 服务器时，用的就是阻塞 I/O：一个客户端连接后，如果一直不发数据，服务器进程就会卡在 read ()，其他客户端根本连不上。后来才知道，这种模型只适合 “单客户端、低并发” 的场景（比如调试工具），像生产环境的 Web 服务器，根本没法用 —— 就像一家奶茶店只有一个服务员，他去拿原料时，其他顾客只能站在门口等，效率太低。
2. 非阻塞 I/O（Non-Blocking I/O）
为了解决阻塞 I/O 的问题，非阻塞 I/O 应运而生 —— 就像服务员去仓库拿原料，仓库没原料时，服务员不一直等，而是先回来做其他事（比如整理柜台），过一会儿再去仓库查（轮询），直到拿到原料。
技术细节
- 给 socket 设置 O_NONBLOCK 选项后，read ()/write () 函数会 “非阻塞”：如果数据没准备好（仓库没原料），函数会立刻返回 - 1，同时设置 errno=EAGAIN（“暂时没原料，再试试”）；如果数据准备好了，就正常读写。
- 服务器需要用 “循环轮询” 的方式，不断调用 read () 检查每个 socket 有没有数据 —— 就像服务员每隔 1 分钟去仓库查一次，直到拿到原料。
我的经历（优化尝试）
后来我把阻塞 I/O 改成非阻塞 I/O，用一个循环遍历所有连接的 socket，逐个调用 read ()：有数据就处理，没数据就跳过。但问题来了，当连接数多到 1000 时，循环一次要花很多时间，大部分 socket 都是 “没数据” 的，这就是 “轮询开销”—— 就像服务员要去 100 个仓库查原料，99 个仓库都没原料，白跑一趟，浪费时间。
3. I/O 多路复用（I/O Multiplexing）
这是高性能服务器最常用的 I/O 模型，就像工厂里加了个 “仓库管理员”：服务员不用自己去查原料，而是告诉管理员 “我要 A 原料”，然后去做其他事；等 A 原料到了，管理员再通知服务员去拿 —— 这样服务员不用白跑，效率大大提高。
技术细节
- 核心是用 select ()/poll ()/epoll () 函数（仓库管理员），同时监听多个 socket（多个仓库）：
- 告诉管理员 “我要监听这些 socket 的读事件（原料到了）或写事件（物流站能接收成品）”。
- 管理员会 “阻塞” 等待，直到至少一个 socket 的事件就绪（至少一个仓库有原料），才通知进程。
- 进程再去处理就绪的 socket（服务员去拿原料），没就绪的 socket 不用管。
我的经历（性能飞跃）
做高并发 Web 服务器时，我把非阻塞 I/O 换成了 epoll（Linux 下性能最好的 I/O 多路复用技术）：用 epoll_create () 创建 “管理员”，epoll_ctl () 注册要监听的 socket 和事件，epoll_wait () 等待事件就绪。当有 10000 个客户端连接时，epoll_wait () 只会返回 “有数据的 socket”（比如 10 个），进程只需要处理这 10 个 socket—— 就像管理员只通知 “有原料的仓库”，服务员不用跑 10000 个仓库，效率比非阻塞 I/O 高 100 倍。
为什么是高性能的核心？
I/O 多路复用解决了 “轮询开销” 的问题，让服务器能高效处理 “多连接、少活跃” 的场景（比如 Web 服务器，大部分客户端连接都是空闲的，只有少数在发请求）—— 就像奶茶店高峰期有 100 个顾客，但只有 10 个在点单，服务员只需要处理这 10 个顾客，其他 90 个可以先等，不用逐个问 “你要点单吗”。
4. 信号驱动 I/O（Signal-Driven I/O）
这种模型就像工厂的仓库装了 “警报器”：服务员告诉仓库 “有 A 原料到了就响警报”，然后去做其他事；等 A 原料到了，仓库响警报（发送 SIGIO 信号），服务员听到警报后，去拿原料。
技术细节
- 给 socket 设置 O_ASYNC 选项，注册 SIGIO 信号的处理函数（警报器和服务员的联系方式）。
- 调用 read () 后，进程不阻塞，继续做其他事；当数据准备好时，内核会给进程发 SIGIO 信号，进程在信号处理函数里调用 read () 读数据。
局限性（我的看法）
这种模型我只用过一次：做实时数据采集工具时，发现信号处理函数里不好处理复杂逻辑（比如解析数据、调用数据库），而且多个 socket 同时触发信号时，容易出现 “信号丢失”（警报器响太多次，服务员听不清）。所以它只适合 “单 socket、高实时” 的场景（比如串口通信），不适合高并发服务器 —— 就像工厂只有一个警报器，多个仓库同时响，服务员不知道该先去哪个仓库。
5. 异步 I/O（Asynchronous I/O）
这是最高效的 I/O 模型，就像工厂把 “拿原料、送成品” 的活外包给了第三方公司：工厂只需要告诉外包公司 “我要 A 原料，做好后送到车间；成品 B 要送到物流站，送完告诉我”，然后就去做自己的事；等外包公司把原料拿到车间、把成品送完，再通知工厂 —— 工厂全程不用参与 “拿原料和送成品” 的过程。
技术细节
- 调用 aio_read ()/aio_write () 函数（找外包公司），告诉内核 “要读 / 写哪个 socket、数据存在哪、写完后怎么通知我（比如发信号或回调函数）”。
- 函数调用后立刻返回，进程继续做其他事（工厂做自己的活）；内核会在后台完成 “等待数据准备→读数据→把数据放到用户缓冲区”（外包公司拿原料并送到车间）的全过程，完成后再通知进程。
我的经历（未来趋势）
最近做微服务网关时，尝试用了 Linux 的异步 I/O（io_uring，比传统 aio 更高效）：用 io_uring_submit () 提交 I/O 请求，io_uring_wait_cqe () 等待请求完成。发现它的性能比 epoll 还高 —— 因为 epoll 需要进程自己处理 “读数据”（服务员去拿原料），而异步 I/O 连 “读数据” 都交给内核（外包公司拿原料并送到车间），进程只需要处理业务逻辑（工厂只做产品）。不过目前异步 I/O 的生态还不够完善（比如很多库不支持），但未来肯定是高性能服务器的主流。
5 种 I/O 模型的核心区别（工厂总结）
|
I/O 模型 |
等待阶段（拿原料） |
处理阶段（用原料） |
效率 |
适用场景 |
|
阻塞 I/O |
进程阻塞 |
进程处理 |
低 |
单客户端、低并发 |
|
非阻塞 I/O |
进程轮询 |
进程处理 |
中 |
低并发、短连接 |
|
I/O 多路复用 |
内核阻塞（管理员等） |
进程处理 |
高 |
高并发、多连接（主流） |
|
信号驱动 I/O |
进程做其他事 |
信号处理函数处理 |
中 |
单 socket、高实时 |
|
异步 I/O |
内核处理（外包） |
进程处理 |
最高 |
超高性能、高并发（未来） |
四、两种高效的事件处理模式
有了 I/O 模型（物料处理方式），还要有 “怎么调度线程 / 进程处理事件” 的方案 —— 就像工厂有了高效的物料处理方式，还要有 “怎么安排工人和生产线” 的调度方案，这就是事件处理模式。高性能服务器常用的是 Reactor 和 Proactor 模式。
4.1 Reactor 模式：“生产线主任调度工人”
Reactor 模式是 “基于事件通知” 的调度方案，就像工厂里的 “生产线主任”：
- 主任（Reactor）负责 “监听事件”（比如原料到了、成品要送），一旦有事件发生，就通知对应的工人（线程 / 进程）。
- 工人（Handler）负责 “处理事件”（比如用原料生产、送成品），处理完后回到待命状态，等主任下次通知。
技术细节（核心组件）
Reactor 模式有三个核心组件，就像工厂的 “主任、工人、事件列表”：
- Reactor（反应器）：核心组件，负责监听 I/O 事件（用 I/O 多路复用技术，比如 epoll），相当于 “生产线主任”。
- Handler（处理器）：负责处理事件，每个 Handler 对应一个业务逻辑（比如 HTTP 请求处理、TCP 连接处理），相当于 “工人”。
- Event（事件）：比如 “socket 可读事件”（原料到了）、“socket 可写事件”（成品要送）、“定时器事件”（到点做清洁），相当于 “要处理的任务”。
工作流程（工厂场景）
- 初始化：Reactor 注册事件和对应的 Handler（主任记下 “原料到了找工人 A，成品要送找工人 B”）。
- 等待事件：Reactor 调用 I/O 多路复用函数（比如 epoll_wait），等待事件发生（主任等仓库通知原料到了）。
- 分发事件：当事件发生（原料到了），Reactor 找到对应的 Handler（工人 A），通知它处理事件。
- 处理事件：Handler 处理事件（工人 A 用原料生产产品），处理完后，回到待命状态，等待下一次通知。
我的经历（Web 服务器实践）
做 Nginx 风格的 Web 服务器时，用的就是 Reactor 模式：
- Reactor 用 epoll 监听 80 端口的 “连接事件” 和已连接 socket 的 “读事件”。
- 当有新客户端连接（连接事件），Reactor 通知 “连接 Handler”：调用 accept () 获取新 socket，再把新 socket 的 “读事件” 注册到 Reactor。
- 当客户端发 HTTP 请求（读事件），Reactor 通知 “HTTP Handler”：读请求数据、解析请求、查数据库、生成响应，最后把 “写事件” 注册到 Reactor。
- 当 socket 可写（写事件），Reactor 通知 “写 Handler”：把响应写给客户端，关闭连接。
这种模式的核心是 “事件驱动”—— 工人不用主动找活干，主任通知什么就做什么，效率很高，适合 “I/O 密集型” 场景（比如 Web 服务器、API 网关）。
4.2 Proactor 模式：“外包公司处理物料，工人只做生产”
Proactor 模式是 “基于异步 I/O” 的调度方案，就像工厂把 “拿原料、送成品” 外包给第三方公司，工人只负责 “用原料生产”：
- 外包公司（内核）负责 “处理 I/O 操作”（拿原料、送成品），完成后通知工厂（进程）。
- 工人（Handler）负责 “处理业务逻辑”（用原料生产），不用管 I/O 操作。
技术细节（核心组件）
和 Reactor 模式类似，但分工不同：
- Proactor（前反应器）：负责发起异步 I/O 请求（告诉外包公司 “要拿 A 原料、送 B 成品”），相当于 “工厂对接外包的负责人”。
- Completion Handler（完成处理器）：负责在异步 I/O 完成后，处理业务逻辑（用原料生产），相当于 “工人”。
- Asynchronous Operation（异步操作）：比如 aio_read ()/aio_write ()，由内核（外包公司）在后台完成。
工作流程（工厂场景）
- 发起异步请求：Proactor 调用异步 I/O 函数（比如 aio_read），告诉内核 “读 socket A 的数据，放到缓冲区 B，完成后通知我”（负责人告诉外包公司 “拿 A 原料，放到车间 B”）。
- 进程做其他事：Proactor 函数返回后，进程可以处理其他任务（工厂继续做其他生产）。
- 异步 I/O 完成：内核完成 “等待数据→读数据→放缓冲区” 的全过程（外包公司拿到 A 原料，放到车间 B），然后通知进程（外包公司打电话给负责人）。
- 处理业务逻辑：Proactor 找到对应的 Completion Handler（工人），Handler 用缓冲区里的数据处理业务（工人用车间 B 的 A 原料生产产品）。
我的经历（微服务网关）
最近用 io_uring（Linux 异步 I/O）做微服务网关时，用的就是 Proactor 模式：
- Proactor 调用 io_uring_submit () 发起异步读请求：“读客户端 socket 的数据，放到缓冲区”。
- 进程继续处理其他客户端的请求（不用等数据读完）。
- 当异步读完成，io_uring_wait_cqe () 返回完成事件，Proactor 通知 Completion Handler：
- Handler 解析请求（比如路由到哪个微服务）。
- 再发起异步写请求：“把微服务的响应写给客户端”。
- 异步写完成后，Handler 关闭连接。
这种模式的核心是 “I/O 操作异步化”—— 工人不用管 “物料怎么来、怎么送”，只专注于 “生产”，适合 “超高性能、I/O 密集型” 场景（比如高频交易系统、大型微服务网关）。
4.3 模拟 Proactor 模式：“用 Reactor 模拟外包公司”
因为早期 Linux 的异步 I/O（aio）性能不好，很多服务器会用 “Reactor + 非阻塞 I/O” 模拟 Proactor 模式 —— 就像工厂没有真正的外包公司，让生产线主任（Reactor）兼做 “外包的活”：
- Reactor 监听 “socket 可读事件”（主任等原料到）。
- 事件发生后，Reactor 调用非阻塞 read () 读数据（主任亲自去拿原料，放到车间）。
- 然后通知 Completion Handler（工人）：“原料已经放到车间了，你直接生产”（相当于 “模拟” 外包公司完成了拿原料的活）。
技术细节（模拟流程）
以 “模拟异步读” 为例：
- Reactor 注册 socket 的 “读事件”（主任等原料到）。
- 当 socket 可读，Reactor 调用非阻塞 read ()，把数据读到缓冲区（主任拿原料，放车间）。
- Reactor 把 “数据已就绪” 的事件，分发给 Completion Handler（工人）。
- Handler 用缓冲区的数据处理业务（工人用原料生产）。
我的经历（Nginx 的做法）
Nginx 虽然用的是 Reactor 模式，但在处理 I/O 时，会用非阻塞 I/O 把 “读数据” 的操作做完，再交给 Handler 处理业务逻辑 —— 这其实就是 “模拟 Proactor”：
- Reactor（epoll）监听读事件。
- 事件发生后，Reactor 调用非阻塞 read () 把所有数据读到缓冲区（相当于 “完成了异步读”）。
- 再把缓冲区交给 Handler 解析 HTTP 请求（处理业务逻辑）。
这种模式的好处是 “兼容性好”—— 不用依赖性能不好的早期 aio，又能享受 “Handler 不用管 I/O” 的便利，是很多高性能服务器的折中方案。
五、最后小结
回头看这一章的内容，高性能服务器框架的设计，其实就是 “工厂设计哲学” 的技术实现：
- 服务器模型：确定 “和客户怎么协作”（C/S 适合统一管控，P2P 适合分散资源）。
- 编程框架：规划 “整体工作流程”（准备→接待→制作→交付→清理），是服务器的 “骨架”。
- I/O 模型：选择 “高效的物料处理方式”（I/O 多路复用是当前主流，异步 I/O 是未来），是服务器的 “肌肉”。
- 事件处理模式：制定 “生产线调度方案”（Reactor 适合大部分场景，Proactor 适合超高性能），是服务器的 “大脑”。
我做技术这么多年，从阻塞 I/O 的小工具到 io_uring 的微服务网关，最大的感悟是：高性能不是 “用最复杂的技术”，而是 “选对适合场景的模型和模式”—— 就像工厂不会用流水线做定制家具，也不会用手工做批量奶茶，服务器也一样：
- 做个人工具，用阻塞 I/O + 简单框架就够了。
- 做 Web 服务器，用 I/O 多路复用（epoll）+Reactor 模式是最佳选择。
- 做高频交易系统，才需要用异步 I/O（io_uring）+Proactor 模式。
希望这些 “工厂类比” 和我的经历，能让你既懂 “高性能框架是什么”，又懂 “该怎么选、怎么用”—— 这才是技术散文该有的 “深度”：不止于讲知识，更在于讲透知识背后的逻辑和实践。未完待续.......
