Spring Boot Web 应用在 Centos 7 容器化环境的部署排障笔记
项目背景与环境概要
随着分布式系统的普及，将本地开发完成的 Web 服务迁移至类生产环境的虚拟机进行测试是标准流程。近期尝试将一个在 Windows 环境下开发调试正常的 SpringMVC 项目部署到 CentOS 7 服务器时，遇到了一系列典型的基础设施与依赖冲突问题。本文档记录了从操作系统适配到运行时依赖解决的全过程分析。
- 目标系统: CentOS Linux release 7.9.2009
- 应用服务器: Apache Tomcat 9.0.41
- JRE 版本: OpenJDK 1.8.0_292 (x64)
故障一：原生库支持缺失导致的服务异常
在完成基础部署并启动 Tomcat 服务后，通过浏览器访问节点 IP 触发连接请求时，发现服务状态码返回 503 Service Unavailable。查阅后端日志文件（位于 `$CATALINA_BASE/logs/catalina.date.log`），定位到具体的报错信息指示底层的原生扩展库未能成功加载。这种情况通常是因为编译时的 JDK 环境变量未正确传递，或者缺失了 APR (Apache Portable Library) 的二进制支持。
解决方案：静态编译与动态库注入
为了解决此问题，需要手动介入构建链，确保运行时有对应的 C/C++ 原生库。操作逻辑如下：
- 依赖项核查
在执行编译任务前，必须确认基础工具链已就绪。使用 `rpm` 指令验证关键组件的存在性，若检测失败则调用包管理器进行补齐。重点检查编译器（GCC）、HTTP 解析库（APR）及 Java 运行环境的路径指向是否正确。
# 示例脚本片段
# 检查 GCC 及 JDK 路径
type which java; java -version
# 若缺失则执行补全操作
yum install -y gcc gcc-c++ apr-util-devel
- 源码级集成原生命周期管理 展开下载的 `tomcat-native` 压缩包，进入源码根目录。配置阶段需要显式指定 JNI 头文件路径和 SSL 支持开关，以确保加密通信所需的符号能被链接器识别。
cd tomcat-native-*/native
./configure \
--with-apr=/usr/bin/apr-1-config \
--with-java-home=$JAVA_HOME \
--with-ssl=yes \
--prefix=$CATALINA_BASE
make && make install
成功后，生成的 `.so` 库文件应自动归位至指定的 lib 子目录。但为了让 Java 虚拟机能找到这些二进制文件，必须显式设置运行时的库搜索路径。修改 Tomcat 的启动脚本，向环境中导出 `LD_LIBRARY_PATH` 变量，将其指向新安装的库目录。同时，检查 `server.xml` 中关于协议处理器的定义，确保启用了支持该原生加速器的处理器类型。
故障二：启动初期化的 Bean 创建失败
排除掉基础设施层面的阻碍后，再次访问自定义的 Web 应用上下文（例如 `/imooc_reader`），此时接口返回 500 Internal Server Error。通过深入剖析堆栈信息，发现问题根源在于 Spring 容器的依赖注入环节。
具体的异常链条显示了深层的类路径冲突：BeanCreationException 嵌套了 UnsatisfiedDependencyException，最终抛出的根本原因是 java.lang.NoSuchMethodError。错误明确指出了试图调用 org.apache.ibatis.session.Configuration.setShrinkWhitespacesInSql(boolean) 方法失败。
技术原理分析与假设
这种错误的经典成因通常是 Jar 包版本不兼容导致的 ABI 破坏变更：
- API 变更痕迹：较新版本的 MyBatis 可能已经移除或重命名了该方法，但构建时的元数据仍引用旧接口。
- 序列化与反序列化的边界情况：在某些 Linux 文件系统编码（如 UTF-8 默认区域设置）与开发机不一致的情况下，可能导致 XML 映射文件解析出现偏差，进而触发不合法的 Bean 属性映射。
考虑到该项目最初并非针对无图形用户界面（Headless）的 Linux 环境深度优化，路径分隔符（'\' 与 '/'）的差异以及硬编码的相对资源路径极有可能是导致部分静态资源配置失败的诱因。
