【开源许可与版权工程】CentOS 停服与生态重组：Rocky、Alma、openEuler、龙蜥

2020 年 12 月 8 日，Red Hat 与 CentOS 项目联合宣布：CentOS 8 将于 2021 年 12 月 31 日停止维护，比原定计划提前近 8 年。CentOS 品牌将转向”CentOS Stream”——一个位于 Fedora 与 RHEL 之间的滚动发布版本，不再是 RHEL 的下游稳定克隆版。

这一决策对全球数百万台运行 CentOS 的服务器产生了直接影响，也在开源社区引发了关于企业责任、许可证治理与基金会控制权的深度讨论。对中国的云厂商、互联网公司和政企用户而言，这次停服触发了一次真实的技术路线重选，直接加速了 openEuler、龙蜥（Anolis OS）等国内替代方案的成熟。

CentOS 停服与生态分叉时间线 2020.12 2021.01 2021.12 2022.05 2023.06 2023.07 2024+ IBM/Red Hat 公告 CentOS 8 EOL 提前 转向 CentOS Stream

分叉项目启动 Rocky Linux 宣布 AlmaLinux 宣布

CentOS 8 EOL 2021 年 12 月 31 日 正式停止更新

Rocky/Alma 正式发布 Rocky 8.6 / Alma 8.6 获得企业用户采用

Red Hat 关闭源码 git.centos.org 关闭 RHEL 源码仅内部可见

SFC 声明 质疑 Red Hat 源码 开放义务

生态稳定期 Rocky/Alma 9.x 国内替代成熟

中国生态替代路线 openEuler 华为 2019 开源 2021 捐赠开放原子基金会

龙蜥 Anolis OS 阿里 2020 开源 2021 捐赠开放原子基金会

TencentOS Server 腾讯云内部演化 CentOS 兼容路线

UOS Server 统信软件 信创场景为主

一、CentOS 停服的背景

1.1 CentOS 的历史定位

CentOS（Community Enterprise Operating System，社区企业操作系统）诞生于 2004 年，其核心价值在于：将 Red Hat Enterprise Linux（RHEL）的源代码包进行重新编译，去除 Red Hat 的商业商标，免费分发给用户。这一模式使 CentOS 成为全球最广泛部署的企业级 Linux 发行版之一，尤其在中小企业、互联网公司和研究机构中占据主导地位。

2014 年，Red Hat 宣布收购 CentOS 项目，原 CentOS 团队成员加入 Red Hat，但承诺继续维护 CentOS 作为免费的 RHEL 克隆版。彼时看来，这是一个双赢的安排。

这种”上游商业版 + 社区免费版”的双轨模式，在 Linux 发行版历史上有其特殊地位。它与 SUSE/openSUSE、Oracle/Oracle Linux、Ubuntu（Canonical）/Debian 等模式有所不同：CentOS 并非 Red Hat 内部的研发版本，而是由社区独立进行再编译与分发，这一关系在 2014 年收购后发生了本质变化——CentOS 项目从独立社区变为 Red Hat 旗下的项目。这一变化为 2020 年的停服决策埋下了伏笔。

1.2 IBM 收购 Red Hat 的影响

2019 年 7 月，IBM 以约 340 亿美元完成对 Red Hat 的收购，这是 IBM 历史上规模最大的一次收购。Red Hat 在 IBM 旗下作为独立事业部运营，但商业压力的变化对开源策略产生了深远影响。

2020 年 12 月 8 日的 CentOS 公告出现在收购完成约 18 个月后。公告由 Red Hat 和 CentOS 项目共同签署，核心内容是：

1. CentOS 8 将于 2021 年 12 月 31 日停止维护（原定 2029 年）；
2. CentOS 7 维持原计划，于 2024 年 6 月 30 日 EOL；
3. CentOS 的未来形态是 CentOS Stream：它不再是 RHEL 的下游克隆，而是 RHEL 的上游开发版，新功能先进入 Stream，再进入 RHEL；
4. 原 CentOS 项目资金和基础设施将继续支持 CentOS Stream。

Red Hat 官方给出的解释侧重”创新加速”——声称 CentOS Stream 能让社区更早参与 RHEL 的开发，反馈周期比原下游克隆模式更短。但从商业角度观察，这一变动的实际影响是：用户想继续使用”稳定 + 免费”的 RHEL 克隆变得不再可能，不得不选择（1）付费 RHEL 订阅；（2）CentOS Stream（滚动更新，稳定性不同）；（3）第三方克隆（彼时尚未存在）。这种”三选一”结构显然有利于 RHEL 订阅收入。

外界普遍认为这一决策与 IBM 的商业整合压力相关，但 Red Hat 官方否认了这一关联，声称决策是 Red Hat 独立做出的。真实决策机制无从考证，但时间点的巧合使外界怀疑难以避免。

1.3 社区的反应

公告发出后 24 小时内，社区反应剧烈。主要批评集中于以下几点：

• 破坏生产环境稳定性：大量服务器在 2029 年的预期下完成了基础设施规划，提前 8 年 EOL 意味着必须重新规划。
• CentOS Stream 不能替代稳定版：Stream 是滚动更新版，其稳定性不能等同于”RHEL 克隆”。生产环境通常不接受滚动更新发行版。
• 治理权限不对等：CentOS 项目的决定实质上由 Red Hat 单方面决定，原始 CentOS 社区贡献者几乎没有话语权。

这次事件对开源基金会治理模式的讨论产生了影响：将关键项目托管于单一公司赞助的结构下，存在公司战略调整导致项目方向突变的风险。

从更宏观的角度观察，CentOS 停服事件在 2021 年之后直接推动了全球企业 Linux 生态的重新洗牌。根据 The Register、LWN 等媒体在 2021–2023 年间的报道，全球约有 700 万台服务器在 2021 年时仍在运行 CentOS 8，这一庞大的装机量是两个克隆版项目能够快速建立社区的根本原因。同时，中国信创政策的推进与全球开源供应链的反思同步发生，加速了本土发行版的成熟。

CentOS 停服也成为开源治理教育的经典案例，被多所高校计算机学院纳入开源软件治理课程，用以说明”单一公司赞助的开源项目”在商业战略变化时的脆弱性。这一启示对后续国内开源基金会（开放原子、木兰等）的建立提供了参考。

从行业影响的时间跨度看，CentOS 停服影响的不仅是 Linux 发行版市场：它直接改变了 DevOps 实践中对操作系统选型的态度（从”CentOS 作为默认”转为”发行版选择要纳入架构设计”）；改变了 CI/CD pipeline 中 base image 的选择规律；改变了安全响应团队对 CVE 补丁路径的依赖（不再能以”等上游 RHEL 补丁 + CentOS 镜像”的简单模式运作）。这些影响叠加起来，对 IT 运营成本的长期影响可能高于最初的迁移成本本身。

1.4 完整时间线表格

下表整理了 CentOS 从诞生到停服、再到生态重构的关键节点。这条时间线跨越近二十年，反映了一个社区项目被商业收购、再被战略重构的全过程。

这张表格对于架构师具有实际参考价值：它帮助在事后回顾时判断，决策应该在哪一个时间窗口介入。例如，若基础设施在 2019 年之后仍在大规模部署 CentOS 8，应当注意到收购带来的潜在策略变化；若在 2023 年之后仍然依赖”克隆版 = 二进制一致”的假设，则需要重新评估供应链风险。

1.5 CentOS 停服对不同类型用户的差异化影响

CentOS 停服并非对所有用户都是同等严重的冲击，不同类型用户的受影响程度取决于他们在 CentOS 上构建的业务模式：

• 大型互联网公司：通常已经有定制内核、自建补丁体系，CentOS 只是一个 base。这类用户迁移成本中等，主要影响是内部发行版需要从”基于 CentOS 再定制”改为”基于 Rocky/Alma/openEuler 再定制”；
• 中小型企业的 IT 部门：依赖发行版官方生态（yum repo、EPEL、社区支持）。这类用户受影响最大，因为他们没有能力维护自己的 Linux 发行版；
• ISV 软件厂商：其软件以 RPM 形式交付并声明”支持 RHEL/CentOS”。这类用户需要重新声明支持矩阵，涉及产品管理与市场工作；
• 公有云厂商：既是用户也是供应商，其公有云镜像服务需要提供新的默认选项，并对存量客户提供迁移支持；
• 硬件 OEM 厂商：服务器出厂预装 CentOS 的厂商，需要与多家发行版协调新的 OEM 合作关系。

这种差异化影响的认识对于技术媒体在评估事件影响时有参考价值：当某些报道声称”CentOS 停服将影响数千万台服务器”时，需要分清这个影响是”需要打补丁”还是”需要重新部署”，两者的成本相差一个数量级。

二、Rocky Linux 与 AlmaLinux 的诞生

2.1 Rocky Linux

2020 年 12 月 9 日，CentOS 联合创始人之一 Gregory Kurtzer 在 CentOS 公告博客的评论区写下了一条被广泛引用的评论，表示将启动一个新的 RHEL 兼容克隆项目，以 CentOS 项目的另一位已故联合创始人 Rocky McGaugh 命名——Rocky Linux。

Rocky Enterprise Software Foundation（RESF）随后成立，Rocky Linux 项目在 2021 年 6 月发布了第一个正式版本 Rocky Linux 8.4。

协议与治理：Rocky Linux 基于 RHEL 的公开源代码构建（GPLv2 组件），托管于开放的 Git 仓库。RESF 是一个非营利机构，旨在为项目的长期独立性提供保障。

资金来源：Rocky Linux 获得了 CIQ（Computing Intelligence Quotient）公司的主要资金支持，CIQ 同时提供基于 Rocky Linux 的商业订阅服务。

Rocky Linux 项目在 2021–2022 年快速建立了完整的基础设施：独立的 Git 仓库、Koji 构建集群、镜像分发网络（CDN）、文档门户、社区论坛。这一速度之快远超大多数开源项目的初建阶段，主要得益于 Gregory Kurtzer 的号召力与 CIQ 的资金投入。到 2023 年底，Rocky Linux 的全球官方镜像站点超过 100 个，国内也有阿里、网易、清华大学 TUNA 等镜像站提供同步。

2.2 AlmaLinux

与 Rocky Linux 几乎同期，CloudLinux 公司（一家专注于 Linux 服务器安全与稳定性的商业公司）宣布资助一个名为 AlmaLinux 的 RHEL 克隆项目。第一个稳定版 AlmaLinux 8.3 于 2021 年 3 月发布，快于 Rocky Linux 几个月。

协议与治理：AlmaLinux 与 Rocky Linux 技术路线类似，均基于 RHEL 公开源码构建。AlmaLinux OS Foundation 于 2021 年成立，管理项目的独立性和社区治理。

资金来源：CloudLinux 是主要赞助方，同时也通过 AlmaLinux 生态提供商业支持服务。

2.3 两者的主要差异

从更深层的战略差异看：Rocky Linux 更强调”社区优先”，决策流程以 RESF 董事会与技术指导委员会为核心；AlmaLinux 则更早建立了与硬件厂商、云厂商的商业合作（如与 AWS、Microsoft 的合作），社区生态更加商业友好。这两种路线对于不同用户群有不同吸引力——强调长期独立性的学术、科研、非营利组织偏向 Rocky，追求商业支持网络的企业用户偏向 Alma。

在发行节奏上，两个项目在 2021–2024 年间基本保持了与 RHEL 主线大约 1–2 周的延迟（minor 版本发布后 1–2 周内对应的 Rocky / Alma 版本发布）。这一节奏在 2023 年源码政策变化后略有延长，但仍在企业可接受的范围内（4–6 周）。

2.4 2023 年后 Rocky Linux 的法律策略

2023 年 6 月 Red Hat 关闭公开 SRPM 来源后，Rocky Linux 与 AlmaLinux 面临的核心问题是：如何在不违反 Red Hat 订阅条款的前提下，继续获取构建”与 RHEL 在源码层面一致”的发行版所需的代码。Rocky Linux 给出的技术与法律组合策略，可以拆解为以下几条路径。

2.4.1 UBI（Universal Base Image）作为参考来源

UBI 是 Red Hat 官方免费发布的容器基础镜像，包含了 RHEL 的核心用户态组件。UBI 镜像本身允许自由分发（包括二进制），且其中的开源软件仍然受原许可证约束，Red Hat 必须提供对应源码。Rocky Linux 团队的解读是：

• UBI 镜像所包含的每一个 GPL 二进制，其源码都对 UBI 的”接收者”开放；
• 下载 UBI 镜像的任何人都是合法的”接收者”，因此可以要求 Red Hat 提供对应源码；
• 通过 UBI 可以覆盖 RHEL 绝大部分用户态基础软件。

这一路径不依赖 Red Hat 的付费订阅合同，也不触碰订阅条款中关于”再分发”的限制。

2.4.2 CloudLinux 订阅路径

CloudLinux（AlmaLinux 的主赞助方）本身是 Red Hat 的企业订阅客户，合法持有 RHEL 订阅并有权访问 SRPM。AlmaLinux 社区成员通过 CloudLinux 间接获得源码的解读是：CloudLinux 作为合法的 GPL “接收者”，在拿到源码后，以自由软件许可证的条款将源码进一步再分发是合法的。Red Hat 的订阅条款可能对合同续约存在限制，但不能限制 GPL 赋予接收者的再分发权利。

2.4.3 CentOS Stream 作为补充参考

CentOS Stream 是 RHEL 的上游开发分支，其代码在 RHEL 正式发布之前就已经公开。Stream 与 RHEL 并非 1:1 克隆，但大多数核心包的源码基本一致，偶尔存在补丁顺序或版本号差异。克隆版项目将 Stream 视为补充参考来源，尤其用于追踪安全更新、比对 patch 内容。

2.4.4 koji.mbox.centos.org 的构建产物

koji 是 Fedora/CentOS 使用的构建系统，其构建日志和产物在一段时期内对公开访问是开放的。Rocky Linux 与 AlmaLinux 在早期构建体系中曾大量参考 koji 输出的 SRPM 作为元数据源。

2.4.5 Rocky Linux “我们有合法 RHEL 订阅”策略的法律依据

Rocky Linux 官方在 2023 年 7 月发布的声明中明确表示：项目保留通过合法商业渠道（如 UBI 容器 + 公有云镜像中的 RHEL 实例 + 合作伙伴订阅）获取 RHEL 源代码的途径。其法律依据基于 GPLv2 Section 6：

Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions.

Rocky Linux 的解读是：一旦合法获得了 RHEL 的二进制或源码，作为 GPL 接收者即拥有独立的再分发权利，Red Hat 无法单方面通过订阅合同剥夺这一权利。Red Hat 的反制手段（如终止违反订阅条款的客户订阅）虽然是合同法上的合法行为，但不能改变 GPL 赋予接收者的上游权利。

2.4.6 AlmaLinux “ABI 兼容”目标转变的技术含义

AlmaLinux 在 2023 年 7 月宣布从”1:1 二进制兼容”调整为”ABI 兼容”。从工程角度看，这一转变的技术含义包括：

• 不再保证每个二进制的 SHA256 与 RHEL 完全一致；
• 继续保证共享库（如 glibc、libstdc++）的 ABI 版本与符号表兼容；
• 继续保证对同一 RHEL 目标版本编译的第三方 rpm 可以直接在 AlmaLinux 上安装运行；
• 在无法获取 Red Hat 源码的情况下，允许从 CentOS Stream 或其他上游来源回溯补丁；
• 修复 CVE 的时间窗口可能比 RHEL 略有滞后（取决于补丁公开的时间）。

对企业用户而言，这一变化的实际影响有限：大多数商业软件厂商（如 Oracle Database、SAP、各类 ISV）的认证列表关注的是 ABI 层面，而非二进制逐字节一致。但对于高度依赖 RHEL 严格兼容性的场景（如金融行业的合规审计要求），需要与供应商确认其支持声明是否覆盖 AlmaLinux。

三、2023 年：Red Hat 关闭 RHEL 公开源码

3.1 事件经过

2023 年 6 月 21 日，Red Hat 宣布将 RHEL 的源码包仅向付费订阅用户开放，位于 git.centos.org 的公开仓库将不再接收新的 RHEL 源代码推送。此前，RHEL 会在 git.centos.org 公开其完整的 SRPM（Source RPM），这是 Rocky Linux、AlmaLinux 等克隆版的重要来源之一。

Red Hat 的官方说法是：GPL 要求向接收者提供源码，而”接收者”是指实际使用其软件的用户，并非广泛的公众。Red Hat 认为，通过向付费订阅用户提供源码访问，已满足 GPL 的要求。

这一公告引发的连锁反应是：

• 当日 Rocky Linux 与 AlmaLinux 均发布临时声明，承诺将继续维持 RHEL 兼容的发行版；
• 6 月 23 日，SFC 发表声明批评 Red Hat 的做法；
• 7 月初，AlmaLinux 宣布转向 ABI 兼容，Oracle Linux 发表公开声明继续承诺二进制兼容；
• 7 月中旬，Oracle、SUSE、CIQ 三家公司联合宣布成立 Open Enterprise Linux Association（OpenELA），共同维护一个 RHEL 兼容的开放源代码基础。

3.2 SFC（软件自由保护组织）的立场

软件自由保护组织（Software Freedom Conservancy，SFC）就此发表声明，认为 Red Hat 的做法在法律上仍在 GPLv2 的模糊地带，但违背了 GPL 的精神。SFC 的主要论点是：GPL 的目的是保证所有用户都能获取源码，而非仅限于直接客户。

SFC 的声明明确使用了”我们认为这违反了 GPL 的精神”的措辞，而非”这违反了 GPL 的字面条款”——这一区分在法律上具有重要意义。

这种措辞的审慎反映了 SFC 组织的现实策略：直接主张 Red Hat 违反 GPL 字面条款，需要在法院通过诉讼来验证，而诉讼本身耗费巨大、结果不确定；而主张 Red Hat 违反 GPL 精神，是社区层面的道德号召，目的是动员其他开源项目表态、形成行业共识。从 2023 年 6 月到 2024 年，SFC 并未就此提起诉讼，这符合其公开声明的定位。

3.3 Rocky Linux 和 AlmaLinux 的技术应对

面对 RHEL 源码不再公开的局面，两个克隆项目采取了不同策略：

Rocky Linux 的应对：

Rocky Linux 宣布将继续以 RHEL ABI 兼容为目标，转向使用 Red Hat 的 UBI（Universal Base Image）容器镜像作为参考，以及使用其他来源（如 CentOS Stream、付费 RHEL 订阅后获取的 SRPM）。Rocky Linux 表示，由于 Koji（Red Hat 的构建系统）的工件中仍有部分可参考内容，将继续维持兼容性。

AlmaLinux 的应对：

AlmaLinux 在 2023 年 7 月宣布，将放弃”与 RHEL 1:1 二进制兼容”的目标，转向”与 RHEL ABI 兼容”。这一调整的实际含义是：大多数应用程序在 AlmaLinux 上可以无缝运行，但不再保证每一个二进制文件的校验和都与 RHEL 完全一致。此外，AlmaLinux 与 CloudLinux 共享了部分从 CloudLinux 商业版获取 RHEL 源码的路径。

3.4 Oracle Linux 的立场

Oracle Linux 是另一个历史悠久的 RHEL 兼容发行版，在这次事件中选择了与 Rocky / Alma 不同的立场。Oracle 在 2023 年 7 月发布声明，明确表示将继续发布与 RHEL 二进制兼容的 Oracle Linux，并公开了从 Oracle 自身订阅所获取的 SRPM。Oracle 的官方博客直接批评了 Red Hat 的新政策。

从企业用户的角度看，Oracle Linux 在 2023 年之后实际上成为了”获取 RHEL 源码的合法第三方渠道”之一，尽管 Oracle Linux 本身带有 Oracle 的商业商标与支持体系。这为 Rocky / AlmaLinux 在技术上交叉验证补丁提供了一个参考源。

3.5 社区舆论走向

2023 年 6 月至 2023 年 9 月之间，开源社区对 Red Hat 政策变化的讨论集中在几个焦点：

• Red Hat 的做法是否违反 GPL 的字面条款？多数法律意见认为没有明确违反，但存在解释空间；
• Red Hat 的做法是否违反 GPL 的精神？SFC 与 Bradley Kuhn（著名自由软件倡导者）明确表示违反；
• IBM 收购 Red Hat 对开源贡献的长期影响？批评者认为商业压力正在侵蚀 Red Hat 原有的开源承诺；
• 企业用户应如何应对？大多数分析建议评估迁移成本，但不建议仓促切换。

值得关注的是，Red Hat 在事件后并未进一步收紧政策，也没有对克隆版项目采取法律行动。这个”边界明确但不扩张”的状态成为了 2024 年之后的行业默认预期。

四、中国的 RHEL 生态替代方案

4.1 openEuler

openEuler 由华为于 2019 年 12 月开源，最初基于华为内部使用的 EulerOS（基于 CentOS 7）演化。2021 年 11 月，华为将 openEuler 捐赠给开放原子开源基金会（OpenAtom Foundation）。

技术路线：

• 内核：Linux 内核，长期支持版本（LTS），openEuler 社区维护独立的内核分支，针对 ARM 架构（鲲鹏）和 x86 进行了优化
• 默认包管理：rpm/yum（与 RHEL 系兼容）
• 许可证主体：GPLv2（Linux 内核）；openEuler 自有组件采用 Mulan PSL v2 或 Apache 2.0

与 CentOS/RHEL 的兼容性：openEuler 22.03 LTS 系列提供了与 CentOS 7 应用的较好兼容性，但不是 RHEL 的”1:1 克隆”，存在差异，需要应用层适配。

生态现状：openEuler 已被多家国产服务器厂商（华为、超聚变、新华三等）作为预装系统，在政企信创场景中占有重要地位。华为推出了基于 openEuler 的商业发行版 HarmonyOS for Server（HCE，旧称 EulerOS）。

发行节奏：openEuler 采用”LTS + 创新版”双轨模式，LTS 版本每两年一次（22.03 LTS、24.03 LTS），生命周期 4 年；创新版每半年一次，生命周期 6 个月。企业用户应选择 LTS 版本，并关注 SPx 系列的小版本升级时间表。

4.2 龙蜥 Anolis OS

Anolis OS（龙蜥操作系统）由阿里云于 2020 年 10 月开源，2021 年捐赠给开放原子开源基金会。龙蜥社区（OpenAnolis）在多家企业参与下运营。

技术路线：

• 与 CentOS 8、RHEL 8 保持高度二进制兼容，并扩展支持 CentOS 8 停服后的安全更新
• 许可证主体：GPLv2（内核）；龙蜥自有组件遵循 MulanPSL-2.0 或 Apache 2.0
• 支持 x86_64、ARM64、RISC-V 架构

与 RHEL 的定位差异：Anolis OS 明确将”RHEL 兼容性”和”云原生优化”作为核心目标，与在阿里云 ECS 上的工作负载迁移需求高度契合。

版本演进：Anolis OS 提供 7（CentOS 7 兼容）与 8（RHEL 8 兼容）两个主要分支，并在 2023 年推出了 Anolis OS 23（面向云原生与 AI 工作负载的创新版本，类似 Fedora 在 RHEL 上游的定位）。对于从 CentOS 迁移的用户，推荐优先考虑 Anolis OS 8 以最小化应用层调整。

4.3 TencentOS Server

TencentOS Server（腾讯服务器操作系统，前称 Tencent Linux、TLinux）由腾讯基于 CentOS 内核演化，针对腾讯云基础设施进行了优化。目前主要用于腾讯云内部及其公有云产品。

TencentOS Server 2.4 及以后版本在 GitHub 开源（github.com/Tencent/TencentOS-kernel），许可证为 GPLv2。主要特性包括针对高密度混部场景的内核优化、腾讯自研的网络和存储驱动。

TencentOS Server 3 系列在 2022 年后基于 CentOS 8 演化，支持 ARM64 架构，默认提供与 RHEL 8 的 RPM 兼容。与 Anolis OS 类似，TencentOS Server 3 可以直接安装针对 RHEL 8 / CentOS 8 构建的第三方 RPM 包，这降低了从 CentOS 8 迁移的工程成本。

在内核定制方面，TencentOS Server 引入了诸多针对云场景的优化：CPU 调度器的 in-place 调整、内存子系统的 QoS 支持、网络栈对 VPC 的加速路径、针对容器场景的 cgroup v2 增强等。这些特性对腾讯云 CVM 实例有直接收益，但对非腾讯云环境的收益较有限。

4.4 统信 UOS Server

统信 UOS Server（统信软件的服务器版）基于 Debian 路线（而非 RHEL 路线），主要面向政企信创合规场景。在服务器 Linux 生态中，统信的 rpm/yum 兼容性较弱，更适合从零迁移的信创项目而非从 CentOS 迁移的改造项目。

4.5 麒麟 Kylin Server

麒麟软件的 Kylin Server（银河麒麟服务器操作系统）是国内信创领域的重要成员。其技术路线与统信有差异：Kylin Server V10 提供了基于 CentOS 8 演化的 SP2/SP3 版本，包管理上与 RHEL 系兼容，适合作为 CentOS 7 / 8 的信创方向替代。

Kylin Server 的主要用户为党政、金融、电信、能源等关键行业，具有完整的等保、密评、信创认证资质链。从企业迁移的可行性角度看，Kylin Server 是 openEuler 之外最主流的信创 RHEL 兼容方向。

4.6 国内替代发行版生态地图

从 2021 到 2024 年，国内 RHEL 兼容方向的发行版已经形成了多层次的生态结构：

• 基础版（社区、开源、可自由使用）：openEuler 社区版、Anolis OS 社区版、TencentOS Server 开源版；
• 商业版（厂商提供商业支持）：HCE（华为）、欧拉商业版（多家厂商）、Kylin Server（麒麟软件）、统信 UOS Server（统信软件）；
• 云厂商版本（绑定云基础设施）：阿里云 Alibaba Cloud Linux、腾讯云 TencentOS Server for CVM、华为云 HCE；
• 边缘/嵌入式版本：openEuler Embedded、openEuler Edge。

这一多层次生态的存在意味着，CentOS 停服在国内并未导致供给不足的问题，反而推动了本土发行版生态的加速成熟。

从行业数据看，根据赛迪顾问发布的《2023 中国服务器操作系统市场研究报告》等公开数据，openEuler 与龙蜥在 2023 年合计占据国内服务器 Linux 市场约 30% 以上的新增份额。这一增长速度在历史上没有先例，反映了 CentOS 停服+信创政策的双重驱动。

对架构师而言，这种生态多样性既是机会也是负担——选型空间扩大，但需要做更细致的评估与对比。建议对每个候选方向都做一次 POC，用实际工作负载而非市场宣传材料做判断依据。

五、中国替代发行版技术深度对比

前一节按发行版梳理了基本情况，本节从横向角度做技术深度对比，帮助架构师在具体场景下做选型判断。下文所有版本号均以 2024 年公开可查的主线版本为准。

5.1 内核版本与包管理对比表

下表横向对比五个主流候选发行版的技术基线。选型判断应同时考虑内核版本（影响容器特性、硬件支持）、上游基线（影响包兼容性）与架构覆盖（影响硬件选型空间）。

几点值得注意的差异：

• 内核版本差异直接影响容器特性可用性。例如 cgroup v2 在 Linux 5.8+ 默认可用，eBPF 的部分高级特性需要 5.10+，Landlock LSM 需要 5.13+。使用 Kubernetes 1.28+ 并启用 cgroup v2 的团队，应选择内核 5.10 及以上的发行版。
• RISC-V 仅在 openEuler 中有正式生产支持。对于国产 RISC-V 服务器项目，openEuler 是目前覆盖最完整的选择。
• Rocky/Alma 保留了对 s390x（IBM Z）和 ppc64le 的支持，这与上游 RHEL 保持一致，对跨平台部署的金融客户有意义。

5.2 许可证与治理对比

下表比较五个发行版在许可证与治理结构上的差异。许可证决定”衍生品能否商用”的边界，治理结构决定”项目能否长期独立存在”。

治理差异对企业用户的实际影响：

• 有独立基金会治理（openEuler、龙蜥、Rocky、Alma）意味着即便主要赞助方撤出，项目法律实体仍然存在，社区可以接管代码库与商标；
• 无独立基金会（TencentOS Server）意味着项目完全依赖赞助公司的战略，风险类似于 CentOS 在 IBM 收购后的情形；
• Mulan PSL v2 是木兰公共许可证第 2 版，兼容 Apache 2.0 / GPLv3，但与 GPLv2 的兼容性需要具体评估——将 Mulan PSL v2 组件与 GPLv2 代码链接时需谨慎。

5.3 生态兼容性细节

5.3.1 openEuler 与 CentOS 7 的差异

openEuler 虽然最早从 CentOS 7 演化而来，但在 22.03 LTS 版本中已经进行了大量组件升级，导致与 CentOS 7 的 RPM 包不完全二进制兼容。关键差异包括：

• glibc 版本：CentOS 7 为 glibc 2.17，openEuler 22.03 为 glibc 2.34。在 CentOS 7 上静态链接 glibc 特定符号的二进制，在 openEuler 上需要重新编译；
• Python 版本：CentOS 7 默认 Python 2.7，openEuler 22.03 默认 Python 3.9，且不再提供 Python 2 运行时；
• OpenSSL 版本：CentOS 7 为 OpenSSL 1.0.2，openEuler 22.03 为 OpenSSL 1.1.1 或 3.0，API 与 ABI 均有变化。

对于依赖这三类库的应用，从 CentOS 7 迁移到 openEuler 本质上是跨大版本升级，而非简单切换发行版。

5.3.2 龙蜥与 CentOS 8 / RHEL 8 的兼容策略

龙蜥 Anolis OS 8 明确声称”与 RHEL 8 二进制兼容”。在工程实测中，针对 RHEL 8 / CentOS 8 构建的第三方 RPM 包（例如 Oracle Database 19c 的 RHEL 8 版本）可以直接在 Anolis OS 8 上安装。龙蜥的内核经过定制，包含阿里云为自身工作负载引入的补丁（如针对 RDMA、SPDK 的优化），但保留了 RHEL 8 用户态 ABI。

对于希望继续使用 RHEL 8 生态但又不想直接依赖 Red Hat 或海外克隆版的团队，Anolis OS 8 是工程上迁移成本最低的选项。

5.3.3 TencentOS 的内核定制项

TencentOS Server 3 的内核在 5.4 LTS 基础上合入了腾讯自研的多项特性，对云原生工作负载有实际意义：

• cgroup v2 完整支持：在 5.4 内核中回移了 5.8+ 的部分 cgroup v2 特性；
• BPF 增强：为云原生观测（如 BCC、bpftrace）提供更完整的 hook 点；
• 高密度混部内核特性：支持在线离线业务混合部署的 CPU 调度隔离，对云厂商是核心差异点；
• 网络性能优化：针对 VPC、ENI 的路径做了内核态 fast path 优化。

对于主要工作负载运行在腾讯云上的客户，TencentOS Server 3 能带来可测量的性能提升；对于运行在其他云或裸金属上的客户，这些定制特性的收益会显著减少。

5.4 云厂商替代镜像策略

各主流云厂商在 CentOS 停服后，都提供了官方推荐的替代镜像。下表汇总了当前（2024 年）各云平台的默认推荐：

在云环境中做选型，除了发行版技术本身，还需要考虑：

• 镜像更新速度：云厂商官方推荐镜像通常提供更快的补丁回滚机制；
• 与云服务集成度：如阿里云的 CloudMonitor Agent、腾讯云的 BarAd 安全组件，只在官方镜像上默认预装；
• 计费与支持：部分云厂商对官方镜像提供免费商业支持，对第三方镜像需单独购买；
• 镜像安全扫描：合规场景下，云厂商对自家镜像的漏洞响应 SLA 通常更好。

5.4.1 阿里云的 CentOS 替代策略

阿里云在 2021 年 CentOS 8 停服后，首先推出了 Alibaba Cloud Linux 2（基于 CentOS 7.x，长期支持）与 Alibaba Cloud Linux 3（基于 CentOS 8，与 Anolis OS 8 技术基线一致）作为官方推荐镜像。2022 年后，阿里云将重心转向 Anolis OS 社区版，并在控制台明确推荐 Anolis OS 作为 CentOS 替代。

从客户侧视角，阿里云的迁移路径是：CentOS 7 → Alibaba Cloud Linux 2（延长寿命）→ Anolis OS 8 / 23（新业务）。对运行在阿里云 ECS 上的现有 CentOS 实例，阿里云提供了操作系统原地更换（OS in-place replacement）能力，降低了迁移复杂度。

5.4.2 腾讯云的 CentOS 替代策略

腾讯云的路径与阿里云类似：CVM 控制台默认推荐 TencentOS Server 3，并对老客户提供延长 CentOS 7 维护支持（直到 2024 年 6 月 30 日上游 EOL 之后数月）。腾讯云还推出了 TencentOS Server 免费版与商业版的区分，在 SLA 响应时间、补丁更新频率上有差异。

5.4.3 华为云的 CentOS 替代策略

华为云力推 HCE（HarmonyOS for Server，前称 EulerOS），作为基于 openEuler 的商业化发行版。HCE 的特点是与华为鲲鹏芯片深度协同，并内置了针对华为云基础设施的优化。对于不使用鲲鹏架构的 x86 客户，华为云也提供了 openEuler 社区版与其他第三方镜像。

六、企业迁移工具与脚本

6.1 官方迁移脚本概述

从 CentOS 迁移到替代发行版，有两种主流路径：in-place 原地迁移（替换 repo、逐步切换 RPM 数据库）与 reinstall 重装迁移（备份数据、重装系统、还原应用）。各主要发行版提供的官方工具如下：

• migrate2rocky：由 Rocky Linux 官方维护，支持从 CentOS 8 / CentOS Stream 8 / Oracle Linux 8 / AlmaLinux 8 迁移到 Rocky Linux 8。9.x 系列有对应的 migrate2rocky9.sh；
• almalinux-deploy.sh：AlmaLinux 官方维护，支持从 CentOS 8 / RHEL 8 / Oracle Linux 8 / Rocky Linux 8 迁移到 AlmaLinux 8。AlmaLinux 9 有对应的 almalinux-deploy 更新分支；
• 龙蜥迁移工具：openAnolis 社区提供 centos2anolis.py 与配套文档，支持从 CentOS 7 / CentOS 8 迁移到 Anolis OS 7 / 8；
• openEuler 迁移：不提供一键原地迁移脚本，官方建议重装迁移。

6.2 migrate2rocky 使用示例

以下示例展示了从 CentOS 8 到 Rocky Linux 8 的原地迁移完整流程。执行前务必先做系统快照（虚拟机）或全盘备份。

# 从 CentOS 8 迁移到 Rocky Linux 8
# 1. 下载迁移脚本
curl -O https://raw.githubusercontent.com/rocky-linux/rocky-tools/main/migrate2rocky/migrate2rocky.sh
chmod +x migrate2rocky.sh

# 2. 运行迁移（需要 root 权限）
sudo ./migrate2rocky.sh -r

# 3. 迁移完成后重启
sudo reboot

# 4. 验证
cat /etc/rocky-release
rpm -qa | grep rocky

脚本执行过程大致分几个阶段：校验当前系统来源、禁用原仓库、替换 GPG 密钥、安装 rocky-release 等核心包、更新所有包、重新生成 initramfs。典型时长在 10–30 分钟，取决于已安装包的数量与网络速度。

-r 参数表示执行实际替换（默认是只做检查的 dry-run）。如果只想先体检系统是否可以迁移，不带参数运行即可查看报告。

6.3 AlmaLinux 迁移示例

# 从 CentOS 8 迁移到 AlmaLinux 8
curl -O https://raw.githubusercontent.com/AlmaLinux/almalinux-deploy/master/almalinux-deploy.sh
chmod +x almalinux-deploy.sh
sudo ./almalinux-deploy.sh
sudo reboot
cat /etc/almalinux-release

almalinux-deploy.sh 在内部逻辑上与 migrate2rocky 类似，但在执行细节上有几点差异：

• 默认会先进行环境检查（内核版本、磁盘空间、网络连接），不通过则直接退出；
• 对已经订阅 Red Hat 的 RHEL 系统，需要先取消订阅再迁移；
• 对 Oracle Linux 的 UEK 内核，会替换为 RHEL 兼容的内核，但不会自动卸载 UEK 内核（建议手动清理）。

6.4 CentOS 7 到 openEuler 的迁移注意事项

openEuler 不提供官方的一键原地迁移脚本，原因是 openEuler 的技术基线与 CentOS 7 差异过大（glibc、Python、OpenSSL 都是跨大版本）。官方建议的路径是重装迁移，关键步骤：

1. 全量备份：对 /etc、/home、/var/lib（数据库数据目录）、/opt（第三方软件）及应用自定义目录进行备份；
2. 清点依赖：列出所有手动安装的 RPM 包与第三方仓库（yum list installed | grep -v @anaconda）；
3. 应用侧准备：
   • Python 2 脚本需要迁移到 Python 3，或者从 EPEL 安装 python2 兼容包；
   • 依赖 OpenSSL 1.0.2 API 的 C/C++ 程序需要重新编译，针对 OpenSSL 1.1 的新 API；
   • 依赖 glibc 特定符号版本（如 memcpy@GLIBC_2.14）的静态链接二进制可直接运行，但依赖旧版符号的动态链接二进制需要重建；
4. 重装 openEuler：建议使用 22.03 LTS SP3 或更新版；
5. 恢复数据与配置：数据库数据目录应先离线验证兼容性（例如 PostgreSQL 12 → 15 需要 pg_upgrade）；
6. 验证功能：完整回归测试后再切换生产流量。

对迁移窗口紧张的团队，可以考虑”先迁移到 Anolis OS 7”（与 CentOS 7 高度兼容，有原地迁移工具），待应用层完成 Python 3 与 OpenSSL 升级后，再规划到 openEuler 的跨大版本升级。

6.5 迁移前健康检查清单

无论选择哪个目标发行版，迁移前应完成以下检查。这份清单基于多个团队在实际迁移项目中遇到的问题整理。

• 内核模块兼容性：检查是否使用了非主线内核模块（如 NVIDIA 闭源驱动、Mellanox OFED、企业存储厂商的 multipath 驱动），确认目标发行版是否有对应版本；
• 第三方 RPM 仓库可用性：梳理所有 /etc/yum.repos.d/ 下的第三方 repo（EPEL、Remi、ELRepo、Oracle、Zabbix、Docker CE 等），确认其在目标发行版有对应版本；
• Python 版本依赖：列出所有依赖 Python 2.7 的运维脚本、监控 agent、第三方工具；
• systemd 服务文件：检查自定义的 .service 文件是否使用了在新版 systemd 中废弃或变更的指令；
• SELinux 策略：自定义 SELinux 策略模块（.pp 文件）需要在目标发行版重新编译并加载；
• 内核参数：/etc/sysctl.conf、/etc/sysctl.d/ 下的调优参数，在新内核下的语义是否保持一致；
• firewalld / iptables：确认目标发行版的防火墙后端（RHEL 8/9 默认 nftables）与现有规则兼容；
• cgroup 版本：如果使用 Docker 或 Kubernetes，确认运行时与目标发行版默认 cgroup 版本（v1/v2）是否匹配；
• 时区与时间同步：chronyd 与 ntpd 在不同发行版的默认行为；
• 日志系统：rsyslog 配置、journald 持久化配置；
• 商业软件认证列表：与 Oracle、SAP、达梦、OceanBase 等商业数据库厂商确认其支持矩阵是否包含目标发行版。

建议将这份清单做成团队内部的评审模板，每台服务器迁移前完成对应检查并存档。

6.6 典型迁移案例的时间预算

不同规模、不同复杂度的迁移项目，时间预算差异显著。以下数字基于公开分享的企业迁移项目整理，仅供参考：

• 小型 Web 服务器（单台，标准 LAMP 栈）：原地迁移 1–2 小时，含测试验证；
• 中型业务系统（10–50 台，含数据库与中间件）：分批重装迁移 2–4 周，含 POC 与回归测试；
• 大型核心系统（100+ 台，跨多个业务域）：完整迁移项目 6–12 个月，含立项、POC、灰度、全量、收尾；
• 跨大版本 + 跨发行版（CentOS 7 → openEuler 22.03）：应用层改造是主要时间消耗，典型项目 6 个月以上。

时间预算中常被低估的部分包括：

• 第三方软件厂商的适配承诺：商业软件厂商的支持列表更新需要时间，不能假设所有 ISV 都能立即支持新发行版；
• 合规审批流程：等保测评、密评、信创审批对新发行版的重新认证流程可能持续数月；
• 运维人员培训：新发行版的默认行为差异（如 firewalld 配置语法、SELinux 策略管理）需要运维团队培训；
• 回滚预案演练：每批迁移前演练回滚流程，至少占总项目时间的 10–15%。

一个常见的建议是：在项目立项时，按技术评估结果预留 1.5–2 倍的时间 buffer，以应对预期外的问题。

七、GPL 合规分析：RHEL 源码政策的法律边界

7.1 Red Hat 对 GPL 的解释

Red Hat 的官方立场是：GPL 要求将源码提供给”接受者（recipient）“，而付费订阅用户即为合法接受者，对这些用户公开源码满足了 GPL 的要求。

GPLv2 原文（Section 3）规定，以二进制形式分发时，必须”附带完整的机器可读的源码，或者附上以书面形式提供源码的要约（written offer），要约在实物媒体上发布，需在商业上合理的时间内提供”。

Red Hat 的解释：付费用户是”接受者”，向他们开放源码（通过订阅门户）满足了此要求；而免费的公众并非其软件的”接受者”。

从 Red Hat 的商业逻辑角度，这一立场还带有经济合理性的论证：CentOS 克隆版在相当长时期内承担了 RHEL 的”免费版”功能，企业可以用 CentOS 获得完整的 RHEL 技术栈，只在需要正式支持时才付费。这种结构让 Red Hat 的研发投入被下游克隆版”搭便车”。Red Hat 认为，将免费源码访问权限制在付费用户群，是对贡献与收益失衡的合理修正。

GPLv2 Section 6 还规定：“你不能对接收者行使所授予权利进一步施加限制（You may not impose any further restrictions on the recipients’ exercise of the rights granted herein）”。Red Hat 的订阅条款中关于”违反再分发规则可能导致订阅终止”的约定，是否构成”进一步的限制”，是法律解释的核心争点。Red Hat 认为这是合同权利而非对 GPL 的限制，合同法允许基于业务原因终止合同；批评者认为这是以商业威胁阻止合法的 GPL 行为，实质上构成限制。

7.2 SFC 与社区的反驳

批评者认为，Red Hat 的解释在逻辑上存在问题：

1. GPL 的设计初衷是保证软件流通过程中每个环节的接受者都能获取源码，形成”自由软件的永久流动”；
2. 如果仅向付费用户提供源码，而付费用户无权再分发给第三方，则源码的可得性实质上被隐性限制；
3. CentOS 克隆版的存在本身依赖于 RHEL 源码的公开可得性，关闭这一渠道实质上影响了下游的 GPL 权利行使。

从法律实践角度，目前尚无法院就此作出明确判决，这一争议处于”GPL 合规的灰色地带”。工程团队在评估此风险时，应关注 SFC 后续的法律行动（如有）以及 Red Hat 是否进一步收紧源码访问政策。

SFC 在其 2023 年 6 月 23 日的博客文章《Understanding Red Hat’s Recent Decision to Limit Rebuilders’ Access to RHEL Source Code》中还进一步指出几个关键点：

• GPL 从未区分”接收者”的商业地位：只要某方合法获得二进制，即享有获取源码的权利，与其是否付费无关；
• 订阅条款不能变更 GPL 授予的权利：即便 Red Hat 对订阅方终止服务，GPL 已授予的权利不会随订阅终止而消失；
• 集体维护的必要性：自由软件生态依赖多方的交叉验证与审查，削弱源码的可得性会弱化整个生态的安全性评估能力。

Bradley Kuhn 在多个技术论坛的公开讨论中强调：这不是法律合规问题，而是商业模式与自由软件哲学的冲突。Red Hat 作为长期的开源领导者，其选择会对整个行业形成示范效应。

7.3 对企业用户的影响

对于依赖 RHEL 的企业用户，这一政策变化的实际影响是：

• 付费 RHEL 订阅用户：源码访问不受影响，依然可以通过 RHSM（Red Hat Subscription Manager）访问 SRPM；
• CentOS Stream 用户：CentOS Stream 仍然公开，可访问 Stream 对应的源码（非 RHEL 发行版源码）；
• 克隆版用户（Rocky/Alma）：需要适应克隆版维护方采用的新构建策略，稳定性可能略有下降；
• 国内用户：如依赖 RHEL 兼容性，建议评估迁移至 openEuler 或 Anolis OS 的成本，尤其是在 x86 之外的国产 ARM 架构场景。

7.4 历史类比：Unix 厂商与 BSD 的关系

Red Hat 源码政策的调整并非软件业首次。历史上 AT&T 对 Unix 源码的政策紧缩催生了 BSD 的演化路径，最终演化出自由可再分发的 FreeBSD / NetBSD / OpenBSD 生态。类比视角下：

• AT&T Unix ↔︎ RHEL（原始商业版本，带源码访问约束）；
• 加州伯克利 BSD ↔︎ CentOS（早期基于 Unix 源码的自由再编译版本）；
• FreeBSD / NetBSD / OpenBSD ↔︎ Rocky / Alma / openEuler（脱离原始上游后自主维护的继承者）。

从这条历史线可以看出一个规律：上游商业公司收紧源码政策，短期会打乱下游项目的节奏，但长期会促成下游项目真正独立化。Rocky / AlmaLinux 在 2023 年之后的发展方向，与 BSD 家族在 1990 年代的分化演化路径有相当的可比性。

7.5 克隆版的可持续性评估

对企业用户来说，更实际的问题是：克隆版项目本身是否可持续？下面几个观察点值得关注：

• 基金会治理结构：RESF 与 AlmaLinux OS Foundation 均为 501(c)(6) 非营利组织，避免了单一公司控制；
• 多元化赞助：AlmaLinux 已经吸纳了 AWS、Microsoft、Cisco 等多家大厂的赞助；Rocky Linux 除 CIQ 外也有企业客户直接支持；
• 构建基础设施独立性：两个项目均建立了独立的 Koji 构建集群，不再依赖 Red Hat 基础设施；
• 社区活跃度：GitHub 上的 commit 频率、issue 响应时间、mailing list 活跃度均保持在合理水平。

综合来看，2024 年的 Rocky Linux 与 AlmaLinux 相比 2021 年刚诞生时已经成熟得多，商业级使用的信心可以建立在基金会治理与多元赞助的基础上。

7.6 OpenELA 的出现及其影响

2023 年 8 月，Oracle、SUSE、CIQ 三家公司宣布共同发起 Open Enterprise Linux Association（OpenELA），目的是为 RHEL 兼容发行版生态提供一个厂商中立的源代码托管与协作平台。OpenELA 的意义在于：

• 为 Rocky Linux、AlmaLinux 等项目提供了一个独立于 Red Hat 的 RHEL 源代码获取渠道；
• 提供跨厂商的补丁协调平台，减少重复劳动；
• 建立了一个新的治理实体，代表”非 Red Hat 的 RHEL 兼容生态”发声。

OpenELA 的长期影响尚待观察，但其成立本身已经证明：行业对 Red Hat 的源码政策调整的反制在 2023 年进入了组织化阶段。对企业用户而言，这是一个积极信号，表明 RHEL 兼容生态的长期供给不依赖单一项目。

八、企业迁移决策框架

8.1 迁移目标系统的选择判据

从 CentOS（尤其是 CentOS 7/8）迁移时，以下维度是主要决策因素：

8.2 工程迁移的主要风险点

软件包兼容性：CentOS 7 基于 RHEL 7（glibc 2.17）；迁移至 RHEL 8 系（Rocky/Alma/openEuler 22.03）涉及 glibc 2.28+ 的变更，可能影响老旧 C/C++ 二进制应用的运行。

Python 版本：CentOS 7 默认 Python 2.7，Rocky/Alma 8 默认 Python 3.6，openEuler 22.03 默认 Python 3.x。依赖 Python 2 的应用需要提前迁移。

systemd 版本差异：从 CentOS 7（systemd 219）到 RHEL 8 系（systemd 239+）有重大变化，init 脚本和服务配置可能需要更新。

SELinux 策略：跨主版本迁移时，SELinux 策略可能有差异，需要重新测试和调整。

内核参数与模块：内核从 3.10（CentOS 7）升级至 5.14+（Rocky 9/Alma 9/openEuler 22.03）可能影响驱动程序、cgroup v2 行为、网络栈配置等。

8.3 合规与许可证的迁移注意事项

所有上述替代方案均基于 Linux 内核（GPLv2）和 GNU 工具链（GPLv3），迁移本身不产生新的许可证义务。

需要注意的是：

• 使用 RHEL 付费订阅功能（如 Insights、RHSM 高级功能）的企业在迁移至克隆版后将失去这些功能，需要评估替代方案；
• 使用 Red Hat 商业软件（如 OpenShift、Satellite）的企业需要与 Red Hat 确认许可证条款是否允许在克隆版上运行；
• openEuler 和 Anolis OS 包含了部分以 Mulan PSL v2 授权的自研组件，与 GPL 的兼容性在中国法律框架下有特定解释，详见本系列第 09 篇。

8.4 迁移路径的典型模式

在多个企业迁移项目的观察中，可以归纳出几种常见的迁移路径模式，供架构师参考：

模式 A：就地升级（in-place upgrade）

• 适用场景：CentOS 8 → Rocky Linux 8 / AlmaLinux 8，系统架构不变、内核大版本不变；
• 优势：停机时间短（仅一次重启），应用无需重新部署；
• 风险：迁移脚本在极端情况下可能导致 RPM 数据库损坏，必须先做快照；
• 工具：migrate2rocky.sh、almalinux-deploy.sh。

模式 B：同架构跨主版本升级

• 适用场景：CentOS 7 → Rocky 9 / AlmaLinux 9；
• 实施方式：建议先迁移到 CentOS 7 → Rocky 8 / Alma 8（不存在官方原地脚本，通常重装），再从 8 升级到 9（使用 leapp 工具链）；
• 风险：glibc、Python、OpenSSL 三个基础依赖同时跨版本升级，应用侧工作量大；
• 推荐：直接重装到目标版本，而非分两步。

模式 C：跨发行版迁移

• 适用场景：CentOS 7 → openEuler 22.03 / Anolis OS 8 等；
• 实施方式：重装 + 应用重新部署；
• 风险：需要完整回归测试，时间窗口长；
• 建议：结合基础设施升级（如替换硬件、迁移至云）一起进行，效益最高。

模式 D：上云替换

• 适用场景：原 CentOS 服务器托管在自建机房，借迁移契机上云；
• 实施方式：直接选择云厂商的官方推荐镜像（如阿里云 Anolis OS、腾讯云 TencentOS），应用以容器或虚拟机形式重新部署；
• 优势：发行版选型与云资源规划合并，整体 ROI 高；
• 风险：涉及网络、存储、安全组等多维度调整，项目复杂度高于单纯的操作系统迁移。

模式 E：容器化隔离

• 适用场景：应用已经或可以容器化；
• 实施方式：保持宿主机运行 CentOS（直到 EOL），应用以容器形式部署在不同基础镜像上，等宿主机 EOL 再替换；
• 优势：迁移风险分解为”容器化”和”宿主机替换”两个独立阶段，每个阶段的风险可控；
• 适用性：受应用架构限制，非所有应用可容器化。

九、工程坑点

9.1 CentOS Stream 与稳定版的本质差异

许多团队将 CentOS Stream 视为 CentOS 稳定版的替代，这是一个常见误解。Stream 是一个滚动发布版本，内核、系统库、工具链会持续更新。其稳定性目标是”保证每次更新不破坏已知 API”，而非”冻结某一功能集合直到 EOL”。

对于生产环境中的数据库服务器、核心网络设备这类对稳定性要求极高的场景，CentOS Stream 不是合适的选择。

从工程实践角度可以这样理解：CentOS 8 的升级策略是”在同一大版本内只接收修复性补丁，minor 版本升级经过 Red Hat QE 团队验证”；CentOS Stream 的升级策略是”紧跟 RHEL 上游开发主线，新特性先在 Stream 合入再进入 RHEL”。前者是 Linux 发行版常见的 LTS 模式，后者则更接近 Fedora 的滚动形态，对业务系统的兼容性验证工作量是显著不同的。

此外，CentOS Stream 的 EOL 策略也不同：Stream 仅维护与当前 RHEL 主要版本对应的一个分支，当下一个 RHEL 主要版本发布后，上一个 Stream 会在较短时间内停止维护。相比之下，CentOS 稳定版（历史上）会跟随 RHEL 生命周期维护 10 年。

9.2 Rocky/Alma 版本与 RHEL 的细微差异

Rocky Linux 和 AlmaLinux 在 2023 年之后的版本中，与 RHEL 的二进制一致性不再是 100%。在以下场景中可能遇到问题：

• 使用 RHEL 认证（Certified）的第三方商业软件（如 Oracle DB、SAP HANA）时，厂商可能不支持在 Rocky/Alma 上运行；
• 使用 Red Hat 的 Container Security Certification 工具时，镜像签名验证可能失败；
• 某些依赖 RHEL 专有包（如 redhat-release）的部署脚本需要适配。

实际工程中的”细微差异”还包括：

• /etc/os-release 的 ID、PRETTY_NAME 字段不同，部署脚本若基于字符串匹配则需要调整；
• GPG 签名 key 不同，yum/dnf repo 配置中的 gpgkey 需要替换；
• 某些 SELinux 策略文件在包名中带有 redhat 前缀（如 selinux-policy-targeted），在 Rocky/Alma 中保持了原包名，但在 openEuler / 龙蜥中改为项目前缀；
• 订阅管理器 subscription-manager 在 Rocky/Alma 中不可用，自动化工具（如 Ansible 的 redhat_subscription 模块）需要调整。

9.3 openEuler 的 ARM 优先性与 x86 兼容问题

openEuler 最初针对华为鲲鹏（ARMv8.2）平台优化，在 x86 上的兼容性整体良好，但部分硬件驱动（尤其是新型号的 Intel 网卡、显卡）在早期版本中可能有延迟。建议在实际环境中进行充分的兼容性测试，而非直接参照 RHEL/CentOS 的硬件支持列表。

其他 openEuler 特定的工程坑点包括：

• 软件仓库镜像源：openEuler 的默认仓库地址在境外访问速度有限，生产环境建议配置国内镜像源（如阿里、华为云镜像）；
• EPEL 等第三方仓库不可直接复用：EPEL 8 的包可以在 openEuler 22.03 上安装，但依赖解析偶尔会冲突，需要使用 --skip-broken 或手动选择包；
• Java 生态差异：openEuler 默认 OpenJDK 来自 BiSheng JDK（华为毕昇 JDK），在 GC 参数、JFR 行为上与 OpenJDK 社区版略有差异；
• 时间同步：默认时间同步服务在部分 openEuler 版本中切换为 chrony，与 CentOS 7 的 ntpd 配置不兼容，迁移时需要重写配置文件。

9.4 迁移过程中的 SELinux 状态陷阱

SELinux 是从 CentOS 迁移到替代发行版中最容易出问题的部分。实际案例中常见的陷阱：

• 策略版本不一致：自定义策略模块（.pp 文件）绑定了特定 selinux-policy 版本，目标发行版的策略版本可能更新，导致加载失败；
• 文件上下文丢失：跨系统恢复备份时，restorecon 如果未执行，会导致服务启动被 SELinux 拦截；
• enforcing → permissive 的误操作：部分团队在遇到 AVC 拒绝时直接将 SELinux 改为 permissive，这会在合规审计中造成问题，正确做法是使用 audit2allow 生成自定义策略。

建议迁移过程中记录完整的 /var/log/audit/audit.log，迁移后首次运行业务时密切观察 AVC 日志。

9.5 内核 ABI 与第三方内核模块

对于使用闭源内核模块（如 NVIDIA GPU 驱动、部分企业存储厂商的 multipath 驱动、商业负载均衡卡驱动）的场景，内核 ABI 的差异会直接导致模块无法加载。关键点：

• RHEL 官方提供 kABI 稳定性承诺，在同一主要版本内保持内核 ABI 稳定；
• Rocky Linux 与 AlmaLinux 继承了 RHEL 的 kABI 稳定性；
• openEuler 的内核 ABI 承诺与 RHEL 不同，跨 minor 版本可能发生变化；
• 龙蜥 Anolis OS 8 基本继承了 RHEL 8 的 kABI 承诺。

因此，对重度依赖闭源内核模块的环境，选择 Rocky Linux 或 AlmaLinux 能降低驱动维护成本。

9.6 证书信任链与合规扫描工具

企业环境中常使用合规扫描工具（如 OpenSCAP、Nessus、趋势科技的 Deep Security）对系统做持续评估。这类工具的策略库通常基于”RHEL 基线”编写，对克隆版或国产发行版的支持程度不一。迁移后需要关注：

• 策略兼容性：OpenSCAP 的 ssg-rhel8 策略集是否能在 Rocky 8 / Alma 8 / Anolis OS 8 上正常运行。实测结果是大多数检查项兼容，少数与发行版标识相关的检查需要调整；
• CVE 信息源：Red Hat CVE Database 只覆盖 RHEL，Rocky 与 Alma 各自维护自己的 CVE 公告，需要将这些源加入扫描器的数据源配置；
• 漏洞扫描工具的证书信任：部分安全扫描工具只信任 Red Hat 签名的 RPM，需要在工具配置中显式信任 Rocky / Alma 的 GPG 密钥。

9.7 迁移后的常见误报与排查

从实际迁移项目反馈，常见的”看起来像故障但其实是误报”的情况包括：

• yum 仓库 metadata 缺失警告：迁移脚本执行后首次 dnf makecache 可能花较长时间，属正常现象；
• systemctl 提示单元文件已变更：由于服务单元从 CentOS 切换到新发行版，部分自定义 .service 文件被系统覆盖，需要重新 merge；
• firewalld 启动失败：如果原环境已经使用 iptables，迁移后可能出现两个防火墙后端冲突，需要明确选择其一；
• /etc/redhat-release 不存在：部分应用硬编码检查此文件。Rocky / Alma 通过 redhat-release 包提供兼容符号链接，openEuler / 龙蜥则需要手动创建。

十、选型建议

对于正在评估从 CentOS 迁移的团队，以下是具体可执行的建议：

1. 容器化优先：如果工作负载已经或可以容器化，优先通过容器解耦发行版依赖，选择任意符合团队技术栈的宿主机发行版；
2. RHEL 生态依赖强：选择 Rocky Linux 或 AlmaLinux，关注其与 RHEL 兼容性声明的最新动态；
3. 国内信创合规场景：选择 openEuler 的商业发行版（各合作厂商提供支持），或麒麟软件的 Kylin Server；
4. 阿里云/腾讯云优先：分别选择各自云厂商的优化版本（Anolis/TencentOS），可获得最佳云平台集成体验；
5. 评估支持合同：无论选择哪个方向，生产环境应购买商业支持合同，以保障安全补丁的及时获取。

10.1 若你是架构师，应该怎么做

架构师在选型时面对的是”未来 3–5 年的平台稳定性”这一长周期问题，决策路径可以按以下决策树展开：

1. 当前工作负载是否已容器化？
   • 是 → 选择任意受主流 Kubernetes 发行版支持的宿主机系统（Rocky、Alma、openEuler、Anolis 均可），重点是宿主机系统的补丁节奏而非 API 兼容；
   • 否 → 进入第 2 步。
2. 是否存在商业软件的 RHEL 认证依赖？（例如 Oracle Database、SAP HANA、DB2、WebLogic）
   • 是 → 查询供应商的支持矩阵。若矩阵包含 Rocky/Alma → 可选 Rocky/Alma；若仅支持 RHEL 官方 → 必须评估直接购买 RHEL 订阅的成本；
   • 否 → 进入第 3 步。
3. 是否受信创合规或本地化要求约束？
   • 是 → openEuler（政企通用）、Kylin Server（有完整信创资质链）、统信 UOS Server（Debian 路线，适合从零起步）。进入第 4 步做进一步筛选；
   • 否 → 进入第 5 步。
4. 信创场景下的二次筛选：
   • 硬件主要是鲲鹏（ARM）→ openEuler / HCE；
   • 硬件主要是海光（x86）或兆芯 → 优先选择该硬件厂商官方推荐配对的发行版；
   • 对应用迁移成本敏感 → 优先选择与 CentOS 兼容度高的（Anolis、openEuler、Kylin）。
5. 是否主要运行在某家云厂商？
   • 阿里云 → Anolis OS；
   • 腾讯云 → TencentOS Server；
   • 华为云 → HCE / openEuler；
   • AWS → Amazon Linux 2023 或 Rocky / Alma；
   • 多云或混合云 → Rocky Linux 或 AlmaLinux（跨云可用，社区生态一致）。
6. 确定候选后，做三项验证：
   • 做一个典型业务的完整迁移 POC，实测性能、兼容性、升级路径；
   • 与目标发行版的商业支持方签订 SLA，明确 CVE 响应时间；
   • 建立补丁跟踪与回退预案，至少覆盖 1 个完整 minor 版本升级周期。

10.2 若你是 IT 运维，应该做什么准备

运维团队的关注点在于”迁移执行的可控性”与”迁移后的日常维护”。具体操作清单如下：

迁移前（T-90 天以上）：

• 资产清点：列出所有 CentOS 6 / 7 / 8 服务器，记录每台的用途、应用负责人、关键度；
• 依赖扫描：用 rpm -qa --last、yum history、systemctl list-units 生成完整的软件清单；
• 备份演练：至少做一次完整数据恢复演练，确认备份可用；
• 权限梳理：收集每个业务系统的业务方联系人，提前沟通迁移窗口。

迁移前（T-30 天）：

• POC 环境搭建：在测试环境用目标发行版搭建与生产一致的实例，完成应用部署与基础测试；
• 迁移脚本验证：在测试环境完整运行 migrate2rocky 或 almalinux-deploy，记录耗时与问题；
• 文档准备：编写每台服务器的”迁移 runbook”，包含操作步骤、回退步骤、验证步骤；
• 监控基线：采集迁移前的性能基线（CPU、内存、IO、网络），用于迁移后对比。

迁移执行（T 日）：

• 分批迁移：按”非核心 → 核心”、“单台 → 集群”顺序推进，每批后观察至少 24 小时；
• 双人协同：至少两人同时在线，一人执行一人监控，关键步骤录屏；
• 实时监控：业务关键指标看板保持在视野内，出现异常立即暂停；
• 快照保护：虚拟机类服务器在执行迁移脚本前打快照，物理机类做 dd 镜像或 LVM 快照。

迁移后（T+1 至 T+30 天）：

• 性能对比：与迁移前基线对比，识别异常；
• 补丁验证：首次安全更新时密切观察，确保 yum repo 配置正确；
• 文档沉淀：把迁移过程中发现的问题写入知识库，供后续批次参考；
• 安全审计：重新进行一次安全扫描，确认 SELinux、防火墙规则、用户账户状态；
• 合规确认：向合规部门报送新发行版的版本信息与订阅合同。

长期维护：

• 订阅管理：纳入 IT 资产系统，到期前至少 60 天提醒续费；
• 版本策略：跟踪目标发行版的 minor 版本发布节奏，制定每年 1–2 次升级计划；
• 应急预案：演练”发行版厂商突发策略变更”的应对流程，至少每年一次；
• 生态跟踪：订阅发行版的安全公告邮件列表与 CVE 频道。

10.3 常见误解与纠正

在 CentOS 迁移的技术讨论中，有几个常见误解值得专门澄清：

误解一：“CentOS Stream 就是 CentOS 的替代品”

CentOS Stream 是 RHEL 的上游开发分支，滚动更新，不等同于原 CentOS 稳定版。对生产环境直接使用 Stream 需谨慎评估稳定性。

误解二：“所有 RHEL 兼容发行版都可以直接替换”

Rocky/Alma 在 2023 年之后与 RHEL 不再 100% 二进制一致，openEuler/Anolis 则有更大的差异。迁移前需要按实际工作负载做兼容性测试。

误解三：“付费 RHEL 是唯一合规选择”

GPL 赋予的自由权利不需要付费；Rocky/Alma 可以合规商用。“付费” 只影响是否获得厂商技术支持与认证，而非合规性。

误解四：“国产发行版只适合信创场景”

openEuler 与龙蜥在非信创场景（如一般企业生产服务器、开发环境、云原生平台）同样可用。选型的决定因素应是技术适配度与支持成本，而非出身国别。

误解五：“迁移一次就永远不用再动”

发行版的生命周期有限。Rocky/Alma 9 将在 2032 年 EOL，openEuler LTS 版本通常 4 年更新一次。迁移应当视为持续过程，而非一次性工程。

10.4 决策清单的可视化摘要

为便于在团队内部传达，这里提供一个浓缩的一页决策摘要，可打印张贴在技术评审会议室。

在使用这张表前，请务必先完成 10.1 的决策树评估。这张表只是决策树的摘要输出，不能替代完整的技术评估与 POC 验证。

10.5 面向未来的三点建议

最后，对于任何正在或即将做企业 Linux 选型的团队，有三个长期性的建议：

1. 避免强绑定单一上游：无论选择哪个发行版，都应当保持迁移到其他发行版的可行性。这意味着避免使用发行版特有的扩展功能、坚持使用标准化的配置管理工具、容器化业务应用以解耦宿主机；
2. 持续投资自动化基础设施：迁移能力的本质是基础设施自动化能力。使用 Ansible / Puppet / Terraform 将系统配置作为代码管理，能在未来任何一次发行版切换中显著降低成本；
3. 参与社区而非仅作为消费者：对于关键业务依赖的开源项目，参与社区（提交 Issue、贡献补丁、参加技术会议）能帮助团队及早感知项目走向的变化，避免重蹈 CentOS 用户在 2020 年底的被动状态。

这三点的背后是一个更深的原则：在开源生态中，“免费”从来不等于”无成本”。长期稳定地使用开源软件，需要建立起对上游项目的理解、投入与参与。CentOS 停服事件是这个原则的一个具体注脚。

本文为工程参考，不构成法律意见。涉及具体法律风险请咨询专业法律顾问。本文所述事件均来自公开报道与公开判决书，如有偏差以官方渠道为准。

参考资料

1. Red Hat 官方公告（2020 年 12 月 8 日）：redhat.com/en/blog/centos-stream-building-innovative-future-enterprise-linux
2. Rocky Linux 项目主页：rockylinux.org
3. AlmaLinux OS Foundation：almalinux.org
4. Red Hat 源码政策声明（2023 年 6 月）：redhat.com/en/blog/furthering-evolution-centos-stream
5. Software Freedom Conservancy 立场声明：sfconservancy.org/blog/2023/jun/23/rhel-gpl-analysis/
6. openEuler 项目主页：openeuler.org
7. 龙蜥（OpenAnolis）社区：openanolis.cn
8. TencentOS Server GitHub：github.com/Tencent/TencentOS-kernel
9. 开放原子开源基金会：openatom.org
10. CentOS 7 生命周期说明：wiki.centos.org/About/Product
11. GPLv2 协议原文：gnu.org/licenses/old-licenses/gpl-2.0.html
12. Red Hat 收购 CentOS 项目公告（2014 年 1 月）：redhat.com/en/about/press-releases/red-hat-and-centos-join-forces
13. IBM 完成收购 Red Hat 公告（2019 年 7 月）：newsroom.ibm.com/2019-07-09-IBM-Closes-Landmark-Acquisition-of-Red-Hat-for-34-Billion
14. migrate2rocky GitHub 项目：github.com/rocky-linux/rocky-tools
15. almalinux-deploy GitHub 项目：github.com/AlmaLinux/almalinux-deploy
16. 龙蜥迁移工具与迁移指南：openanolis.cn/sig/migration
17. Rocky Linux 对 Red Hat 源码政策的回应（2023 年 7 月）：rockylinux.org/news/keeping-open-source-open
18. AlmaLinux 2023 年 7 月关于 ABI 兼容的声明：almalinux.org/blog/future-of-almalinux/

上一篇：红芯浏览器与”国产内核”往事：披皮事件的工程复盘

下一篇：OpenHarmony 与开放原子基金会：大厂捐赠意味着什么