Files
MAcode/docs/系统设计和开发方案.md

920 lines
41 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# CC码音视频监管系统——系统设计和开发方案
> 用于指导系统开发工作、多团队分工协作和关键技术合作
> 编制日期:2026年7月
---
## 一、项目概述
### 1.1 项目目标
建设CC码音视频监管系统,实现全网所有音视频内容的统一编码、实时验证、自动检测、秒级下架和全生命周期监管。
### 1.2 核心能力
| 能力 | 说明 | 响应速度 |
|------|------|---------|
| 平台门禁 | 各平台调用API在上传/播出/CDN/终端四个环节验证CC码 | 秒级 |
| 网络探针 | CC码中心独立运行的爬虫巡查+水印提取+指纹比对+AI语义识别 | 分钟级 |
| 秒级下架 | 一条指令全网同步下架(视频平台+音频平台+CDN) | 秒级 |
| UGC赋码 | 平台代理批量赋码,码段授权+本地赋码+异步回传 | 毫秒级 |
| 直播监管 | 直播/广播实时录制、切片检测、秒级断流 | 秒级~分钟级 |
| 申诉恢复 | 48小时申诉+24小时审核+秒级恢复 | 秒级恢复 |
### 1.3 系统边界
```
本系统负责(CC码中心) 各平台负责
───────────── ─────────────
· CC码生成、签发、生命周期管理 · 内容审核(平台责任,非CC码中心)
· 四关验证API · 平台内业务流程
· 秒级下架指令分发 · 水印嵌入(平台转码环节)
· 网络探针爬虫+检测 · 播放数据回传
· 指纹库建设与维护 · 下架指令执行
· 水印/指纹/AI检测引擎 · 申诉发起
· 监管后台+数据大屏 · 审核数据定期上报
· 申诉审核
```
> **内容审核是平台责任,CC码中心不替代平台审核。CC码中心的核心价值是"验证"和"监管",不是"审查"。平台审核是第一道防线,CC码中心的网络探针是第二道防线。**
### 1.4 内容审核责任划分
| 场景 | 审核责任方 | CC码中心角色 | 交互方式 |
|------|-----------|------------|---------|
| 影视剧/综艺上线 | 平台内容审核团队 | 审查通过后方可申请CC码 | 平台提交审核证明 → CC码中心签发 |
| UGC短视频上传 | 平台自动审核+人工复审 | 平台审核通过后批量赋码 | 平台本地赋码 → 异步回传 |
| 音频内容上线 | 音频平台审核团队 | 同影视剧 | 平台提交 → CC码中心签发 |
| 直播/广播 | 平台实时审核 | 预赋码+探针切片检测 | 预赋码 → 探针检测 → 违规断流 |
| 网络探针发现疑似违规 | CC码中心检测引擎 | 自动检测→告警→通知平台 | 探针检测 → 通知平台 → 平台确认 |
| 申诉复核 | CC码中心审核团队 | 人工复核误判 | 申诉 → 复核 → 恢复/驳回 |
**CC码中心对平台审核的监督机制**
| 机制 | 说明 |
|------|------|
| 网络探针巡查 | 独立巡查全网,平台漏审的违规内容被探针发现 |
| 平台考核 | 违规率、赋码覆盖率纳入考核,与年检/牌照续期挂钩 |
| 码段冻结 | 平台审核严重失职时冻结码段,已赋码内容批量下架 |
| 审核数据上报 | 平台定期上报审核量/通过率/拦截量,CC码中心抽查 |
---
## 二、系统架构
### 2.1 总体架构
```
┌─────────────────────────────────────────────┐
│ CC码中心(广电云) │
│ │
┌──────────┐ │ ┌─────────┐ ┌──────────┐ ┌───────────┐ │
│ 视频平台 │──API──────│──│ API网关 │─→│ 业务服务 │→│ 检测引擎 │ │
│ (爱奇艺等)│ │ │ (Kong) │ │ (Go微服务)│ │(Python+GPU)│ │
└──────────┘ │ └────┬────┘ └────┬─────┘ └─────┬─────┘ │
│ │ │ │ │
┌──────────┐ │ │ ┌────┴─────┐ ┌────┴─────┐ │
│ 音频平台 │──API──────│──┐ │ │ 存储层 │ │ 指纹库 │ │
│ (喜马拉雅)│ │ │ │ │(PG+Redis │ │(Milvus │ │
└──────────┘ │ │ │ │ +MinIO) │ │+ClickHse)│ │
│ │ │ └──────────┘ └──────────┘ │
┌──────────┐ │ │ │ │
│ 短视频平台│──API──────│──┤ │ │
│ (抖音等) │ │ │ │ │
└──────────┘ │ │ │ │
│ │ │ ┌──────────┐ │
┌──────────┐ │ │ │ │ 消息队列 │ │
│ 网络探针 │──内部─────│──┘ │ │ (Kafka) │ │
│ (爬虫集群)│ │ └───────│ │ │
└──────────┘ │ └──────────┘ │
│ │
┌──────────┐ │ ┌──────────┐ │
│ 监管后台 │──内部─────│───────────────│ 管理前端 │ │
│ (广电总局)│ │ │(React) │ │
└──────────┘ │ └──────────┘ │
└─────────────────────────────────────────────┘
```
### 2.2 架构原则
| 原则 | 说明 |
|------|------|
| 复用现有基础 | 在TCS-IPTV系统(Go+Gin+PostgreSQL)上扩展 |
| 云原生 | Kubernetes容器化部署,微服务架构 |
| 等保三级 | 所有组件部署于广电云等保三级VPC内 |
| 音视频统一 | 共用CC码体系、API网关、监管架构 |
| 分层解耦 | API网关层、业务服务层、检测引擎层、存储层独立部署 |
| 数据安全 | 不使用闭源外国商用SDK,水印/指纹技术自主可控 |
---
## 三、模块分解与技术规格
### 3.1 模块总览
```
CC码音视频监管系统
├── 业务网关层
│ └── api-gateway # Go, Kong, 鉴权限流路由
├── 核心业务层(Go微服务)
│ ├── cc-code-svc # CC码生成与生命周期管理
│ ├── verify-svc # 平台门禁四关验证
│ ├── ugc-code-svc # UGC批量赋码与码段管理
│ ├── takedown-svc # 秒级下架指令分发
│ ├── appeal-svc # 申诉接收与审核流转
│ └── live-monitor-svc # 直播监管调度
├── 检测引擎层(Python
│ ├── probe-crawler # 网络探针爬虫集群
│ ├── probe-detector # 水印提取+指纹比对+AI语义
│ ├── fingerprint-svc # 视频/音频指纹提取与入库
│ ├── watermark-svc # 视频/音频水印嵌入与提取
│ └── ai-semantic-svc # AI视频/音频语义理解
├── 前端层
│ └── admin-frontend # React监管后台+数据大屏
├── 存储层
│ ├── PostgreSQL # 关系型数据
│ ├── Redis Cluster # 缓存
│ ├── Milvus # 指纹向量库
│ ├── ClickHouse # 时序数据/检测日志
│ ├── MinIO # 对象存储
│ └── Elasticsearch # 搜索引擎
├── 消息层
│ └── Kafka # 异步事件流
└── 基础设施层
├── Kubernetes # 容器编排
├── Harbor # 镜像仓库
├── Vault # 密钥管理
├── Prometheus+Grafana # 监控告警
└── Loki+Jaeger # 日志+链路追踪
```
### 3.2 各模块技术规格
#### 3.2.1 api-gatewayAPI网关)
| 项 | 说明 |
|----|------|
| 语言 | Go |
| 框架 | Kong 3.x |
| 职责 | 统一API入口、JWT鉴权、API Key验证、限流、路由、日志 |
| 部署 | K8s Deployment, 3副本 |
| 性能目标 | 10万QPS |
| 依赖 | Redis(限流计数)、Vault(密钥) |
| 开发团队 | 后端团队 |
#### 3.2.2 cc-code-svcCC码生成与生命周期管理)
| 项 | 说明 |
|----|------|
| 语言 | Go |
| 框架 | Gin + GORM |
| 职责 | CC码生成、签发、状态机管理、码段分配、码段冻结 |
| 部署 | K8s Deployment, 3副本 |
| 复用 | `tcs-iptv/internal/cccode` 码段分配、序列号生成 |
| 数据库 | PostgreSQL: `cc_records`, `cc_segments`, `cc_status_log` |
| Kafka | `topic.code.apply`, `topic.code.issued` |
| 开发团队 | 后端团队 |
| 技术难度 | ⭐⭐ 低(复用现有代码) |
**CC码状态机**
```
pending ─审核通过→ active ─举报/疑似违规→ paused ─核实无违规→ active
active ─授权到期/内容下线→ expired
paused ─确认违规→ taken_down
```
**关键API**
| 接口 | 方法 | 说明 | 调用方 |
|------|------|------|--------|
| `/api/v1/code/apply` | POST | 申请CC码 | 内容制作方/平台 |
| `/api/v1/code/issue` | POST | 审核通过后签发 | 监管方 |
| `/api/v1/code/status` | GET | 查询CC码状态 | 平台(高频) |
| `/api/v1/code/suspend` | POST | 暂停CC码 | 监管方 |
| `/api/v1/code/restore` | POST | 恢复CC码 | 监管方 |
| `/api/v1/code/takedown` | POST | 下架CC码 | 监管方 |
| `/api/v1/code/segment/allocate` | POST | 分配码段给平台 | 监管方 |
| `/api/v1/code/segment/freeze` | POST | 冻结平台码段 | 监管方 |
#### 3.2.3 verify-svc(平台门禁验证)
| 项 | 说明 |
|----|------|
| 语言 | Go |
| 框架 | Gin + GORM |
| 职责 | 四关验证(上传/播出/CDN/终端)、UGC批量验证 |
| 部署 | K8s Deployment, 5副本 |
| 复用 | `tcs-iptv/internal/api/handlers.go` 验证接口框架 |
| 缓存 | Redis Cluster, TTL=10秒, 命中率>99% |
| 性能目标 | 10万QPS, 缓存命中<50ms, 未命中<200ms |
| 开发团队 | 后端团队 |
| 技术难度 | ⭐⭐ 低 |
**四关验证API**
| 关卡 | 接口 | 检查内容 | 响应时间 |
|------|------|---------|---------|
| 上传拦截 | `POST /api/v1/verify/upload` | CC码是否存在、是否在有效号段内 | <100ms |
| 播出校验 | `GET /api/v1/verify/playback?cc_code=xxx` | CC码状态是否active | <50ms |
| CDN注入校验 | `POST /api/v1/verify/cdn` | 文件哈希与登记哈希是否一致 | <200ms |
| 终端抽检 | `POST /api/v1/verify/terminal` | 播放内容哈希抽样比对 | <200ms |
#### 3.2.4 ugc-code-svcUGC批量赋码)
| 项 | 说明 |
|----|------|
| 语言 | Go |
| 框架 | Gin + GORM |
| 职责 | 码段授权、UGC批量赋码、批量回传、批量验证 |
| 部署 | K8s Deployment, 3副本 |
| 性能目标 | 批量回传10万条/分钟 |
| Kafka | `topic.ugc.batch-report` |
| 开发团队 | 后端团队 |
| 技术难度 | ⭐⭐ 低 |
#### 3.2.5 takedown-svc(秒级下架指令分发)
| 项 | 说明 |
|----|------|
| 语言 | Go |
| 框架 | Gin + GORM |
| 职责 | 下架指令生成、Kafka广播、平台回调、CDN清除、确认追踪 |
| 部署 | K8s Deployment, 3副本 |
| Kafka | `topic.takedown.broadcast`(24分区), `topic.takedown.confirm` |
| 数据库 | PostgreSQL: `takedown_orders` |
| 性能目标 | 指令分发<1秒, 平台回调超时3秒, 重试2次 |
| 开发团队 | 后端团队 |
| 技术难度 | ⭐⭐⭐ 中等(多平台并行分发+幂等+确认追踪) |
#### 3.2.6 appeal-svc(申诉管理)
| 项 | 说明 |
|----|------|
| 语言 | Go |
| 框架 | Gin + GORM |
| 职责 | 申诉接收、审核流转、恢复指令、误判案例记录 |
| 部署 | K8s Deployment, 2副本 |
| 数据库 | PostgreSQL: `appeals` |
| Kafka | `topic.appeal.created` |
| 开发团队 | 后端团队 |
| 技术难度 | ⭐⭐ 低 |
#### 3.2.7 live-monitor-svc(直播监管调度)
| 项 | 说明 |
|----|------|
| 语言 | Go + Python |
| 职责 | 直播流拉取调度、按分钟切片、并行送检、断流指令 |
| 部署 | K8s Deployment, 5副本 |
| 性能目标 | 500路(初期)→2000路(目标),切片间隔60秒 |
| 依赖 | FFmpeg, probe-detector, takedown-svc |
| 开发团队 | 后端团队 + 检测团队 |
| 技术难度 | ⭐⭐⭐ 中等(实时流处理+并发调度) |
#### 3.2.8 probe-crawler(网络探针爬虫集群)
| 项 | 说明 |
|----|------|
| 语言 | Python |
| 框架 | Scrapy + Playwright |
| 职责 | 视频网站巡查、音频平台巡查、直播录制、音频流监测 |
| 部署 | K8s Deployment, 10~50副本 |
| 依赖 | 代理IP池, MinIO(片段存储) |
| Kafka | `topic.detection.task` |
| 开发团队 | 检测团队 |
| 技术难度 | ⭐⭐⭐ 中等(反爬对抗+大规模调度) |
#### 3.2.9 probe-detector(检测引擎)
| 项 | 说明 |
|----|------|
| 语言 | Python |
| 框架 | FastAPI + Celery |
| 职责 | 水印提取、指纹比对、AI语义分析、检测结果上报 |
| 部署 | K8s Deployment + GPU节点 |
| 依赖 | watermark-svc, fingerprint-svc, ai-semantic-svc, Milvus |
| Kafka | `topic.detection.result` |
| 开发团队 | 检测团队 |
| 技术难度 | ⭐⭐⭐⭐ 较难(多种检测手段编排+分级检测策略) |
#### 3.2.10 fingerprint-svc(指纹提取与入库)
| 项 | 说明 |
|----|------|
| 语言 | Python |
| 职责 | 视频指纹提取(ResNet50)、音频指纹提取(Constellation Map)、入库Milvus |
| 部署 | K8s Deployment, GPU节点(视频指纹需要) |
| 视频指纹 | ResNet50 → 256维向量 → Milvus, GPU推理, 1分钟视频<2秒 |
| 音频指纹 | FFT → 峰值检测 → 组合哈希 → Milvus, CPU即可, 1分钟音频<1秒 |
| 开发团队 | 算法团队 |
| 技术难度 | 视频指纹⭐⭐ 低, 音频指纹⭐⭐ 低 |
| 开源参考 | audio-fingerprint-engine, Audio-Fingerprint, ResNet50+Milvus |
#### 3.2.11 watermark-svc(水印嵌入与提取)
| 项 | 说明 |
|----|------|
| 语言 | Rust 或 Go+CGO |
| 职责 | 视频水印嵌入/提取(DCT+QIM)、音频水印嵌入/提取(DSSS+心理声学) |
| 部署 | K8s Deployment, 3副本, 无需GPU |
| 视频水印参数 | 96bit/帧, PSNR>38dB, 抗压缩>95%, 抗裁剪>80% |
| 音频水印参数 | 96bit/10秒, SNR>20dB, 抗压缩>90%, 抗翻录>70% |
| 开发团队 | 算法团队 |
| 技术难度 | 视频水印⭐⭐⭐ 中等, 音频水印⭐⭐⭐⭐ 较难 |
| 开源参考 | VidMark, open-video-watermark, audiowmark, Audio-Watermarking |
#### 3.2.12 ai-semantic-svcAI语义理解)
| 项 | 说明 |
|----|------|
| 语言 | Python |
| 框架 | NVIDIA Triton + PyTorch |
| 职责 | 视频语义理解(CLIP)、音频语义理解(Whisper)、兜底检测 |
| 部署 | K8s Deployment + GPU节点 |
| 开发团队 | 算法团队 |
| 技术难度 | ⭐⭐⭐ 中等(模型部署+推理优化) |
#### 3.2.13 admin-frontend(监管后台)
| 项 | 说明 |
|----|------|
| 框架 | React 18 + Ant Design 5 + ECharts 5 |
| 职责 | CC码管理、下架操作、申诉审核、检测监控、数据大屏、平台管理 |
| 部署 | Nginx静态部署 |
| 开发团队 | 前端团队 |
| 技术难度 | ⭐⭐ 低 |
---
## 四、技术栈总览
### 4.1 后端服务层
| 组件 | 选型 | 版本 | 选型理由 |
|------|------|------|---------|
| 核心语言 | Go | 1.22+ | 高并发、低延迟,已有TCS-IPTV代码基础 |
| Web框架 | Gin | 1.10+ | 轻量高性能,已有代码基础 |
| ORM | GORM | 2.0+ | Go生态最成熟ORM |
| API网关 | Kong | 3.x | 开源成熟,插件丰富 |
| 服务间通信 | gRPC | — | 内部高性能RPC |
| 依赖注入 | Wire | — | 编译时DI,类型安全 |
### 4.2 检测引擎层
| 组件 | 选型 | 版本 | 选型理由 |
|------|------|------|---------|
| 检测服务语言 | Python | 3.11+ | AI/媒体处理生态最丰富 |
| 检测服务框架 | FastAPI | 0.110+ | 异步高性能,自动API文档 |
| 任务调度 | Celery + Redis | 最新版 | 异步任务队列,GPU任务排队 |
| GPU推理框架 | NVIDIA Triton | 2.x | 多模型并行、动态批处理 |
| 深度学习框架 | PyTorch | 2.x | 模型训练与推理 |
### 4.3 媒体处理层
| 组件 | 选型 | 说明 |
|------|------|------|
| 视频水印 | 自研(DCT+QIM) | 先采购国产商用快速落地,同步自研替换 |
| 音频水印 | 自研(DSSS+心理声学) | 基于开源算法改进,不使用闭源外国SDK |
| 视频指纹 | 自研(ResNet50+Milvus | 直接自研,工程集成 |
| 音频指纹 | 自研(Constellation Map | 类Shazam算法,直接自研 |
| 视频处理 | FFmpeg 6.x+ | 开源标准 |
| 音频处理 | librosa / torchaudio | Python音频分析标准库 |
### 4.4 数据存储层
| 组件 | 选型 | 版本 | 用途 |
|------|------|------|------|
| 关系型数据库 | PostgreSQL | 16.x | CC码记录、元数据、码段、申诉 |
| 数据库高可用 | Patroni + etcd | 最新版 | 自动故障切换 |
| 缓存 | Redis Cluster | 7.x | 热点CC码缓存、限流、分布式锁 |
| 向量数据库 | Milvus | 2.x | 视频/音频指纹向量检索 |
| 时序数据库 | ClickHouse | 24.x | 播放数据、检测日志、运营分析 |
| 对象存储 | MinIO | 最新版 | 视频片段、音频片段、证据包 |
| 搜索引擎 | Elasticsearch | 8.x | 审核报告检索、日志检索 |
### 4.5 消息与异步层
| 组件 | 选型 | 用途 |
|------|------|------|
| 消息队列 | Apache Kafka 3.x | 下架指令广播、检测任务分发、播放数据回传 |
| 流处理 | Apache Flink 1.18+ | 实时播放统计、异常检测 |
| 任务队列 | Celery + Redis | 异步任务 |
| 定时调度 | Airflow 2.x | 定时爬虫、报表生成 |
### 4.6 基础设施与DevOps
| 组件 | 选型 | 用途 |
|------|------|------|
| 容器编排 | Kubernetes 1.29+ | 容器编排、自动扩缩容 |
| 镜像仓库 | Harbor 2.x | 私有镜像仓库 |
| 密钥管理 | HashiCorp Vault | API Key、数据库密码 |
| 指标监控 | Prometheus + Grafana | 指标采集、告警 |
| 日志采集 | Loki + Promtail | 全链路日志聚合 |
| 链路追踪 | Jaeger / OpenTelemetry | 分布式请求追踪 |
| CI/CD | GitLab CI + ArgoCD | 自动化构建、GitOps |
### 4.7 前端层
| 组件 | 选型 | 版本 | 用途 |
|------|------|------|------|
| 管理后台 | React | 18.x | 监管后台、运营管理 |
| UI组件库 | Ant Design | 5.x | 企业级中后台组件 |
| 图表可视化 | ECharts | 5.x | 监管数据可视化 |
| 状态管理 | Zustand | 最新版 | 轻量全局状态管理 |
---
## 五、数据库设计
### 5.1 核心表结构
**cc_recordsCC码记录表)**
| 字段 | 类型 | 说明 |
|------|------|------|
| id | BIGSERIAL | 主键 |
| cc_code | VARCHAR(64) | CC码,唯一索引 |
| content_type | VARCHAR(16) | video/audio/live_video/live_audio |
| category | VARCHAR(32) | 内容类目 |
| title | VARCHAR(256) | 内容标题 |
| file_hash | VARCHAR(64) | 文件SHA256哈希 |
| perceptual_hash | VARCHAR(128) | 感知哈希 |
| fingerprint_vector | JSONB | 指纹向量引用ID |
| status | VARCHAR(16) | pending/active/paused/taken_down/expired |
| platform_id | VARCHAR(32) | 所属平台 |
| cp_name | VARCHAR(128) | 内容制作方 |
| is_ugc | BOOLEAN | 是否UGC |
| parent_cc_code | VARCHAR(64) | 父CC码(二创/衍生关联) |
| watermark_info | JSONB | 水印嵌入信息 |
| created_at | TIMESTAMP | 创建时间 |
| updated_at | TIMESTAMP | 更新时间 |
**cc_segments(码段表)**
| 字段 | 类型 | 说明 |
|------|------|------|
| id | BIGSERIAL | 主键 |
| segment_prefix | VARCHAR(32) | 码段前缀 |
| platform_id | VARCHAR(32) | 分配平台 |
| category | VARCHAR(32) | 内容类目 |
| start_seq | BIGINT | 起始序号 |
| end_seq | BIGINT | 结束序号 |
| current_seq | BIGINT | 当前已用序号 |
| frozen | BOOLEAN | 是否冻结 |
| allocated_at | TIMESTAMP | 分配时间 |
**takedown_orders(下架指令表)**
| 字段 | 类型 | 说明 |
|------|------|------|
| id | BIGSERIAL | 主键 |
| order_id | VARCHAR(64) | 指令ID,唯一索引 |
| cc_code | VARCHAR(64) | 目标CC码 |
| reason | TEXT | 下架原因 |
| issued_by | VARCHAR(64) | 下达人 |
| status | VARCHAR(16) | pending/executing/confirmed/failed |
| targets | JSONB | 下架目标列表 |
| confirmations | JSONB | 各平台确认回执 |
| created_at | TIMESTAMP | 下达时间 |
| completed_at | TIMESTAMP | 完成时间 |
**appeals(申诉表)**
| 字段 | 类型 | 说明 |
|------|------|------|
| id | BIGSERIAL | 主键 |
| appeal_id | VARCHAR(64) | 申诉ID |
| cc_code | VARCHAR(64) | 关联CC码 |
| appellant | VARCHAR(128) | 申诉人/平台 |
| reason | TEXT | 申诉理由 |
| evidence | JSONB | 证据材料 |
| status | VARCHAR(16) | pending/reviewing/approved/rejected |
| reviewer | VARCHAR(64) | 审核人 |
| result | TEXT | 审核结论 |
| created_at | TIMESTAMP | 申诉时间 |
| resolved_at | TIMESTAMP | 结案时间 |
**detection_logs(检测日志表,ClickHouse**
| 字段 | 类型 | 说明 |
|------|------|------|
| event_id | UUID | 事件ID |
| cc_code | String | 检测到的CC码 |
| content_url | String | 内容URL |
| detection_method | String | watermark/fingerprint/ai_semantic |
| result | String | normal/suspected/violation |
| confidence | Float32 | 置信度 |
| platform | String | 发现平台 |
| detected_at | DateTime | 检测时间 |
### 5.2 Kafka Topic规划
| Topic | 分区数 | 用途 | 保留期 |
|-------|--------|------|--------|
| `topic.code.apply` | 6 | CC码申请事件 | 7天 |
| `topic.code.issued` | 6 | CC码签发事件 | 30天 |
| `topic.takedown.broadcast` | 24 | 下架指令广播 | 7天 |
| `topic.takedown.confirm` | 6 | 下架确认回执 | 30天 |
| `topic.detection.task` | 12 | 检测任务分发 | 3天 |
| `topic.detection.result` | 12 | 检测结果上报 | 30天 |
| `topic.ugc.batch-report` | 6 | UGC批量回传 | 7天 |
| `topic.playback.event` | 24 | 播放数据回传 | 3天 |
| `topic.appeal.created` | 3 | 申诉创建 | 30天 |
| `topic.system.dlq` | 3 | 死信队列 | 永久 |
---
## 六、部署架构
### 6.1 Kubernetes集群规划
| 集群 | 节点配置 | 用途 |
|------|---------|------|
| **业务集群** | 6~10台 8C16G | API网关、业务服务、管理后台 |
| **检测集群** | 4~8台 8C16G + 2~4台 GPU(A10) | 爬虫、检测引擎、指纹提取、AI推理 |
| **存储集群** | 3台 4C8GPG主从)+ 3台 8C32GMilvus+ 3台 4C8GClickHouse | 数据库 |
| **消息集群** | 3台 4C8G | Kafka + ZooKeeper |
### 6.2 GPU资源规划
| 用途 | GPU型号 | 数量 | 说明 |
|------|---------|------|------|
| 视频指纹提取 | A10 | 2~4张 | ResNet50深度模型推理 |
| 音频指纹提取 | 无需GPU | — | Constellation Map纯信号处理,CPU即可 |
| AI视频语义 | A10 | 1~2张 | CLIP多模态模型推理 |
| AI音频语义 | A10 | 1张 | Whisper语音识别+音频Embedding |
| 水印嵌入/提取 | 无需GPU | — | DCT/DSSS变换,CPU计算 |
### 6.3 网络架构
```
互联网 ←→ 广电云安全网关 ←→ API网关(Kong) ←→ 业务服务集群
├── 检测集群(内网,不对外)
├── 存储集群(内网)
└── 消息集群(内网)
平台用户 ←→ 互联网 ←→ API网关 ←→ 业务服务
监管人员 ←→ 广电专网 ←→ 管理后台 ←→ 业务服务
```
---
## 七、团队分工与协作
### 7.1 团队划分
| 团队 | 负责模块 | 人数 | 技术栈 |
|------|---------|------|--------|
| **后端团队** | api-gateway, cc-code-svc, verify-svc, ugc-code-svc, takedown-svc, appeal-svc, live-monitor-svc | 6~8人 | Go, Gin, GORM, Kafka, PostgreSQL, Redis |
| **检测团队** | probe-crawler, probe-detector, live-monitor-svc(Python部分) | 4~6人 | Python, Scrapy, Playwright, FastAPI, Celery |
| **算法团队** | fingerprint-svc, watermark-svc, ai-semantic-svc | 4~6人 | Python, PyTorch, FFmpeg, librosa, Rust |
| **前端团队** | admin-frontend | 2~3人 | React, Ant Design, ECharts |
| **运维团队** | K8s, CI/CD, 监控, 存储, 消息 | 3~4人 | Kubernetes, Prometheus, Kafka, PostgreSQL |
| **平台对接团队** | 平台SDK、对接文档、技术支持 | 3~4人 | Go, Java, 技术文档 |
### 7.2 模块与团队映射
```
后端团队(Go
├── api-gateway ─────────── 独立开发
├── cc-code-svc ─────────── 复用TCS-IPTV代码,独立开发
├── verify-svc ──────────── 复用TCS-IPTV代码,独立开发
├── ugc-code-svc ────────── 独立开发
├── takedown-svc ────────── 独立开发,与检测团队协作(下架验证)
├── appeal-svc ──────────── 独立开发
└── live-monitor-svc ────── 与检测团队协作(切片送检)
检测团队(Python
├── probe-crawler ───────── 独立开发
├── probe-detector ──────── 与算法团队协作(调用检测引擎)
└── live-monitor(Python) ── 与后端团队协作(调度层)
算法团队(Python/Rust
├── fingerprint-svc ─────── 独立开发,开源参考多
├── watermark-svc ───────── 独立开发,难度最高
└── ai-semantic-svc ─────── 独立开发
前端团队(React
└── admin-frontend ──────── 与后端团队协作(API对接)
运维团队
├── K8s集群 ─────────────── 所有团队提供基础设施
├── 存储集群 ─────────────── PG/Redis/Milvus/ClickHouse/MinIO
├── 消息集群 ─────────────── Kafka
└── CI/CD ──────────────── 所有团队提供流水线
平台对接团队
├── 平台SDK(Go/Java)──── 独立开发
├── 对接文档 ─────────────── 独立编写
└── 技术支持 ─────────────── 协助各平台对接
```
### 7.3 团队间接口契约
| 接口 | 提供方 | 消费方 | 协议 |
|------|--------|--------|------|
| CC码验证API | 后端团队 | 平台对接团队→各平台 | REST HTTP |
| 下架指令事件 | 后端团队(takedown-svc) | 检测团队(probe-detector) | Kafka |
| 检测任务事件 | 检测团队(probe-crawler) | 算法团队(probe-detector) | Kafka |
| 指纹提取请求 | 检测团队 | 算法团队(fingerprint-svc) | gRPC |
| 水印提取请求 | 检测团队 | 算法团队(watermark-svc) | gRPC |
| AI语义请求 | 检测团队 | 算法团队(ai-semantic-svc) | gRPC |
| 管理后台API | 后端团队 | 前端团队 | REST HTTP |
| 指纹向量存储 | 算法团队 | 运维团队(Milvus) | Milvus SDK |
| 检测日志写入 | 检测团队 | 运维团队(ClickHouse) | ClickHouse SDK |
### 7.4 协作里程碑
| 里程碑 | 时间 | 涉及团队 | 交付物 |
|--------|------|---------|--------|
| API契约冻结 | 第2周 | 后端+前端+平台对接 | 所有REST API OpenAPI文档 |
| gRPC契约冻结 | 第3周 | 检测+算法 | 检测引擎Protobuf定义 |
| Kafka Topic定稿 | 第3周 | 后端+检测+运维 | Topic schema + 分区规划 |
| 数据库schema定稿 | 第4周 | 后端+运维 | DDL脚本 + ER图 |
| 基础设施就绪 | 第6周 | 运维 | K8s集群+PG+Redis+Kafka |
| 第一阶段联调 | 第10周 | 后端+前端+平台对接 | 试点平台跑通验证流程 |
| 检测引擎联调 | 第16周 | 检测+算法 | 爬虫→检测→告警全链路 |
| 全链路联调 | 第24周 | 全部团队 | 平台门禁+网络探针完整闭环 |
---
## 八、关键技术难度评估
### 8.1 难度分级总览
| 技术模块 | 难度 | 周期 | 负责团队 | 关键风险 |
|---------|------|------|---------|---------|
| CC码生成与生命周期 | ⭐⭐ 低 | 4周 | 后端团队 | 复用现有代码,风险低 |
| 四关验证API | ⭐⭐ 低 | 3周 | 后端团队 | Redis缓存一致性 |
| UGC批量赋码 | ⭐⭐ 低 | 3周 | 后端团队 | 并发序号分配 |
| 秒级下架分发 | ⭐⭐⭐ 中等 | 6周 | 后端团队 | 多平台并行+幂等+确认 |
| 直播监管调度 | ⭐⭐⭐ 中等 | 8周 | 后端+检测 | 实时流并发调度 |
| 网络探针爬虫 | ⭐⭐⭐ 中等 | 8周 | 检测团队 | 反爬对抗 |
| 检测引擎编排 | ⭐⭐⭐⭐ 较难 | 10周 | 检测+算法 | 多种检测手段分级编排 |
| 视频水印 | ⭐⭐⭐ 中等 | 3~6个月 | 算法团队 | 抗裁剪+抗压缩鲁棒性调优 |
| 音频水印 | ⭐⭐⭐⭐ 较难 | 6~9个月 | 算法团队 | 抗翻录是公认难题 |
| 视频指纹 | ⭐⭐ 低 | 2~3个月 | 算法团队 | 指纹库规模扩大后检索性能 |
| 音频指纹 | ⭐⭐ 低 | 2~3个月 | 算法团队 | 工程化即可 |
| AI语义理解 | ⭐⭐⭐ 中等 | 3~4个月 | 算法团队 | 模型部署+推理优化 |
| 监管后台 | ⭐⭐ 低 | 8周 | 前端团队 | 业务逻辑复杂但技术难度低 |
### 8.2 关键技术难点与应对
#### 难点1:音频水印抗翻录(难度⭐⭐⭐⭐)
| 项 | 说明 |
|----|------|
| 问题描述 | 安静环境翻录提取率>70%,嘈杂环境下降明显 |
| 应对方案 | ①音频指纹作为主力识别技术,水印作为补充追溯;②持续优化心理声学模型参数;③多段冗余嵌入 |
| 降级策略 | 水印提取失败时自动切换到音频指纹比对 |
| 开源参考 | audiowmark(⭐569), Audio-Watermarking, carnation-radio |
#### 难点2:视频水印鲁棒性(难度⭐⭐⭐)
| 项 | 说明 |
|----|------|
| 问题描述 | 需同时抗压缩、抗裁剪、抗转码 |
| 应对方案 | ①DWT-DCT-QIM三重变换增强鲁棒性;②多帧冗余嵌入;③大量对抗测试调优 |
| 开源参考 | VidMark(DWT-DCT-QIM), open-video-watermark, video-invisible-watermark |
#### 难点3:秒级下架全网同步(难度⭐⭐⭐)
| 项 | 说明 |
|----|------|
| 问题描述 | 一条指令需同时通知多个视频平台+音频平台+CDN,保证秒级到达+幂等+确认追踪 |
| 应对方案 | ①Kafka 24分区并行分发;②指令ID去重保证幂等;③超时3秒重试2次;④未确认自动告警 |
#### 难点4:检测引擎分级编排(难度⭐⭐⭐⭐)
| 项 | 说明 |
|----|------|
| 问题描述 | 水印→指纹→AI语义三级检测,需智能编排,不同内容走不同检测路径 |
| 应对方案 | ①快速筛查(元数据验证)→重点检测(指纹比对)→深度检测(水印+AI);②置信度阈值动态调整;③误判案例反哺模型 |
#### 难点5:爬虫反爬对抗(难度⭐⭐⭐)
| 项 | 说明 |
|----|------|
| 问题描述 | 主流平台反爬策略持续升级 |
| 应对方案 | ①代理IP池轮换;②Playwright浏览器自动化;③请求频率控制;④群众举报补充 |
### 8.3 自研难度评估与落地策略
| 技术模块 | 自研难度 | 预估周期 | 难点分析 | 落地策略 |
|---------|---------|---------|---------|---------|
| **视频水印** | ⭐⭐⭐ 中等 | 3~6个月 | DCT+QIM经典学术成果,难点在鲁棒性调优 | 先采购国产商用快速集成(3个月),同步自研(6个月)替换 |
| **音频水印** | ⭐⭐⭐⭐ 较难 | 6~9个月 | DSSS+心理声学模型复杂,抗翻录是公认难题 | 自研为主,基于开源算法改进 |
| **视频指纹** | ⭐⭐ 低 | 2~3个月 | ResNet50现成模型,工程集成 | 直接自研,1个PyTorch工程师 |
| **音频指纹** | ⭐⭐ 低 | 2~3个月 | Shazam算法公开20年,工程化即可 | 直接自研,1个Python工程师 |
**双轨落地路线**
```
快速落地(3个月内):
├── 视频水印 → 采购国产商用方案集成上线
├── 音频水印 → 基于开源算法改进,自研MVP上线
├── 视频指纹 → 自研MVP上线
└── 音频指纹 → 自研MVP上线
自主可控(6~12个月):
├── 视频水印 → 自研版替换国产商用方案
└── 音频水印 → 自研版持续优化抗翻录能力
```
### 8.4 开源参考项目
| 技术模块 | 开源项目 | 语言 | License | 说明 |
|---------|---------|------|---------|------|
| **视频水印** | [VidMark](https://github.com/AlexAgents/VidMark) | Python | MIT | DWT-DCT-QIM完整实现 |
| **视频水印** | [open-video-watermark](https://github.com/fabriziosalmi/open-video-watermark) | Python | MIT | DCT频域水印+REST API |
| **视频水印** | [video-invisible-watermark](https://github.com/JumiRay/video-invisible-watermark) | Python | MIT | YUV亮度通道DCT嵌入 |
| **音频水印** | [audiowmark](https://github.com/swesterfeld/audiowmark) | C++ | GPL-3.0 | ⭐569星,Patchwork算法 |
| **音频水印** | [Audio-Watermarking](https://github.com/dmeldrum6/Audio-Watermarking) | JS | — | DSSS+心理声学+Reed-Solomon |
| **音频水印** | [carnation-radio](https://github.com/Tranquil-Flow/carnation-radio) | Rust/TS | — | Masked DSSS+Painter-Spanias模型 |
| **音频指纹** | [audio-fingerprint-engine](https://github.com/rhthm/audio-fingerprint-engine) | Python | — | Constellation Map+PostgreSQL |
| **音频指纹** | [Audio-Fingerprint](https://github.com/inboxpraveen/Audio-Fingerprint) | Python | — | 生产级,3秒片段识别 |
| **音频指纹** | [AudioFingerprinting](https://github.com/ankitjosh78/AudioFingerprinting) | Python | — | FastAPI+librosa+麦克风实时 |
| **视频指纹** | ResNet50 + Milvus | Python | Apache-2.0 | torchvision+Milvus SDK |
---
## 九、分阶段开发计划
### 第一阶段(3个月):平台门禁上线
| 交付物 | 负责团队 | 技术难度 |
|--------|---------|---------|
| api-gateway | 后端+运维 | ⭐⭐ |
| cc-code-svc | 后端 | ⭐⭐ |
| verify-svc | 后端 | ⭐⭐ |
| takedown-svc | 后端 | ⭐⭐⭐ |
| 平台SDKGo/Java | 平台对接 | ⭐⭐ |
| 管理后台(CC码+下架) | 前端+后端 | ⭐⭐ |
| K8s业务集群+PG+Redis+Kafka | 运维 | ⭐⭐ |
**对接目标**:IPTV平台 + 1~2家持证视频平台
**里程碑**:第3个月,试点平台上传验证+播出校验+秒级下架跑通
### 第二阶段(6个月):网络探针MVP + UGC赋码
| 交付物 | 负责团队 | 技术难度 |
|--------|---------|---------|
| ugc-code-svc | 后端 | ⭐⭐ |
| probe-crawler | 检测 | ⭐⭐⭐ |
| probe-detector | 检测+算法 | ⭐⭐⭐⭐ |
| fingerprint-svc(视频) | 算法 | ⭐⭐ |
| watermark-svc(视频) | 算法 | ⭐⭐⭐ |
| Milvus集群 | 运维 | ⭐⭐ |
| GPU检测集群 | 运维 | ⭐⭐ |
**对接目标**:短视频平台 + 1~2家音频平台
**里程碑**:第6个月,短视频平台批量赋码上线,日检测5000条,准确率≥90%
### 第三阶段(9个月):存量补码 + 直播监管 + 音频扩展
| 交付物 | 负责团队 | 技术难度 |
|--------|---------|---------|
| 存量补码工具 | 后端 | ⭐⭐ |
| live-monitor-svc | 后端+检测 | ⭐⭐⭐ |
| 音频watermark-svc | 算法 | ⭐⭐⭐⭐ |
| 音频fingerprint-svc | 算法 | ⭐⭐ |
| ai-semantic-svc | 算法 | ⭐⭐⭐ |
| appeal-svc | 后端 | ⭐⭐ |
**里程碑**:第9个月,存量Top1000补码完成,50路直播实时监测,2家音频平台对接
### 第四阶段(12个月):全量运行
| 交付物 | 负责团队 |
|--------|---------|
| 全平台对接 | 平台对接 |
| 存量补码完成 | 后端+平台对接 |
| 网络探针全量 | 检测 |
| 完整监管闭环 | 全部团队 |
| 监管大屏 | 前端 |
**里程碑**:第12个月,全网视频+音频覆盖,完整告警+下架+验证+申诉闭环
### 第五阶段(15个月):音频监管优化
| 交付物 | 负责团队 |
|--------|---------|
| 音频指纹库完善(Top10000音乐+Top5000播客) | 算法 |
| 音频水印抗翻录加固 | 算法 |
| 翻唱/混音检测优化 | 算法 |
### 第六阶段(18个月):运营优化
| 交付物 | 负责团队 |
|--------|---------|
| 误判率优化(<2%) | 算法+检测 |
| 对抗测试(去水印/翻录/变速) | 算法 |
| 自动化运营(告警自动处理率>80%) | 检测+运维 |
| 全链路性能调优 | 全部团队 |
---
## 十、关键技术合作建议
### 10.1 水印技术合作
| 合作方向 | 合作方 | 合作模式 |
|---------|--------|---------|
| 视频水印快速落地 | 国产商用方案供应商(如海致BD) | 采购集成,3个月内上线 |
| 视频水印自研 | 高校信息隐藏实验室 | 联合研发,6个月出MVP |
| 音频水印自研 | 高校音频信号处理实验室 | 联合研发,基于开源算法改进 |
| 水印标准制定 | 广电总局+厂商+高校 | 联合标准组,统一视频+音频水印规范 |
### 10.2 指纹技术合作
| 合作方向 | 合作方 | 合作模式 |
|---------|--------|---------|
| 视频指纹 | 内部自研 | 1个PyTorch工程师,2~3个月 |
| 音频指纹 | 内部自研 | 1个Python工程师,2~3个月 |
| 指纹库建设 | 内容方+平台 | 平台提供内容指纹入库 |
### 10.3 AI语义技术合作
| 合作方向 | 合作方 | 合作模式 |
|---------|--------|---------|
| 视频语义理解 | 商汤/百度多模态API | 快速落地调用SaaS,后期自研 |
| 音频语义理解 | Whisper开源模型 | 自研部署,Triton推理服务化 |
| 模型训练 | 高校AI实验室 | 误判案例数据集联合训练 |
### 10.4 平台对接合作
| 合作方向 | 合作方 | 合作模式 |
|---------|--------|---------|
| 平台SDK | 内部开发 | Go+Java双语言SDK+完整文档 |
| 试点平台 | IPTV+持证视频平台 | 第一阶段对接,验证流程 |
| 短视频平台 | 抖音/快手/B站 | 第二阶段对接,UGC批量赋码 |
| 音频平台 | 喜马拉雅/蜻蜓FM | 第三阶段对接,音频赋码 |
---
## 十一、风险与应对
| 风险 | 等级 | 负责团队 | 应对方案 |
|------|------|---------|---------|
| 音频水印抗翻录不达标 | 高 | 算法团队 | 自研先验证再上线;音频指纹作为主力兜底 |
| 视频指纹库规模过大 | 中 | 算法+运维 | Milvus分布式集群,按内容类目分Collection |
| 爬虫被反爬阻挡 | 中 | 检测团队 | 代理IP池+Playwright+群众举报补充 |
| GPU资源不足 | 中 | 运维 | 分级检测策略,快速筛查用CPU,深度检测才用GPU |
| 平台对接进度滞后 | 中 | 平台对接 | SDK简化对接,提供Go/Java双语言+完整文档 |
| 直播检测延迟超标 | 中 | 检测团队 | 优先用水印/指纹(秒级),AI语义作为异步补充 |
| Kafka消息积压 | 低 | 运维 | Consumer Lag告警+自动扩容消费者 |
| PG单点故障 | 低 | 运维 | Patroni HA方案,一主两从,自动故障切换 |
| 多团队协作接口不一致 | 中 | 全部团队 | 第2~3周冻结API/gRPC/Kafka契约,CI校验 |
---
## 十二、与现有TCS-IPTV系统的关系
| 现有模块 | 复用方式 | 扩展内容 | 负责团队 |
|---------|---------|---------|---------|
| `internal/cccode` | 直接复用码段分配、序列号生成 | 扩展音频内容类型、码段冻结 | 后端团队 |
| `internal/api/handlers.go` | 复用验证、下架接口框架 | 增加音频验证、UGC批量、直播接口 | 后端团队 |
| `internal/chain` | 复用版权链交互 | 无需改动 | 后端团队 |
| `internal/config` | 复用配置管理 | 增加新服务配置项 | 后端团队 |
| `internal/monitor` | 复用Prometheus监控 | 无需改动 | 运维团队 |
| `cmd/api-svc/main.go` | 复用服务启动框架 | 拆分为多个独立微服务 | 后端团队 |
---
## 十三、项目管理建议
### 13.1 开发流程
```
需求评审 → API契约定义 → 技术方案设计 → 编码 → 单元测试 →
代码审查 → 集成测试 → 灰度发布 → 全量发布
```
### 13.2 CI/CD流水线
| 阶段 | 工具 | 说明 |
|------|------|------|
| 代码提交 | GitLab | 分支管理,MR评审 |
| 自动构建 | GitLab CI | Go编译、Python打包、前端构建 |
| 自动测试 | GitLab CI | 单元测试+集成测试 |
| 镜像构建 | Kaniko | 构建Docker镜像推送Harbor |
| 安全扫描 | Trivy | 镜像漏洞扫描 |
| 部署 | ArgoCD | GitOps自动部署K8s |
| 监控 | Prometheus+Grafana | 部署后指标监控 |
### 13.3 质量标准
| 指标 | 目标 |
|------|------|
| 单元测试覆盖率 | >80% |
| API契约一致性 | 100%CI校验) |
| 代码审查通过率 | 100% |
| P0故障修复时间 | <1小时 |
| P1故障修复时间 | <4小时 |
| 部署成功率 | >99% |