企业服务器从Amazon Linux 2迁移到Amazon Linux 2023，应用兼容性要检查哪些项目

Amazon Linux 2 迁移到 Amazon Linux 2023，不能以“新服务器能够 SSH 登录、应用进程能够启动”作为兼容性验收标准。真正需要确认的是：原有二进制能否在新系统上正确链接，运行时和扩展版本是否匹配，数据库及中间件客户端能否完成认证与读写，服务管理、网络、安全策略和监控代理是否仍按预期工作。

Amazon Linux 2 的生命周期退出不等于现有实例会被自动关机，但继续依赖旧系统会增加补丁、软件源、漏洞修复和故障处置风险。企业迁移时应优先采用新建 Amazon Linux 2023 主机、重建应用环境、灰度切换的方式，不建议通过混用 Amazon Linux 2 与 Amazon Linux 2023 软件源或直接替换系统标识完成“原地升级”。

先冻结验收口径：什么才算应用兼容

迁移验收应以“业务能力在目标环境中保持可用”为核心，而不是单纯比较两个系统的发行版名称。建议在项目开始前，把以下内容写入变更单或验收单：

“通过”还应附带两个条件：一是结果可重复，二是证据可追溯。一次手工启动成功、一次接口返回 200，不能替代完整验收。

第一轮核对：建立 Amazon Linux 2 的真实基线

1. 确认架构、内核和系统身份

先记录源主机和目标主机的基本环境。不要仅根据实例类型或镜像名称推断架构，因为同一个应用可能在 x86_64 和 arm64 上使用不同的安装包、容器镜像或本地编译扩展。

以下命令主要用于只读采集：

cat /etc/os-release
uname -m
uname -r
rpm --eval '%{_arch}'
dnf --version
systemctl is-system-running
getenforce 2>/dev/null || true

重点记录：

• CPU 架构是否一致；
• 应用是直接运行在主机上，还是运行在容器中；
• 内核版本、加载的内核模块和关键 sysctl 参数；
• SELinux 当前状态及策略；
• 应用是否依赖特定设备、文件系统、内核模块、eBPF 或内核能力；
• 是否依赖固定网卡名称，例如 eth0，而新系统实际使用的是 ens5 等名称。

如果源环境为 x86_64、目标环境为 arm64，即使解释型语言代码本身兼容，也不能直接复用 x86_64 的二进制、Python wheel、Node.js 原生扩展或私有 RPM 包。此时应重新构建对应架构的制品，并将容器镜像的多架构支持纳入验收。

2. 盘点应用启动链，而不是只盘点主程序

很多迁移故障不发生在主程序本身，而发生在启动链中的某个环节。例如 systemd 单元引用了旧路径，启动脚本调用了 amazon-linux-extras，定时任务使用了不存在的命令，或者环境变量只配置在旧主机的交互式 Shell 中。

源主机至少应记录以下内容：

rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' | sort
systemctl list-unit-files --state=enabled
systemctl list-timers --all
crontab -l 2>/dev/null || true
sudo crontab -l 2>/dev/null || true

同时从应用发布系统、配置管理系统和镜像构建文件中核对：

• 应用包或二进制的来源、版本和构建提交；
• 启动命令、工作目录、运行用户和用户组；
• EnvironmentFile、密钥文件、证书文件和配置文件路径；
• /opt、/srv、/var/lib、/var/log 等业务目录；
• systemd 的 LimitNOFILE、TimeoutStartSec、Restart、CapabilityBoundingSet 等设置；
• cron、systemd timer、队列消费者和批处理任务；
• 构建脚本中是否出现 yum、amazon-linux-extras、旧软件源地址或固定包版本。

不要把“目标主机能够重新安装同名软件包”当成基线。需要记录应用真正使用的库和功能。一个只监听 HTTP 端口的服务，与依赖图像处理、压缩、加密、数据库驱动的服务，其迁移风险并不相同。

3. 区分四类制品

建议把应用依赖分成四类，分别验收：

1. 源代码：需要在 Amazon Linux 2023 的构建环境重新编译或重新安装依赖。
2. 解释型代码：需要核对解释器版本、第三方包版本、编码和运行时路径。
3. 本地二进制：需要核对架构、动态链接器、glibc、libstdc++、OpenSSL 等。
4. 容器镜像：应用层可能不变，但仍需验证宿主机内核、cgroup、容器运行时和安全策略。

从 Amazon Linux 2 主机复制 /usr/lib64、/lib64 或整个虚拟环境到 Amazon Linux 2023，通常不能作为正式迁移方法。这样做容易形成难以维护的混合依赖，后续补丁也可能覆盖或破坏这些文件。

第二轮核对：系统库、编译链和加密接口

1. 核对 glibc 和动态链接关系

Amazon Linux 2 与 Amazon Linux 2023 在 glibc、编译器、libstdc++ 和系统库版本上存在差异。Linux 二进制通常具有一定的向后兼容性，但这不代表所有构建方式都能跨发行版运行。

对主程序和关键插件执行以下检查：

file /path/to/application
readelf -l /path/to/application | grep 'interpreter'
readelf -d /path/to/application | grep -E 'NEEDED|RPATH|RUNPATH'
readelf --version-info /path/to/application | grep -E 'GLIBC_|GLIBCXX_' || true

检查结果时关注：

• ELF 架构是否与目标主机一致；
• 动态链接器路径是否存在；
• NEEDED 中的库能否由目标系统提供；
• 是否存在指向旧目录的 RPATH 或 RUNPATH；
• 所需的 GLIBC_、GLIBCXX_ 符号版本是否高于目标环境；
• 应用是否携带了私有 .so 文件，并且这些文件又依赖其他未打包的库。

对可信的内部二进制，可以进一步使用：

ldd /path/to/application

ldd 不应直接用于来源不明的可执行文件。对于供应商提供的程序，优先使用供应商文档、软件包元数据或 readelf 检查依赖，避免为了确认依赖而执行不可信制品。

判定分支：

• 如果目标系统能找到全部依赖，且符号版本满足要求，再进入功能测试。
• 如果出现 No such file or directory，但文件本身存在，通常要检查动态链接器或依赖库，而不是简单判断文件权限。
• 如果出现 GLIBCXX_x.x.x not found，应重新编译应用或升级兼容的编译运行库，不要随意覆盖系统的 libstdc++。
• 如果应用依赖私有库，必须把私有库、版本、校验值和部署路径纳入正式制品。

2. 重点检查 OpenSSL 3 及 TLS 行为

Amazon Linux 2023 的加密库环境与 Amazon Linux 2 不同，OpenSSL 3 带来的影响可能出现在编译阶段，也可能在运行阶段才暴露。

先记录版本和实际使用的库：

openssl version -a
rpm -q openssl openssl-libs
ldconfig -p | grep -E 'libssl|libcrypto'

需要检查：

• 应用是否仍链接 libssl.so.1.0 或 libssl.so.1.1；
• C/C++ 程序是否使用已废弃或行为变化的 OpenSSL API；
• Java、Python、Node.js、PHP 等运行时是否通过自身扩展间接使用 OpenSSL；
• TLS 版本、密码套件、证书链和服务端名称校验是否一致；
• 是否依赖旧算法、弱签名、旧版加密套件或特定 Provider；
• 对端数据库、消息队列和外部 API 是否拒绝新的 TLS 协商方式，或反过来要求更高版本的 TLS。

典型异常可能类似以下示例：

error while loading shared libraries: libssl.so.1.1: cannot open shared object file

或者：

error:0308010C:digital envelope routines::unsupported

这类问题的正确处理顺序通常是：

1. 确认应用和扩展的支持矩阵；
2. 在 Amazon Linux 2023 构建环境重新编译或升级应用依赖；
3. 使用目标端的测试证书和真实协议参数验证；
4. 只有在供应商明确提供兼容包时，才考虑安装额外兼容库。

不建议从非受控来源复制旧版 libssl 到系统目录，也不建议通过降低全局加密策略来“让程序先跑起来”。这样可能绕过安全控制，却没有真正消除兼容问题。若必须调整加密策略，应记录影响范围、适用连接、恢复方式和到期时间。

3. 检查编译器、C++ ABI 和本地扩展

以下组件经常在解释型语言背后隐藏本地代码：

• Python 的数据库、密码学、科学计算和图像处理扩展；
• Node.js 的 node-gyp 原生模块；
• PHP 的数据库、图像和缓存扩展；
• Java 的 JNI 库；
• Go、Rust 或 C++ 编译出的动态链接程序；
• Nginx、Web 服务器和日志代理的第三方模块。

验收时不能只执行 --version。还要在干净的 Amazon Linux 2023 构建环境中重新安装或编译，并运行实际导入测试。若供应商只提供 Amazon Linux 2 的 RPM，应确认其是否支持 Amazon Linux 2023，而不是只看 RPM 能否安装。

第三轮核对：语言运行时和应用框架

Python 应用

Python 迁移时最容易被忽略的是“系统 Python”和“应用虚拟环境”不是同一件事。需要记录：

• Python 主版本；
• venv、virtualenv、Poetry 或 Conda 的构建方式；
• 依赖锁定文件；
• C 扩展及其编译工具链；
• 时区、默认编码和区域设置；
• WSGI/ASGI 服务器及其启动参数。

基础核对示例：

python3 --version
python3 -c 'import sys,ssl,locale; print(sys.version); print(ssl.OPENSSL_VERSION); print(locale.getpreferredencoding(False))'
python3 -m pip check

在目标环境中，建议从锁定文件重建虚拟环境，不要直接复制 Amazon Linux 2 上的 site-packages。对数据库驱动、密码学扩展、图像处理库和科学计算库，要实际执行导入与核心函数测试。

结果解释：

• 依赖包能够安装但导入失败，通常是本地扩展、动态库或 Python ABI 不匹配。
• 导入成功但 HTTPS、数据库连接失败，重点检查 OpenSSL、CA 证书和驱动行为。
• 应用启动成功但定时任务失败，重点检查 systemd/cron 使用的解释器路径和环境变量。

Java 应用

Java 迁移应同时核对 JDK 主版本、JVM 参数、TLS、时区和 JNI 依赖：

java -version
printf '%s\n' "$JAVA_HOME"

重点检查：

• 编译时 JDK 与运行时 JDK 是否一致；
• 是否使用已经删除或不再支持的 JVM 参数；
• 垃圾回收器、堆大小、文件描述符和线程栈配置；
• JDBC 驱动版本是否支持目标数据库和目标 JDK；
• 信任库、证书链和默认 TLS 行为；
• JNI 动态库是否依赖旧版 glibc 或旧版 libstdc++；
• 应用日志中的字符集和时区是否变化。

如果目标系统只安装了较新的 JDK，而应用仍要求旧版本，应以应用供应商兼容矩阵为准决定升级应用还是并行提供指定 JDK。不要通过修改全局 JAVA_HOME 让所有服务共用一个未经验证的版本。

Node.js 应用

Node.js 版本、包锁文件和原生扩展必须一起检查：

• node、npm 或其他包管理器版本；
• package-lock.json、yarn.lock 或 pnpm 锁文件；
• node-gyp 所需的编译器和头文件；
• bcrypt、图像处理、压缩、数据库驱动等原生模块；
• OpenSSL 版本变化对加密 API 的影响；
• systemd 服务使用的 Node 路径是否与交互式 Shell 一致。

在干净的目标构建环境中，应使用锁文件执行安装，并运行单元测试和实际接口测试。npm install 可能重新解析依赖，不能替代锁定安装；生产构建应遵循项目既有的确定性构建方式。

PHP、Ruby、Go 及其他运行时

PHP 要检查 PHP 主版本、扩展 API、FPM 服务、php.ini、CLI 与 FPM 的配置差异。命令行执行正常而 Web 请求失败，往往是 FPM 使用了另一套扩展或环境变量。

Ruby 要检查原生 gem、编译工具链和 Bundler 锁文件。Go 或 Rust 程序虽然可能以静态链接方式发布，但仍需检查 DNS、证书、时区、内核能力和动态插件。如果程序使用 cgo、OpenSSL、SQLite 或图像库，就不能简单按“静态编译”处理。

第四轮核对：数据库、中间件和外部服务

1. 数据库客户端与连接协议

无论数据库部署在本机、同一私网还是云数据库，迁移时都要区分“数据库服务端迁移”和“应用客户端迁移”。

客户端侧重点包括：

• MySQL、PostgreSQL、SQL Server、Oracle 等驱动版本；
• JDBC、ODBC、PDO、原生客户端或 ORM 适配器；
• 用户认证插件；
• TLS 证书和 CA 文件路径；
• 字符集、排序规则和时区；
• 连接池大小、连接超时、读写超时和重试策略；
• IPv4/IPv6、DNS 解析和私网路由；
• 数据库服务端是否限制来源地址、TLS 版本或客户端版本。

需要实际执行一组与业务一致的操作：建立连接、查询、事务提交、事务回滚、批量写入、分页读取、长连接重连以及连接池耗尽处理。只执行一个 SELECT 1 不能证明 ORM、事务和字符集行为没有变化。

如果本地数据库数据文件也要迁移，必须先确认数据库版本、存储引擎和官方支持的迁移方式。不要直接把旧主机的 /var/lib/mysql、/var/lib/pgsql 等数据目录复制到新主机后启动。涉及数据目录、权限或数据库版本变化时，应先完成备份或快照，确认恢复步骤，再使用经过支持的逻辑导出、物理备份或复制方案。回滚应能够恢复到一致的数据状态，而不是只切回旧服务器 IP。

2. 缓存、消息队列和搜索服务

对 Redis、Memcached、Kafka、RabbitMQ、OpenSearch 等服务，检查内容不只是端口连通性：

• 客户端库和协议版本；
• TLS、用户名、密码和证书；
• SASL 或其他认证机制；
• 消息确认、重试、消费位点和幂等逻辑；
• 压缩算法；
• 大消息、批量消息和连接断开后的行为；
• DNS 变化和连接池重建；
• 服务端对客户端 IP、TLS 或协议字段的限制。

消费者程序应验证重启、重复投递、消费延迟和异常消息处理。若只验证“能收到一条消息”，无法发现确认机制或位点提交差异。

3. Web 服务、反向代理和网络接口

迁移后要检查 Nginx、Apache 或其他 Web 组件的配置语法、模块、证书路径和上游连接。重点包括：

• 配置文件是否引用旧路径；
• 动态模块是否能加载；
• TLS 证书、私钥和 CA 链权限是否正确；
• 上游连接的域名、端口、SNI 和超时是否一致；
• 上传临时目录、静态文件目录和日志目录是否存在；
• 连接数、文件描述符和内核参数是否满足原有负载；
• 防火墙和安全组是否同时允许必要的入站、出站流量。

如果原脚本硬编码了 eth0、固定 IP 或旧网卡路径，应改为读取实际接口、DNS 或服务发现信息。防火墙规则调整前应备份现有规则和安全组配置，并安排带外访问或控制台恢复路径，避免误改后失去远程管理能力。

4. AWS SDK、实例角色和元数据访问

运行在 EC2 上的应用还要检查 AWS SDK 与主机环境的交互：

• SDK 版本是否支持目标语言运行时；
• 实例角色权限是否与原主机一致；
• 区域、终端节点和代理配置是否正确；
• 是否依赖实例元数据获取临时凭证；
• 应用是否支持账户要求的实例元数据访问策略；
• S3、消息服务、密钥服务等调用的 TLS 和证书校验是否正常；
• 重试、超时和限流处理是否符合现有业务预期。

不要把永久访问密钥写入新主机配置文件作为临时迁移方案。若确实需要复制凭证、证书或密钥，应使用企业批准的密钥管理和传输流程，并在迁移完成后核对权限、轮换和撤销情况。

第五轮核对：服务管理、脚本和安全策略

1. systemd 单元与运行用户

在目标主机上检查实际生效的服务单元：

systemctl cat app.service
systemd-analyze verify /etc/systemd/system/app.service

需要确认：

• ExecStart 使用的二进制或解释器路径；
• WorkingDirectory 是否存在；
• User、Group 和目录权限是否匹配；
• EnvironmentFile 是否已经部署；
• After、Requires、Wants 等依赖关系是否适用；
• Restart 策略是否会掩盖真实启动错误；
• LimitNOFILE、内存限制和能力限制是否改变；
• 服务启动后是否能被监控系统识别。

“手工执行程序成功，systemd 启动失败”通常是环境差异，不是应用代码本身的问题。systemd 不一定加载登录 Shell 的 PATH、代理、语言环境和密钥变量，应把依赖显式写入受控配置。

2. Shell、定时任务和系统命令

迁移时应审查脚本中的以下内容：

• yum、amazon-linux-extras 和旧软件源命令；
• /usr/bin/python、/usr/local/bin/node 等固定路径；
• service、ifconfig、netstat 等旧命令；
• sed、grep、tar、find、date 的特定参数；
• 依赖 Bash 语法却使用 /bin/sh 执行的脚本；
• 对用户、组、设备名、挂载点和临时目录的假设；
• 定时任务是否依赖交互式环境或当前目录。

Amazon Linux 2023 以 dnf 为主要软件包管理方式。即使目标环境提供兼容命令，也不应让正式脚本依赖未写入支持范围的别名。脚本中若需要安装软件，应由镜像构建或配置管理流程统一完成，不建议让生产启动脚本在启动时临时修改软件源。

3. 文件权限、SELinux 和安全代理

检查目录和文件时，至少覆盖：

• 应用运行用户对配置、日志、上传和临时目录的读写权限；
• 证书和私钥的所有者、组和模式；
• SELinux 上下文及拒绝日志；
• noexec、只读挂载和临时目录策略；
• 主机安全代理、漏洞扫描代理和日志代理是否支持 AL2023；
• 监控代理是否依赖特定内核模块或旧版 systemd 接口。

如果应用因 SELinux 被拒绝，不应直接将 SELinux 关闭作为验收手段。应先留存拒绝记录，确认访问对象和操作类型，再按最小权限原则补充策略。变更安全策略前要说明影响范围、审批人和恢复方法。

兼容性核对矩阵：按顺序判定结果

完成采集后，可按下面的顺序处理结果：

结果建议分为三类：

• 通过：功能和非功能测试达到约定标准，没有未解释的高风险异常。
• 条件通过：存在已知差异，但有书面风险评估、临时措施、责任人和到期时间。条件通过不适合用于核心生产切换，除非变更审批明确接受。
• 不通过：出现数据错误、认证失败、关键功能缺失、严重安全告警、无法回滚或性能明显超出预算。此时应停止切换，不要用重试、关闭校验或放宽权限掩盖问题。

分阶段验收：先验证兼容，再验证负载

阶段一：干净环境构建

使用 Amazon Linux 2023 的目标架构构建应用和依赖。构建过程应固定：

• 基础镜像或 AMI 版本；
• RPM 软件源和包版本；
• 语言运行时版本；
• 依赖锁文件；
• 编译器和构建参数；
• 生成制品的提交号和校验值。

这一阶段重点回答“能否正确安装和编译”，不代表业务已经兼容。

阶段二：启动与冒烟测试

在隔离环境启动所有服务，验证：

• 主进程和子进程状态；
• 监听地址和端口；
• 健康检查；
• 配置加载；
• 日志输出；
• 数据库、缓存、消息队列和对象存储连接；
• 一次完整的登录、查询、写入和异步处理流程。

对于应用启动日志中的 warning，应进行分类。非关键弃用提示可以记录并进入整改计划，但与证书、数据库事务、权限、线程池或数据序列化有关的 warning 不能直接忽略。

阶段三：业务回归与异常路径

正常路径之外，还要执行：

• 数据库连接断开后的自动恢复；
• 上游超时和返回错误；
• 重复提交和幂等处理；
• 大文件、特殊字符和边界日期；
• 消息重复投递和消费进程重启；
• 磁盘接近阈值、日志轮转和临时文件清理；
• 主机重启后的服务恢复。

如果应用只在正常路径下通过，而在连接重建或服务重启后出现数据重复、消息丢失或状态不一致，应判定为不通过。

阶段四：同条件性能对比

性能对比必须尽量保持条件一致，包括实例规格、CPU 架构、数据量、缓存冷热状态、并发数、网络路径和测试时长。新系统刚启动时缓存为空，不能直接与已运行多日的旧系统比较。

可使用企业已有基线，也可以在项目中预先约定示例门槛，例如：

• 核心接口错误率不得高于旧环境基线；
• P95 延迟控制在基线的约定偏差内；
• CPU、内存、文件描述符和连接数不出现无法解释的持续增长；
• 消费延迟、批处理时长和数据库连接池等待时间不超过业务预算。

这些数值应由业务负载决定，不能把某个通用百分比当成所有系统的固定标准。发现性能下降时，应先拆分应用耗时、数据库耗时、网络耗时和系统调用耗时，再判断是运行时版本、系统库、内核参数还是应用配置造成。

阶段五：灰度、切换与回滚验证

生产切换前，应保留可启动的 Amazon Linux 2 旧环境，并明确：

• 切换入口是负载均衡、DNS、服务发现还是其他方式；
• 新旧环境是否允许同时接收写请求；
• 数据复制、增量同步和一致性校验如何完成；
• 出现问题时由谁执行回切；
• 回切触发条件和最长容忍时间；
• 切换后哪些证据需要再次采集。

回滚不是简单地把流量指回旧主机。如果新环境已经写入数据，必须先确认旧环境能否安全接收这些数据，否则可能造成覆盖、重复或数据分叉。涉及数据库结构、消息位点和文件内容的变更，必须在切换前完成恢复演练。

异常留证：让每个不兼容问题都能复现

每个异常至少记录以下信息：

• 源系统和目标系统的版本、架构、内核；
• 应用版本、构建提交号和制品校验值；
• 依赖包清单和运行时版本；
• 发生时间、主机标识和测试用例；
• 完整错误日志及前后文；
• 请求参数、消息样本或数据范围，敏感字段应脱敏；
• 预期结果和实际结果；
• 影响范围、严重级别和当前状态；
• 临时措施、责任人和下一步动作。

建议不要只保存截图。截图无法用于批量比较，也容易丢失上下文。命令输出、应用日志、systemd 状态、测试报告和配置版本应以文本或结构化文件归档。配置证据可以保存路径、版本和校验值，但不要把密码、私钥、访问令牌直接放入验收附件。

出现以下类型的证据时，应暂停“条件通过”的判断：

• 动态库缺失但通过复制旧库临时解决；
• 通过关闭 TLS 校验、SELinux 或防火墙解决连接问题；
• 通过 root 运行应用解决权限问题；
• 通过手工设置环境变量才能启动；
• 数据库写入结果没有完成对账；
• 监控和告警未接入，只能依靠人工观察；
• 回滚没有验证数据一致性。

复核清单：修复后不能只重复原命令

兼容性问题修复后，应从受影响的层级重新开始复核，而不是只重复导致报错的那条命令。

例如：

• 修复动态库后，要重新构建、启动并运行完整业务流程；
• 升级 OpenSSL 或数据库驱动后，要重新验证 TLS、认证、事务和连接重试；
• 调整 systemd 权限后，要用实际运行用户重启服务并检查日志；
• 修改 SELinux 策略后，要验证允许的访问和不应允许的访问；
• 更换语言运行时后，要重新执行依赖安装、单元测试和接口回归；
• 调整内核或网络参数后，要重新执行连接数、并发和重启测试；
• 修复监控代理后，要确认指标、日志、告警和主机下线通知均能触发。

正式切换后，还应安排一次变更后复核，至少覆盖新主机重启、应用滚动重启、证书或密钥加载、日志轮转、定时任务、备份恢复抽检和监控告警。Amazon Linux 2023 后续补丁、运行时升级或供应商驱动更换时，应重新执行受影响的兼容性项目，而不是认为首次迁移通过后永久有效。

最终验收资料应至少保留版本基线、依赖清单、构建记录、测试结果、异常关闭记录、性能对比、灰度监控、回滚验证和复核日期。这样才能证明应用不是“在新系统上启动过一次”，而是在 Amazon Linux 2023 上具备可重复部署、可观测、可回滚和可持续维护的兼容性。