1. 先立顺序：从"系统"出发，而不是从"服务器"出发

教材把这节放在第三章开头，是有意为之——上一章讲完硬件，很容易让人产生"我要买一台什么样的服务器"的冲动；而正确的第一句话应该是"我这个系统要干什么"。

链条是这样的：

业务需求 → 系统模型 → 性能预估 → 服务器选型

反过来做（先选型再想用途）会出两种错：

2. 系统与服务器：先把"系统"两个字说透

第一章 1.1-1.3 已经钉过定义：系统 = 客户端 + 网络 + 服务器，三者缺一不成系统。

服务器在里面扮演什么角色？回想"司令塔"三个字：

• 它不是发号施令的那一方，而是应答 + 分发的一方；
• 它存在的理由是"别人要用它"——没有客户端，服务器就不成立。

所以"先是系统，然后才是服务器"这句话，落成一句可操作的话是：

先回答"谁、通过什么、来干什么"，服务器的配置自己会浮出来。

举一个跟你行当贴边的例子——设计院的图纸共享：

同一个"图纸共享"，四步下来服务器的台数和类型完全不同——变的不是服务器，是系统。

3. 系统模型：把系统画成"能算"的图

第一章 1.7-1.9 讲过"模型化"，这里给出具体标准：模型不是画给人看的，是画给"算"用的。

一张合格的系统模型图，必须写清四件事：

4. 性能预估：从模型算出"要多大"

模型画完，就可以算容量了。性能预估不是拍脑袋，是三个数的乘法：

① 并发数 = 总人数 × 同时在线比例 ② 请求速率（QPS） = 并发数 ÷ 每个请求之间的间隔 ③ 需要的核数 = 峰值 QPS ÷ 单核算力

单核算力怎么来？1000 ÷ 单请求占用毫秒数——比如一条请求占用服务器 200 毫秒，一个核一秒就能处理 5 条。

举个完整例子（60 人的小团队）：

• 同时在线：60 × 30% = 18 人
• 每人每 3 秒产生一个请求 → 平均 6 QPS
• 峰值系数取 3（早会前集中操作）→ 18 QPS
• 单请求 200ms → 单核 5 QPS → 需要 18 ÷ 5 ≈ 4 核

关键结论：按峰值定容量，按平均值算成本。

5. 定制：需求决定架构，架构决定配置

"定制"两个字不是挑品牌、选颜色，而是——把瓶颈找出来，给它加料。

同一笔钱，花在瓶颈上叫定制，花在别处叫浪费。

6. 投资与回报：真的有必要用服务器吗

买之前先问自己四个问题：

1. 现在哪儿不够用？——说不出具体痛点，就不必买。
2. 有没有更轻的替代？——NAS、云盘、SaaS、托管机房，很多需求根本不需要"一台服务器"。
3. 谁来维护它？——买机器只是开始。没人的话，它就是个定时炸弹。
4. 停一天，损失多少？——这个数直接决定你该买"几个 9"（2.1~2.3 的可用性阶梯）。

总拥有成本（TCO）：买机器只是第一笔

回报怎么算

服务器的回报不体现在"它帮我赚了多少钱"，而体现在省下的工时和避免的损失：

• 省工时：图纸集中管理后，每人每天少花 15 分钟找版本 → 60 人 × 15 分钟 ≈ 每天 15 小时 ÷ 8 = 约 2 个人力
• 避损失：一次误删图纸造成的返工，可能就抵掉整台服务器的采购价
• 不再发生的成本：U 盘来回拷、邮件发图纸附件、版本对不上

7. 什么时候不该买服务器

这一节教材的标题是一个问句，答案就藏在问句里——"真的有必要吗"是每次都要重新回答的问题。

不该买的信号：

• 就你一个人用（本地装个软件就完事）
• 需求还在天天变（先上云，稳定了再落地）
• 团队里没有能维护它的人
• 业务量小且平稳，现成 SaaS 更便宜省心

该买的信号：

• 数据不能出内网——这一点对你的行当特别实在：图纸、甲方资料、报价合同属于敏感信息（2.8~2.12 的"云的四坑"里专门说过）
• 并发高且长期稳定，规模已经摊得起
• 需要和内部系统深度集成，买现成的接不上

8. 动手时间（Demo07）：给一个真实场景算容量

60 人的小团队要上一个图纸共享系统，先算算需要多少核。把下面这段贴进 PowerShell 就能跑：

function Estimate-Capacity {
    param(
        [int]$Users = 60,            # 总人数
        [double]$OnlineRatio = 0.3,  # 同时在线比例
        [int]$ThinkSeconds = 3,      # 每人多少秒产生一次请求
        [int]$ServiceMs = 200,       # 每条请求占用服务器多少毫秒
        [double]$PeakFactor = 3      # 峰值系数（繁忙时段是平均值的几倍）
    )
    $concurrent = [math]::Ceiling($Users * $OnlineRatio)
    $qps        = [math]::Round($concurrent / $ThinkSeconds, 2)
    $peakQps    = [math]::Round($qps * $PeakFactor, 2)
    $perCore    = [math]::Round(1000 / $ServiceMs, 1)
    $cores      = [math]::Ceiling($peakQps / $perCore)
    [pscustomobject]@{
        '同时在线（人）' = $concurrent
        '平均每秒请求'   = $qps
        '峰值每秒请求'   = $peakQps
        '单核每秒能力'   = $perCore
        '按峰值需要核数' = $cores
        '留 50% 余量后'  = [math]::Ceiling($cores * 1.5)
    }
}

Estimate-Capacity

然后动手改参数，做三次对比：

# 情景一：60 人，平稳使用
Estimate-Capacity

# 情景二：人数涨到 300（公司规模扩大 5 倍）
Estimate-Capacity -Users 300

# 情景三：还是 60 人，但每条请求变重（报表/渲染，占 2 秒）
Estimate-Capacity -ServiceMs 2000

观察点：

1. 人数翻 5 倍，核数也大致翻 5 倍——容量问题基本是线性的，先算清楚总比事后猜强；
2. 情景三最值得盯：人数没变，只是"活变重了"，需要的核数却暴涨 10 倍。这就是"定制"的含义——先看活有多重，再决定机器多大。
3. 注意最后一行"留 50% 余量"和"需要核数"的差距——真实采购看的是余量那一行。

9. 30 秒实验

1. 实验 1（系统先于服务器）：打开你手机上任意一个 App，用纸笔写下它的"客户端 / 网络 / 服务器"三格。写不满三格说明你还没想清它是什么系统。
2. 实验 2（家里的服务器）：数一数家里有几台设备在"等着被访问"——路由器后台、NAS、网络摄像头录像机、智能音箱。它们都是服务器，只是没人这么叫。
3. 实验 3（峰值思维）：回想你所在场景的"最忙时刻"（出图前夜？季度末？），判断它比平时忙几倍——这个倍数就是性能预估里的峰值系数。

10. 常见误区

1. "先把服务器买了，用途慢慢想"——顺序反了。买完才发现配置不对，损失的不只是钱，还有迁移和停机的时间。
2. "性能预估就是拍脑袋估个大概"——它是可算的：并发数 × 请求速率，再除单核算力。第 8 节的 Demo 就是完整算例。
3. "按平均负载买就够了"——平均值决定成本，峰值决定容量。系统崩的时候永远是峰值那一刻。
4. "买机器是一次性投入"——TCO 里采购只是一小部分。电费、许可、维保、人力才是长期大头，其中人力最容易漏算。
5. "云一定比自建贵"或"云一定比自建便宜"——两个都错。看规模和使用时长：规模大、用得久、负载稳定 → 自建更划算；规模小、需求多变 → 云更划算（3.1-3.3 篇的曲线图）。
6. "服务器买回来就完事了"——它是要养的。备份、打补丁、看监控、换坏盘，缺了这些，服务器反而变成最大的风险点。

11. 折叠自测题

12. 下一步学什么

• ☑ 3.4-3.6 服务器与从属计算机的通信（IP、MAC、TCP、路由器） —— 服务器与从属计算机的通信（IP、MAC、TCP、路由器） 点此继续：机器买回来了，它怎么找到 "自己的" 那些客户端？

相关笔记

• 服务器与从属计算机的通信（IP、MAC、TCP、路由器） —— 算完账买回来，它就该跟客户端说话了

• 系统与司令塔（系统与服务器、使用形态、被动式运用形态） —— 系统三件套的定义篇

• 服务器的位置与外部世界（网络、部署、云、大型机） —— 本篇"自建还是租云"的账，在那里有部署四档与云的四坑
• 与PC的三重差异（可靠性、性能、操作系统） —— 可用性几个 9 决定"停一天损失多少"的预算
• 网络 2.5 如何构建网络（网络的设计） —— 网络课同款思路：先设计，再拉线
• 网络 2.6 明确网络的结构（网络结构图） —— "系统模型"在网络课里的名字叫网络结构图
• 网络 1.8 云服务的分类（SaaS、PaaS、IaaS） —— "有没有更轻的替代"的标准答案表
• 🔵 计算机基础 · 自学笔记 —— CPU、内存、存储的底层常识（算容量要用）