📚 课程目录第3章环境准备

三、环境准备：先把地基打牢

说句实在话，我见过太多团队把SDK接不上去的问题，最后排查下来，90%都是环境没搞对。

操作系统不对、JDK版本不匹配、数据库驱动落后、网络策略没开——这四样里只要有一项出问题，你那审计SDK就乖乖趴着不动。

这一节咱们就把它一次性理清楚。

3.1 操作系统要求

我个人的习惯是——优先在 Linux 上部署审计SDK。原因很简单：生产环境里 Linux 的权限模型、文件句柄上限和内核参数调优都更顺手。

当然，Windows 和 macOS 也不是不行。开发和联调阶段完全能用。但你要是部署到生产，我推荐你用 CentOS 7+、Ubuntu 20.04+ 或 Rocky Linux 8+。

操作系统	推荐版本	使用场景	注意事项
Linux	CentOS 7+ / Ubuntu 20.04+ / Rocky Linux 8+	生产环境部署	需设置正确的时区与日志目录权限
Windows	Windows Server 2019+ / Windows 10+	开发与测试	NTFS 权限影响审计日志写性能
macOS	macOS 12+ (Monterey 及以上)	本地开发调试	Mac 的 Java 字体和时区有时会出怪问题

一个小经验： 我曾遇到 Windows 上 SDK 初始化超时，折腾半天发现是防病毒软件把审计日志目录给锁了。Windows 上部署记得把 SDK 目录加到白名单里。

3.2 JDK版本

这个事儿我得多说两句。JDK 版本不对，SDK 连编译都过不去。

咱们这个数据访问审计 SDK 基于 Java 8 编写，但为了向前兼容，JDK 8、11、17 都支持。JDK 8 是底线，JDK 17 是推荐——原因很简单：JDK 8 已经停止免费安全更新了。

JDK 8 (1.8.x)：最低要求，适合存量老旧项目。我提醒一句：别用 Oracle JDK 8 update 201 之前的版本，那个版本有个严重的 SSL 协商 bug。
JDK 11 (LTS)：我个人最推荐的版本。性能好，模块化清晰，而且 ZGC 对审计SDK这种低延迟场景非常友好。
JDK 17 (LTS)：如果你的应用已经升级到 Spring Boot 3.x，那直接上 JDK 17，没毛病。

  检查 JDK 版本的命令：java -version

  输出示例：openjdk version "17.0.9" 2023-10-17 LTS

避坑指南： 我曾经有个客户，本地 JDK 8 跑得好好的，上了生产环境发现是 JDK 17。结果呢？SDK 里有一段反射代码在 JDK 17 的模块化限制下直接抛了 InaccessibleObjectException。所以一定要在集成之前统一全环境的 JDK 版本。

3.3 数据库驱动

审计SDK需要直连数据库解析访问日志，所以数据库驱动必须提前配好。驱动版本要和你的数据库版本匹配，这个非常关键。

比如你用 MySQL 8.0.x，还拿着 5.1.x 的驱动，那连接认证就会失败，SDK 直接罢工。

数据库类型	驱动类名	推荐驱动版本	Maven坐标 (artifactId)
MySQL	`com.mysql.cj.jdbc.Driver`	8.0.33+	mysql-connector-j
Oracle	`oracle.jdbc.OracleDriver`	21.7.0.0+	ojdbc11
PostgreSQL	`org.postgresql.Driver`	42.6.0+	postgresql
SQL Server	`com.microsoft.sqlserver.jdbc.SQLServerDriver`	11.2.3+	mssql-jdbc

如果你用 Maven 或 Gradle，只需要在 pom.xml 或 build.gradle 里加上对应依赖就行。我个人习惯把驱动单独拎出来，不跟业务代码的依赖混在一起，这样升级驱动时不用动业务包。

<!-- pom.xml 示例：MySQL 驱动 -->
<dependency>
    <groupId>com.mysql</groupId>
    <artifactId>mysql-connector-j</artifactId>
    <version>8.0.33</version>
    <scope>provided</scope>
</dependency>

注意： 我把 scope 设成 provided，因为实际部署时驱动 JAR 会放到 SDK 的 lib 目录下，而不是让应用服务器再去加载一份。避免类加载器冲突。

3.4 网络策略检查

SDK 初始化时需要和审计服务端建立长连接，发送心跳和数据。如果网络策略没开，SDK 会一直重连，日志里全是 ConnectException。

你需要保证这些端口能通：

9000 (TCP)：SDK 向审计中心上报数据的主端口
9001 (TCP)：配置同步和心跳端口
443 (HTTPS)：如果开启 TLS 加密上报，也要放行

用 telnet 快速验证：

telnet <审计中心IP> 9000
telnet <审计中心IP> 9001

如果返回 Connected to...，说明网络没问题。

我记得有一次在银行项目里，网络策略审核卡了一周。最后发现是他们安全组只放了 80 和 443 端口，

9000 和 9001 连不上。让我哭笑不得的是，他们所有服务器都是内网互通的，根本不需要防火墙限制这么死。

血泪教训： 如果你在公司内网做集成，先找网络管理员确认好白名单策略。我曾经因为没检查策略，SDK 在生产环境上跑了 3 天，一条审计日志都没成功上报……后来发现是内网的代理服务器把 9000 端口给劫持了。

3.5 快速自检清单

别废话，直接对照下面这个表检查一遍：

检查项	检查方法	预期结果
操作系统版本	`cat /etc/os-release` 或 `ver`	符合推荐版本表
JDK版本	`java -version`	JDK 8 / 11 / 17 LTS
数据库驱动	检查 Maven/Gradle 依赖或 lib 目录	驱动版本 ≥ 推荐版本
网络端口连通性	`telnet` 或 `nc -vz`	9000、9001 端口正常
环境变量 `JAVA_HOME`	`echo $JAVA_HOME`	路径正确，指向 JDK 安装目录