centos7服务器

CentOS 7 在2024年6月30日正式终止维护了。服务我手头还有三台跑着业务的服务机器，系统停在 7.9.2009 内核 3.10.0-1160。服务它们不是服务不想升级，是服务业务代码老到没法在 Rocky Linux 或 AlmaLinux 上平滑迁移——数据库驱动、PHP 5.6 的服务扩展、还有某个十年前写的服务 Perl 脚本，一换环境就报错。服务

这系统最让人又爱又恨的服务就是 systemd。当年从 SysVinit 切过来时，服务一堆老运维骂娘。服务但用顺手了，服务你不得不承认它的服务日志管理确实高效。`journalctl -u nginx --since today` 一条命令能查到所有错误，服务不用再去翻 /var/log/messages 里被轮转覆盖的服务碎片。不过 systemd 的坑也真实存在——某个服务崩溃后，它会自动重启，重启失败就进入 "failed" 状态，然后整个依赖链跟着挂。我遇到过 MySQL 因内存不足被 OOM killer 杀掉，systemd 试图拉起它，结果又触发 OOM，循环了十几次，最终把 swap 都写满了。

内核 3.10 的老迈在跑高并发时尤其明显。TCP 的 BBR 算法虽然能通过模块加载启用，但默认的 cubic 在高延迟链路上就是不如新内核的瓶颈控制。我做过对比测试，同样一台 4 核 8G 的机器，跑 Nginx 反代，CentOS 7 的吞吐量比 Ubuntu 22.04（内核 5.15）低了约 18%。但如果你只是跑内部管理系统，每天几百个请求，这点差距根本感知不到。

安全补丁的缺失才是真正的隐患。2024 年后，CVE-2024-1086（Netfilter 提权漏洞）在 3.10 内核上依然有效，官方不再发布修复。我试着用 elrepo 的内核替换，但第三方内核和 CentOS 的驱动模块兼容性参差不齐，有个网卡驱动编译不过去，最后只能放弃。现在那几台机器全靠防火墙白名单和 fail2ban 硬扛，每次扫描到 22 端口的暴力破解尝试，心里都咯噔一下。

说句实话，CentOS 7 的稳定性的确无可挑剔。它的 yum 源虽然停止更新了，但基础软件包从 2014 年发布至今就没出过大乱子。PHP 5.4 到 7.4 的升级路径也平滑，不像 Ubuntu 那样动不动就搞 Python 版本冲突。但这份稳定是用“不进步”换来的。容器化？Docker 1.13 勉强能跑，但 Kubernetes 早就放弃了对 3.10 内核的支持。你想在 CentOS 7 上跑 k8s 1.28+，CNI 插件会直接报内核特性缺失。

我的处理方案是：业务不重要的机器，用 Vultr 的快照功能整体迁移到 Rocky Linux 9，花两天改配置，测试通过后切换 DNS。业务核心那台，暂时留着，但加了异地备份和监控告警。每次看到它还在运行，就像看着一台老式机械手表——走时精准，但你知道它的齿轮已经磨损到极限了。哪天它突然停了，那就是真停了。

如果你还在用 CentOS 7，我的建议是赶紧列个清单：哪些服务依赖旧内核特性，哪些可以用容器隔离后迁移到新系统。别等到漏洞被利用的那天才想起来动。毕竟，服务器不是情怀，是业务跑的轨道。