服务器形态演进与上层软件架构
服务器的形态不是一夜之间从塔式跳到整机柜的，每一代变化都伴随上层软件栈的演进。这一篇换一个视角，把硬件形态和软件栈放在同一根时间轴上。
一条时间线
timeline title 服务器形态与软件栈演进 1964 : 大型机 System/360
批处理 OS 1970s : 小型机 PDP-8 / VAX
分时 OS 1989 : x86 服务器 SystemPro
NetWare/Windows NT 1990s : RISC Unix 小型机
Solaris/AIX/HP-UX 2000s : x86 机架服务器
Linux + LAMP/J2EE 2008 : 虚拟化普及
VMware ESXi/KVM 2013 : 容器与云原生
Docker/Kubernetes 2017 : 刀片走弱
整机柜兴起 (OCP/天蝎) 2020 : AI 服务器
HGX/DGX 平台 2024 : 整机柜 AI
GB200 NVL72
Scale Up vs Scale Out
整个演进的核心问题是一句话：“做大单台机器（Scale Up）还是堆很多台机器（Scale Out）？”
graph LR
subgraph SU["Scale Up（向上扩展）"]
SU1[一台超强机器]
SU2[多 CPU 路数]
SU3[大内存]
SU4[共享存储]
end
subgraph SO["Scale Out（向外扩展）"]
SO1[多台普通机器]
SO2[单机简化]
SO3[网络互联]
SO4[分布式调度]
end
| Scale Up | Scale Out | |
|---|---|---|
| 代表硬件 | 大型机、小型机、4P/8P x86 | 双路 x86、整机柜 |
| 代表软件 | Oracle RAC、SAP HANA | Hadoop、Kubernetes |
| 单点性能 | 极强 | 一般 |
| 故障域 | 大 | 小 |
| 扩展上限 | 物理瓶颈（背板、CPU 路数） | 理论无限 |
| 单位成本 | 高 | 低 |
互联网时代的主基调是 Scale Out——用 Linux + 大量 x86 + 分布式软件，替代了大型机/小型机的”重型路线”。但近几年 AI 训练又出现 Scale Up 的回潮：单机柜 NVL72 = 72 GPU 共享内存 实际上是把”机柜变成一台超大机器”。
服务器外形演进的内在逻辑
1970s–1980s：大型机/小型机时代
机器和家具一样大，价格以”百万美元”为单位。一台机器跑整个企业的业务。OS 自带数据库、自带文件系统、自带远程终端。
1990s：Unix 小型机的黄金十年
IBM Power、Sun SPARC、HP PA-RISC 三足鼎立。这一代机器追求极致单机可靠性：双 CPU、热插拔内存、双控存储、双路供电。一台机器跑十年是常态。
代表 OS：Solaris、AIX、HP-UX。
1989–2000s：x86 杀入数据中心
1989 年康柏推出 SystemPro——全球第一款 IA 架构服务器，2 颗 Intel 486。
之后十年，靠摩尔定律的飞速进步，x86 的性能/价格比把 RISC 挤出了 80% 以上的服务器市场。这背后是软件生态的胜利：
- Linux 把 Unix 体验带到 x86
- Windows NT/2000/2003 Server 拉拢 ISV
- MySQL、PostgreSQL 替代收费数据库
- Apache、Nginx 替代专有 Web 服务器
到 2010 年，双路 1U/2U x86 机架服务器已经是数据中心绝对主流。
2008 起：虚拟化把”一台机器拆成 N 台”
VMware ESXi 让一台物理服务器跑十几个虚拟机成为标配。从此：
- 服务器规格往”大”方向走（更多内存、更多核），单台机器承载更多虚机
- 资源池化、动态迁移成为运维标配
- 商业公司（VMware/Microsoft）一度赚得盆满钵满
2013 起：容器和云原生
Docker 让”启动一个隔离环境”从分钟级降到秒级。Kubernetes 把”调度容器到合适机器”变成自动化。
软件栈结果：
graph TB HW[物理服务器] HW --> OS[Linux Kernel] OS --> RT[容器 Runtime
containerd/CRI-O] RT --> POD[Pod / 容器] POD --> APP[应用] K8S[Kubernetes 控制面] -.调度.-> POD
容器对硬件的影响：服务器规格回归”够用就好”——更需要的是”很多台机器 + 高速网络”。
2017 起：整机柜与 OCP
互联网巨头发现：自己设计服务器比买戴尔/HPE 便宜得多。Facebook 牵头成立 Open Compute Project（OCP），开源服务器硬件规范；阿里、腾讯、百度联合搞天蝎计划。整机柜方案诞生：
- 一柜出厂就是 N 个节点 + 集中电源 + 集中风扇
- 母线槽供电，节点免线缆插拔
- BMC 可批量管理整柜
第 8 篇会专门讲整机柜。
2020 起：AI 服务器是新物种
ChatGPT 之前就有 AI 服务器，但是 ChatGPT 之后才真正爆发。它和通用服务器的核心差异在第 4 篇讲过——这里要补一点：AI 服务器把”芯片间互联”提升到了主板设计的核心位置。
NVIDIA HGX 平台、AMD MI300X 平台、华为 Atlas 平台都遵循同一思路：CPU 是配角，8 颗 GPU + NVLink/InfinityFabric/HCCS 全互联才是主舞台。
服务器上层软件架构：标准的五层
不管硬件形态怎么变，服务器上跑的软件栈基本可以分五层：
graph TB L5[业务应用层
Web / DB / AI / 大数据] L4[运行时层
JVM / Python / 容器] L3[OS 层
Linux / Windows] L2[虚拟化层
VMware / KVM / Hypervisor] L1[BIOS/UEFI + 固件层] L0[硬件层] L5 --> L4 --> L3 --> L2 --> L1 --> L0
每一层都可以独立替换、独立优化：
- L0 硬件：是本系列前 6 章的全部内容
- L1 BIOS/UEFI：开机第一段代码、CPU 微码、内存训练、BMC 协作；现代趋势是 OpenBMC + UEFI Secure Boot
- L2 虚拟化：可有可无，公有云/私有云都在这一层
- L3 OS：第 7 章的内容
- L4 运行时：JVM、Python、容器，决定开发体验
- L5 应用：业务的最终落点
服务器层次架构：硬件视角的”五层”
把硬件本身也分层来看，可以画出对应硬件每一层”做什么”的一张图：
graph TB H5[服务器集群层
K8s/HPC 调度] H4[整机层
1U/2U/整机柜] H3[节点内互联层
PCIe/NVLink/UPI] H2[部件层
CPU/GPU/内存/盘/网卡] H1[半导体层
晶体管/封装] H5 --> H4 --> H3 --> H2 --> H1
理解这两张分层（硬件 + 软件），意味着当一个性能问题出现时，你能定位到正确的层去找答案——比如：
- “Pod 调度慢” → L5/L4
- “容器启动后 TPS 低” → L3/L4
- “QPS 抖动” → L2 vCPU 调度 / L0 NUMA
- “训练吞吐不上去” → L0 GPU 互联
应用部署架构：三种典型
最后用三张图把”软件如何部署在服务器上”扫一遍：
1. 经典三层架构（2000s）
graph LR USR[用户] --> WEB[Web 服务器] WEB --> APP[应用服务器] APP --> DB[(数据库)]
每层独立扩展。典型配置：Web 用便宜机器水平扩，App 用中端机器，DB 用高端机器（Scale Up）。
2. 微服务 + 容器（2015+）
graph LR USR[用户] --> GW[API 网关] GW --> S1[服务 A 容器组] GW --> S2[服务 B 容器组] GW --> S3[服务 C 容器组] S1 --> CACHE[(缓存)] S2 --> DB[(分布式 DB)] S3 --> MQ[(消息队列)]
每个服务独立部署、独立扩缩。底层是同质 x86 服务器池 + Kubernetes。
3. AI 训练/推理（2020+）
graph LR DS[(数据集)] --> TRAIN[训练集群
多机多卡 8x GPU] TRAIN --> CKPT[(模型 checkpoint)] CKPT --> INFER[推理集群
1-8 GPU] USR[用户] --> APIGW[API 网关] --> INFER
训练集群强调单机多卡 + 多机互联（NVLink + RoCE）；推理集群强调成本和延迟。
小结
- 服务器形态从”巨型独占”演进到”小型分布式”，再回旋到”机柜级单机”（AI 训练）
- 每次外形革新都伴随软件栈分层升级——VMware、Docker、Kubernetes 都是这样
- 硬件分层和软件分层各自独立，但任何性能问题都能落到具体一层
- 下一篇压轴讲一种特殊形态：整机柜（OCP / 天蝎 / GB200 NVL72）