14.3 v2 验收

验收定义

eventd v2 验收不是「代码写完」，而是「系统在生产环境中可稳定运行」。验收分三层：

L1 功能验收：所有需求已实现并通过测试
L2 性能验收：满足基线指标
L3 运维验收：可部署、可监控、可回滚

L1 功能验收清单

网关层（第 1–3 章）

• HTTP 路由分发正确（/api/* → API 层）
• WebSocket 可建立连接并收发消息
• 网关中间件顺序正确（由外到内：错误处理 → 日志 → 请求 ID）
• 慢客户端保护生效（tryEmitNext 返回 FAIL_OVERFLOW 时剔除连接）

API 层（第 4–6 章）

• 注解路由和函数式路由同时工作
• JWT 鉴权通过/失败场景正确
• CORS 预检请求返回 200，并带 Access-Control-Allow-Origin/Methods/Headers
• 统一错误 JSON 格式正确（code + message + status）
• WebTestClient 单元测试全部通过

数据层（第 7–9 章）

• R2DBC 连接池正常工作（metrics 中 acquired/idle/pending 合理）
• 同一连接内的 R2DBC 事务回滚正确
• Saga 补偿链在失败场景下按逆序执行，且补偿失败可见
• Flyway 迁移脚本执行成功
• 主从路由读走从库、写走主库（用 pg_stat_activity 或连接账号验证，不是 EXPLAIN）
• Caffeine + Redis 缓存命中正常（看 cache.gets 指标，不只看响应时间）
• 缓存失效在事务提交后执行；TTL 只作为兜底，不用来保证一致性

整合层（第 10–12 章）

• Prometheus metrics 可抓取
• Zipkin traces 完整（含跨服务链路）
• 结构化日志输出 JSON（含 requestId/traceId）
• 熔断器在下游故障时快速失败
• 限流触发返回 429 + Retry-After
• Saga 正向流程和补偿流程均通过
• 事件总线发布/订阅正常

L2 性能验收

性能验收不能用一套固定 QPS 数字当通用标准。先在目标硬件、目标数据量和目标部署拓扑下测出本环境基线，再比较优化前后。

基线至少记录：

场景固定为：网关纯转发、API + Caffeine、API + Redis、API + R2DBC、Saga 全流程、WebSocket 广播。

验收口径：

• 同一场景至少跑 3 次，取中位数
• QPS 不低于基线的 80%
• P99 不超过基线的 1.5 倍
• 错误率 < 1%
• 连续运行 1 小时，内存无持续增长趋势

基线文件随版本提交（例如 perf/baseline.properties），但只在专用压测环境执行回归断言。共享 CI 机器上的数字波动足以让这些断言随机失败。

L3 运维验收

• Docker 镜像构建成功（docker build -t eventd:v2 .）
• Kubernetes manifest 可用（deployment + service + ingress）
• 健康检查端点 /actuator/health 返回 UP
• Prometheus 告警规则已部署
• Grafana dashboard 已导入
• 日志收集器（Fluentd/Filebeat）配置正确
• 数据库迁移可在 CI 中自动执行
• 回滚流程文档化（镜像回退 + 数据库前向修复脚本；Flyway Community 不提供 undo）

测试覆盖率

单元测试：目标行覆盖率 > 80%（覆盖率是下限，不是质量证明）
集成测试：所有 API 端点至少一个 happy path + 一个 error path
压力测试：连续运行 1 小时，内存无持续增长，GC 暂停符合本环境 SLO
混沌测试：随机 kill Pod，恢复时间符合本环境 SLO，且无数据丢失

「30 秒自愈」「GC < 200ms」这类数字要由 SLO 和实测决定，不能直接当通用门槛。

文档清单

• API 文档（OpenAPI/Swagger）
• 部署文档（Docker/K8s）
• 运维手册（告警响应、故障排查）
• 开发文档（本地启动、测试运行）
• 架构图（模块关系、数据流）

向卷三衔接

eventd v2 为卷三的流处理引擎提供：

1. 数据源：events 表中的业务事件 → Kafka Producer
2. HTTP 接收端：流处理结果的实时推送（WebSocket/SSE）
3. 监控基础设施：Prometheus + Zipkin 已就绪
4. 部署经验：容器化、K8s 运维经验可直接复用

卷三将引入 Kafka Streams 和 Flink，消费 eventd v2 产生的事件流，构建实时指标面板。

最终检查

运行完整构建：

# 1. 数据库迁移（需要 flyway-maven-plugin；应用启动时自动迁移则可省略）
./mvnw flyway:migrate

# 2. 单元测试
./mvnw test

# 3. 集成测试（启动完整 Spring 上下文）
./mvnw verify -P integration-test

# 4. 性能基准（13.3 的 exec:java 方式；也可接入 jmh-maven-plugin）
./mvnw test-compile exec:java \
    -Dexec.mainClass="org.openjdk.jmh.Main" \
    -Dexec.classpathScope=test \
    -Dexec.args="FluxBenchmark"

# 5. 打包
./mvnw package -DskipTests

# 6. Docker 构建
docker build -t eventd:v2 .

# 7. 容器启动测试（Docker Compose v2 用空格形式）
docker compose -f docker-compose.yml up -d
curl http://localhost:8080/health  # ok
docker compose down

flyway:migrate 和 jmh:benchmark 都不是 Maven 默认生命周期的一部分：前者要配 flyway-maven-plugin，后者要配 jmh-maven-plugin 或使用上面的 exec 方式。漏配插件时命令会直接报「No plugin found」，不是迁移或基准本身失败。

小结

eventd v2 验收通过的标准：

卷二《系统构建与数据访问》到此结束。感谢阅读。