3、环境准备与依赖管理
搞数据审计SDK,第一步不是写代码,而是把环境搭稳。我见过太多团队在项目中期才发现JDK版本不对,或者依赖冲突折腾了两天。说白了,这些坑完全可以在开始之前就填平。
这一章我会把环境要求、语言版本、依赖配置和兼容性规则全部摊开来聊。你跟着走一遍,基本不会出大问题。
3.1 操作系统要求
我们的审计SDK底层依赖系统调用做文件监控和网络拦截,所以不同OS的表现会有细微差异。我个人的习惯是统一在Linux下开发和测试,生产环境也推荐Linux。
| 操作系统 | 支持版本 | 说明 |
|---|---|---|
| Linux | CentOS 7+、Ubuntu 18.04+、Alpine 3.12+ | 生产首选,内核需开启 auditd 或 eBPF 支持 |
| macOS | macOS 11 Big Sur 及以上 | 仅用于本地开发调试,不支持生产部署 |
| Windows | Windows Server 2016+ / Windows 10 1809+ | 需要启用 Windows 事件跟踪(ETW)功能 |
我的经验:在 macOS 上做开发时,记得给 Docker 分配至少 4GB 内存。我之前因为默认 2GB 导致审计 SDK 编译时 OOM,排查了半天才发现是 Docker 资源限制。
3.2 语言版本要求
这节很重要。不同语言的版本直接影响SDK的功能可用性。举个例子,Java 8 和 Java 11 在模块化系统上差别很大,审计SDK中用到的某些反射 API 在 Java 17 之后被限制了。
你想想看,如果生产环境用的是 Java 8,但你本地用 Java 17 写了新特性,发布时就会报错。所以版本对齐是硬性要求。
3.2.1 Java 版本兼容表
| SDK 版本 | 最低 Java 版本 | 推荐 Java 版本 | 注意事项 |
|---|---|---|---|
| v1.0 - v1.4 | Java 8 | Java 11 | 使用 --add-opens 解决反射警告 |
| v2.0+ | Java 11 | Java 17 | 不再支持 Java 8 |
3.2.2 Python 版本兼容表
| SDK 版本 | 最低 Python 版本 | 说明 |
|---|---|---|
| v1.0 - v1.3 | Python 3.7 | 支持 asyncio 原生协程 |
| v2.0+ | Python 3.9 | 不再支持 3.7 以下版本 |
3.2.3 Go 版本兼容表
| SDK 版本 | 最低 Go 版本 | 推荐 Go 版本 |
|---|---|---|
| v1.0+ | Go 1.16 | Go 1.21 |
特别注意:Java 8 用户请注意,从 v2.0 开始 SDK 不再支持 Java 8。如果你还在用 Java 8,请锁定 v1.4.x 版本。别问我怎么知道的——我曾经帮一个团队紧急回滚,只因为没注意到版本声明。
3.3 Maven/Gradle 依赖配置
依赖配置这块,我建议直接复制粘贴下面的片段。但有一点要提醒你:版本号不要写死 SNAPSHOT,除非你在做特性开发。
3.3.1 Maven 配置
<dependency>
<groupId>com.yourcompany.audit</groupId>
<artifactId>data-access-audit-sdk</artifactId>
<version>2.1.0</version>
</dependency>
<!-- 如果使用 Spring Boot,建议添加 -->
<dependency>
<groupId>com.yourcompany.audit</groupId>
<artifactId>data-access-audit-spring-boot-starter</artifactId>
<version>2.1.0</version>
</dependency>
3.3.2 Gradle 配置
implementation 'com.yourcompany.audit:data-access-audit-sdk:2.1.0'
// 如果使用 Spring Boot
implementation 'com.yourcompany.audit:data-access-audit-spring-boot-starter:2.1.0'
核心原则:所有传递性依赖必须显式声明版本,防止意外升级。我之前遇到过 jackson-databind 被老版本覆盖导致序列化失败的情况,后来强制约束了所有 Jackson 版本才解决。
3.4 版本兼容性说明
版本兼容性是最容易被忽视的。你可能会觉得「版本号升一点没事」,但审计SDK涉及底层拦截,小版本差异也可能出大问题。
3.4.1 核心依赖兼容矩阵
| SDK 版本 | Spring Boot | Jackson | Netty | gRPC |
|---|---|---|---|---|
| v1.x | 2.3.x - 2.5.x | 2.10.x - 2.12.x | 4.1.x | 1.35.x - 1.40.x |
| v2.0 - v2.1 | 2.6.x - 2.7.x | 2.13.x - 2.14.x | 4.1.x | 1.45.x - 1.50.x |
| v2.2+ | 3.0.x - 3.2.x | 2.15.x+ | 4.1.x | 1.55.x+ |
看到没?Spring Boot 从 2.x 跳到 3.x 时,SDK 也必须跟着升级。因为 Spring Boot 3 基于 Jakarta EE,包名从 javax.* 变成了 jakarta.*。这个变化影响很大,很多老项目升级时都会踩坑。
我的建议:在 pom.xml 或者 build.gradle 里用
<dependencyManagement> 或 platform 统一管理版本,别指望 Maven/Gradle 自动帮你解决。自动解析的版本往往不是你想要的。
3.5 本章知识结构图
下面这张图帮你快速理清环境准备和依赖管理的关系。从操作系统到底层SDK,再到上层应用,每一层都有明确的版本要求。
从图中可以看到,每一层都有明确的版本要求。我把它们分成两个维度:纵向是「环境依赖链」,横向是「应用集成」。你配置环境时,必须保证每一层版本都在SDK声明的兼容范围内。
一句话总结:操作系统 → 运行时 → 构建工具 → SDK核心 → 关键依赖,五层版本必须对齐,缺一层都不行。我个人习惯在项目初始化时就写好一个 .tool-versions 文件,把 JDK、Maven/Gradle、Python/Go 的版本全锁死,团队其他人拉下来直接生效。