一点废话：
这几个月断断续续在工作之余学完了 Linux，但感觉学完就忘。
平时工作里全是业务逻辑，几乎碰不到底层原理。
老话说“基础不牢，地动山摇”，所以我打算跟着课程自己敲一遍服务端代码，把之前学的东西都用起来，顺便加深一下印象。
一、简介
本篇作为系列的开篇，主要讲解 服务端的基本框架设计 —— 理清整体架构和模块职责，为后续模块实现打下基础。
二、基本框架
根据牛客上的老师所说，服务器虽然种类繁多，但是其基本框架大多一致，下面的图就可以概括：
简单理解：
· IO处理单元 负责于客户端建立建立连接，接收客户端发送的消息。
· 请求队列 作为IO请求的缓存区，让请求任务排队。
· 逻辑单元 解析并处理客户端IO请求。（处理完可以直接发回给客户端，也可以在IO处理单元发回去）
· 请求队列，和存储打交道，让数据存取的需求排队
· 网络存储单元， 负责数据的存取和持久化。 它可以使用内存数据库（如 Redis）提供快速缓存，也可以使用外存关系型数据库（如 MySQL、Oracle）进行持久化存储，或者使用文件系统存储静态数据和日志。
模块说明
1. IO处理单元（网络事件层）
IO 层就是服务端的“前台接待”，负责和客户端打交道。
它主要做两件事：
- 监听客户端连接，并接收请求；
- 发送处理好的响应回客户端。
这部分一般用poll/epoll模型实现
2. 请求队列模块
请求队列就像一个中转站。
当 IO 层收到请求后，并不会立刻处理，而是把任务丢到队列里。
逻辑线程池再从队列里取出任务，执行具体业务逻辑。
这样做有几个好处：
- IO 层和逻辑层解耦，互不影响；
- 高并发时不会让线程被堵死；
3. 逻辑处理单元（逻辑层）
逻辑层是服务器的大脑，决定了服务器能做什么。
每种业务逻辑（比如用户登录、文件请求、动态响应）都可以拆成独立模块，通过请求队列调度执行。
这部分一般是多线程处理。通常会引入线程池，让多个任务可以并行处理，提高吞吐量。
4. 网络存储单元
网络存储单元负责数据的存取和缓存。
常见内容包括：
- 客户端会话信息；
- 静态文件缓存；
- 数据库接口。
逻辑层需要数据时直接去这一层拿，保证数据访问快速，同时线程安全。
小结
简单总结一下整个框架：
- IO处理单元：负责网络收发和事件监听；
- 请求队列模块：缓冲任务，解耦 IO 和逻辑；
- 逻辑处理单元：执行具体业务逻辑；
- 网络存储单元：提供数据访问和缓存支持。
整个流程可以理解为一条流水线：客户端请求 → IO 层接收 → 放入请求队列 → 逻辑层处理 → 网络存储访问 → IO 层发送响应。
在下一篇（WebServer 02）中，我们会深入 Reactor 模型，讲解服务器如何用 epoll + 非阻塞 IO 来实现高性能事件驱动。
