为什么需要“服务排队”和“资源围栏”？与Systemd After
实际操作要点
折腾Systemd After时，我发现最麻烦的往往不是安装，而是配置。想象你开了一家24小时营业的奶茶店。店里有制冰机、果汁机、封口机多台设备。如果你同时按下所有开关，整条街的电路会跳闸。更合理的方式是：先开总闸，再开制冰机，等冰制好后，再开果汁机和封口机——这就是“服务依赖”。而每台设备限定最大电流，避免互相抢电——这就是“资源管控”。
在Linux服务器上，Systemd扮演着店长的角色，负责调度所有后台程序（称为“服务”）。而cgroups（Control Groups）则是电表箱里的空气开关，为每个进程组划定CPU、内存的使用上限。本文要讲的两件事，正是Systemd如何定义服务的启动顺序（依赖关系），以及如何通过cgroups V2对服务占用的CPU和内存做精细化限制。
第一部分：Systemd服务依赖关系——让服务按顺序“上班”
1. After与Requires：命令式与强制式
在Systemd的服务单元文件（.service）中，[Unit]段落里有两个最常用的依赖指令：After=和Requires=。很多新人会混淆它们，其实逻辑很简单：
- After= 只规定“什么时候启动”，不规定“必须一起启动”。比如你在After里写了
network.target，Systemd会等网络准备好后再启动你的服务，但如果网络启动失败了，你的服务照样会启动（可能因为没网而报错，但Systemd不阻止）。 - Requires= 则规定“我离不开它”。如果
Requires=mysql.service，那么当mysql服务启动失败或意外停止时，Systemd会连带着把你的服务也停掉。注意：Requires默认不保证启动顺序——它只保证“存在性”，你需要结合After来确保顺序。
真实场景对比：
比如你的Web应用依赖数据库：
[Unit]
Description=My Web App
After=network.target mysql.service
Requires=mysql.service
这里After=mysql.service保证Web应用在数据库之后启动；Requires=mysql.service保证如果数据库挂了，Web应用也会被Systemd自动杀掉，避免产生孤儿连接。
2. Wants：温和版的Requires
现实中有一种“软依赖”：启动A时最好也顺便启动B，但如果B失败，A照样运行。比如你的Web应用希望日志收集服务也在运行，但日志挂了不影响业务。这时就用Wants=。它不会造成A因为B失败而停止，但会尽量尝试让B启动。
小技巧：多数情况下推荐用After + Wants组合来替代单纯的Requires，因为Requires的“连坐制”在生产环境中可能造成级联故障，除非你明确知道必须强绑定。
3. 依赖关系的可视化与调试
运行systemctl list-dependencies your-service可以查看某服务的依赖树。例如：
systemctl list-dependencies nginx.service
输出会展示nginx所依赖的target和服务，包括sysinit.target、network.target等。如果发现你不希望的依赖，可以通过[Unit]段的DefaultDependencies=no来关闭大部分隐式依赖（但要谨慎）。
第二部分：cgroups V2——给每个服务装上“CPU和内存水龙头”——Systemd After
1. 从cgroups V1到V2：为什么要升级？
Linux内核的cgroups机制，自2007年诞生起，经历了V1版本的多层级混乱（每个子系统拥有独立的树，例如cpu、memory各画各的树，管理起来像一团乱麻）。cgroups V2在2016年合入主线，统一为单层级树，所有资源控制都在同一个目录下。Systemd从v232开始支持cgroups V2，当前主流发行版（Ubuntu 22.04+、Debian 12+、RHEL 9+）默认使用V2。
为什么要关心这个？因为cgroups V2提供了更精确的资源上限控制和压力通知机制，是容器和云原生世界的底层基石。对于普通Linux管理员，只需记住：V2之后，你可以在Systemd单元文件中直接写CPUQuota=、MemoryMax=来限制服务资源，而不用手动创建cgroup目录。
2. CPU管控：CPUQuota与CPUAccounting
假设你的服务器是4核CPU（即400%），你希望某个后台服务最多占用1.5核。在服务的[Service]段中加入：
[Service]
CPUAccounting=on
CPUQuota=150%
CPUAccounting=on 开启CPU使用统计，否则配额不生效。CPUQuota=150% 表示该服务及其子进程最多能占用1.5个逻辑核心。如果服务试图超过这个值，内核会强制调度它下来，让出CPU时间片。
还有一个常用的是CPUWeight=（cgroups V2中的权重控制），用于在多个服务之间按比例分配CPU，而不设硬上限。比如：
[Service]
CPUAccounting=on
CPUWeight=200
如果另一个服务权重100，则你的服务获得两倍CPU时间（前提是CPU有争抢）。权重最适合“尽力而为”场景，硬配额适合“不能超标”场景。
3. Memory管控：MemoryMax与MemoryHigh
内存限制同样在[Service]段设置：
[Service]
MemoryAccounting=on
MemoryMax=512M
MemoryHigh=384M
- MemoryMax= 硬上限。服务使用的内存（包括物理内存+swap）超过此值，内核会开始OOM Killer杀掉进程。这是最后的防线。
- MemoryHigh= 软上限。当内存超过此阈值，内核会积极回收该服务的缓存和可回收页（比如page cache），但不会立即杀进程。这给了服务一个“减速带”，避免突然触达硬上限导致被杀。
注意：MemoryAccounting=on 必须开启，否则限制无效。另外，cgroups V2中MemoryMax的单位可以是K、M、G，或使用百分比（如MemoryMax=50%表示系统总内存的50%）。
4. 别遗漏IO和PID限制
Systemd还支持IOReadBandwidthMax=、IOWriteBandwidthMax=、TasksMax=（限制进程数）。虽然本文聚焦CPU和内存，但实际生产中磁盘IO限制往往更重要。比如：
[Service]
IOAccounting=on
IOReadBandwidthMax=/dev/sda 50M
这样指定块设备的读写带宽上限。
第三部分：结合依赖与资源管控——一个真实场景
容易忽略的细节
假设你需要部署一个PHP-FPM + MySQL的组合，并且希望PHP-FPM最多占用2核CPU和1GB内存，MySQL最多占用4核和4GB内存，且两者必须在网络就绪后启动，且PHP-FPM依赖MySQL（MySQL挂了则自动停掉PHP-FPM）。
编辑/etc/systemd/system/php-fpm.service的[Unit]和[Service]段：
[Unit]
Description=PHP FastCGI Process Manager
After=network.target mysql.service
Requires=mysql.service
[Service]
Type=notify
ExecStart=/usr/sbin/php-fpm --nodaemonize
CPUAccounting=on
CPUQuota=200%
MemoryAccounting=on
MemoryMax=1G
MemoryHigh=800M
对于MySQL：
[Service]
CPUAccounting=on
CPUQuota=400%
MemoryAccounting=on
MemoryMax=4G
MemoryHigh=3.5G
重启服务：systemctl daemon-reload && systemctl restart php-fpm mysql。之后使用systemd-cgtop或systemctl show php-fpm查看实际资源用量。
关联教程：此处可内链到“Systemd After部署与验证”内容。
相关阅读：此处可内链到“Systemd After常见问题”专题。
想继续深入：此处可内链到“Systemd After优化清单”文章。
第四部分：验证与调试——你配置的真的生效了吗？
配置写完了，如何确认Systemd确实创建了cgroup并施加了限制？
1. 检查cgroup文件系统
cgroups V2挂载在/sys/fs/cgroup下。每个Systemd单元对应的cgroup目录路径为：/sys/fs/cgroup/system.slice/服务名.service/。例如：
cat /sys/fs/cgroup/system.slice/php-fpm.service/memory.max
如果输出为1073741824（即1GB），说明限制已生效。
2. 使用systemd-cgtop实时监控
安装systemd-cgtop（通常包含在systemd包中），运行：
systemd-cgtop
它会像top一样显示每个systemd slice或scope的CPU、内存、IO使用量。你可以直接看到php-fpm的CPU占比是否被限制在200%以下。
3. 压力测试确认
使用stress工具给服务加压：
systemd-run --unit=test-stress --scope stress --cpu 4 --vm 2 --vm-bytes 2G
然后观察systemd-cgtop中test-stress的CPU和内存是否被限制在预设值内。注意systemd-run --scope会创建一个临时scope，适合测试。
第五部分：常见陷阱与回滚建议
1. 依赖循环导致无法启动
如果在After和Requires中形成了环（如A requires B，B requires A），Systemd会检测到并拒绝启动。解决办法：重新评估依赖关系，或者使用Wants替代。
2. 忘记开启Accounting
很多用户写了CPUQuota=但忘了CPUAccounting=on，结果限制不生效。因为Systemd默认不启用资源统计（为性能考虑）。同样，Memory、IO都需要对应Accounting开关。
3. 硬内存限制导致进程频繁被杀
如果MemoryMax设得过低，业务高峰期服务进程可能被OOM Killer杀死。建议先用MemoryHigh软限制，再逐步降低MemoryMax。你可以在systemctl status中看到“Memory high watermark”信息，帮助你调整。
4. 如何回滚？
如果配置导致服务异常，第一时间执行：
systemctl revert 服务名.service
这会删除你添加的drop-in文件或修改，恢复服务到软件包默认配置。如果是直接编辑了/etc/systemd/system/下的主文件，建议先备份再修改，回滚时直接恢复原文件并daemon-reload。
更稳妥的做法：生产环境使用drop-in文件（/etc/systemd/system/服务名.service.d/override.conf），这样回滚只需删除整个.d目录。
补充参考：此处可内链到“Systemd After故障排查实例”。
总结
实际操作要点
Systemd的After/Requires解决了服务之间的“先后顺序”和“生死相依”关系，而cgroups V2通过CPUQuota、MemoryMax等参数为每个服务划定了资源边界。两者的结合，让你能像编排乐团一样精确控制每台服务器的行为——哪个先登场、哪个不能超过多少音量。掌握这些概念，是迈向可靠运维和云原生架构的重要一步。
下次当你面对一台“高负载时MySQL把PHP挤到OOM”的服务器时，不妨先检查是否给PHP加了MemoryMax，给MySQL加了CPUQuota，并确认After=mysql.service写对了。按这个顺序复查，Systemd After遇到异常时也更容易定位。
延伸阅读