服务器：入口系统如何与业务、网络两系统接边界
服务器不是「业务之上多了一层通信层」。服务器本身是一个完整的入口系统——长期运行、并发调度、解析分发。它落在三系统边界的上端：入口系统（服务器）+ 业务系统 + 网络系统。这一篇讲服务器如何进入这个边界，以及它和 CLI、业务库、网络系统的分工。
一、服务器 vs CLI：都是入口，但形态完全不同
CLI 的核心是「一次任务的执行入口」，服务器的核心是「长期运行的服务入口 + 并发请求调度」。
1
2
3
4
5
6
7
8
| CLI：
启动 → 解析参数 → 执行任务 → 输出结果 → 退出
（一次执行，一个任务，顺序执行）
Server：
启动 → 初始化 → 监听端口 → 等待请求 → 收到请求
→ 解析请求 → 调用业务 → 生成响应 → 继续等待请求 → ……
（长期运行，大量请求，并发处理）
|
CLI 的「命令」变成了 Server 的「请求处理器」：
1
2
3
4
5
| CLI：mytool process --pid 1234
ProcessCommand → ProcessService → ProcessManager
HTTP：POST /process { "pid": 1234 }
ProcessController → ProcessService → ProcessManager
|
下面基本没变，变的是入口。
二、服务器进入三系统边界
服务器落在三个系统的边界上：
1
2
3
4
5
6
7
8
9
| ┌──────────────────────────────────────────┐
│ 入口系统（服务器） │
│ 通信协议 + 请求解析 + 请求分发 + 调用 │
├──────────────────┬───────────────────────┤
│ 业务系统 │ 网络系统 │
│ Service/Domain/ │ EventLoop/Connection │
│ Algorithm │ Session/Protocol/ │
│ │ Buffer │
└──────────────────┴───────────────────────┘
|
服务器在这条边界上的位置：
1
2
3
| 入口系统（服务器）：管请求怎么进来、怎么解析、怎么分发、怎么响应
业务系统： 管业务逻辑怎么完成
网络系统： 管字节怎么收发、连接怎么管理
|
服务器 = 一个业务执行平台/通信运行系统；业务静态库是被这个平台调用的业务能力。
三、服务器内部的结构
服务器的完整形态：
1
2
3
4
5
6
7
8
9
| main → 实例化/启动 → Server
Server
├── Protocol HTTP / WebSocket / RPC（协议）
├── Network Socket / Connection / EventLoop / Buffer（网络系统）
├── Parser 请求解析（入口系统）
├── Dispatcher/Router 请求分发（入口系统）
└── Handler 调用层（把请求交给业务）
↓
Business Library（Service + Domain + Algorithm）
|
一次请求的完整路径：
1
2
3
4
5
6
7
8
9
10
| POST /login
→ HTTP Request
→ Server
→ HTTP Parser（解析请求）
→ Router（分发请求）
→ LoginHandler（调用层）
→ LoginService（业务系统）
→ Domain / Algorithm
→ 返回业务结果
→ Handler 转成 HTTP Response
|
服务器负责「解析、分发、调用」，业务负责「完成业务」。
四、服务器 vs 业务系统的边界
服务器不拥有业务，它只拥有「怎么接收请求、怎么找到功能、怎么返回结果」：
1
2
3
4
5
6
7
8
9
10
11
| 服务器（入口系统）：
→ 通信协议（HTTP/TCP）
→ 请求解析（Parser）
→ 请求分发（Router/Dispatcher）
→ 调用（Handler）
→ 生命周期管理
业务（业务系统，静态库）：
→ Service（业务任务组织）
→ Domain（业务对象）
→ Algorithm（业务算法）
|
1
2
3
4
5
6
7
8
| 业务做成静态库：
business/
├── include/ LoginService.h / UserService.h
├── src/ LoginService.cpp / UserService.cpp
├── domain/
├── algorithm/
└── CMakeLists.txt → libbusiness.a
|
服务器调用它：
1
2
3
4
5
6
| #include <business/LoginService.h>
void LoginHandler::handle(const Request& request) {
auto result = LoginService::login(request.username(), request.password());
}
|
服务器不需要知道登录业务内部怎么实现。
五、服务器 vs 网络系统的边界
网络系统是服务器之下的一部分——但不是「服务器的通信层」，而是独立的组件集合：
1
2
3
4
5
6
7
8
| 网络系统（组件，非分层）：
EventLoop / Connection / Session / Protocol / Buffer
只管字节收发、连接管理、会话维护、协议格式
服务器（入口系统）：
Parser（字节↔消息）
Dispatcher（消息→Handler）
只管解析、分发、调用
|
边界：
1
2
3
| 网络系统：字节进、字节出
入口系统：消息解析、请求分发
业务系统：业务处理
|
HTTP/TCP 是网络系统提供的能力，服务器只是入口程序。 网络系统是程序内部的网络运行子系统，不是 OSI 七层模型中的某一层。
六、入口也要分层
服务器这条线上，「入口」不止一层：
1
2
3
| 通信协议入口 HTTP Server（接收 HTTP 请求）
请求分发入口 Router / Handler（找到处理函数）
业务入口 Service（执行业务）
|
1
2
| 客户端 → HTTP Request → HTTP Server → HTTP Parser → Router
→ Handler → Service → Domain/Algorithm → Database
|
HTTP 是通信协议；HTTP Server 是协议入口；Router/Handler 是请求分发入口；Service 是业务入口——「入口」也应该分层理解。
七、服务器新增的复杂性：运行环境工程
服务器真正比 CLI 多的，不是「多一个 Server 类」，而是运行环境：
1
2
3
4
5
6
7
8
9
10
11
12
| 并发
请求生命周期
连接生命周期
线程池 / 协程
超时
限流
请求取消
状态管理
日志
配置
错误恢复
服务启动 / 停止
|
这些属于服务运行环境的工程问题——是入口系统的职责，不是业务系统的职责。
八、和其他线的关系
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
| 服务器 ←→ 服务器入口的解构（04-系统角色/07）
边界线讲服务器怎么和业务/网络接边界
解构线讲服务器入口内部按入口骨架（接受→解析→分发→调用）解构
——本线的 Parser/Dispatcher/Handler 正是解构线的解析层/分发层/调用层
服务器 ←→ 从指令到系统/03（三系统协作）
03 讲业务+网络+入口三系统怎么组合
本线讲「服务器作为入口系统」的完整形态和边界
服务器 ←→ 网络系统（组件拆分/组装）
网络系统 = 5 组件（EventLoop/Connection/Session/Protocol/Buffer）
服务器 = 入口系统（Parser/Dispatcher/Handler），在网络系统之上
服务器 ←→ 从输入到交互
CLI/GUI 是用户交互入口，服务器是网络请求入口
它们都是入口适配器，汇聚到同一套业务核心
服务器 ←→ 框架化组件 + 依赖注入
服务器是最大的框架化组件（长期运行、有生命周期）
业务/网络组件被它调用 → 依赖注入出现
服务器 ←→ 七条流
启动流（服务器怎么起来）、运行流（请求怎么流动）
生命周期（Server/Connection/Request 嵌套生命周期）
|
收束
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| 服务器 = 长期运行的服务入口 + 并发请求调度（vs CLI 一次任务）
服务器进入三系统边界：
入口系统（服务器）：解析、分发、调用
业务系统：完成业务
网络系统：收发字节、管理连接
服务器内部：Protocol → Network → Parser → Dispatcher → Handler → 业务
边界：
vs 业务：服务器不拥有业务，只负责接收/查找/返回
vs 网络：网络系统管字节，服务器管消息
入口分层：协议入口 → 请求分发入口 → 业务入口
新增复杂性：并发/生命周期/线程池/超时/状态 = 运行环境工程
|
服务器不是「业务上多一层通信」，而是完整的入口系统。 它站在三系统边界的上端，把网络系统的字节和业务系统的能力连起来。
