# CC码音视频监管系统——系统设计和开发方案

> 用于指导系统开发工作、多团队分工协作和关键技术合作
> 编制日期：2026年7月

---

## 一、项目概述

### 1.1 项目目标

建设CC码音视频监管系统，实现全网所有音视频内容的统一编码、实时验证、自动检测、秒级下架和全生命周期监管。

### 1.2 核心能力

| 能力 | 说明 | 响应速度 |
|------|------|---------|
| 平台门禁 | 各平台调用API在上传/播出/CDN/终端四个环节验证CC码 | 秒级 |
| 网络探针 | CC码中心独立运行的爬虫巡查+水印提取+指纹比对+AI语义识别 | 分钟级 |
| 秒级下架 | 一条指令全网同步下架（视频平台+音频平台+CDN） | 秒级 |
| UGC赋码 | 平台代理批量赋码，码段授权+本地赋码+异步回传 | 毫秒级 |
| 直播监管 | 直播/广播实时录制、切片检测、秒级断流 | 秒级~分钟级 |
| 申诉恢复 | 48小时申诉+24小时审核+秒级恢复 | 秒级恢复 |

### 1.3 系统边界

```
本系统负责                          各平台负责
─────────────                      ─────────────
· CC码生成、签发、生命周期管理        · 平台内业务流程
· 四关验证API                        · UGC内容审核
· 秒级下架指令分发                    · 水印嵌入（平台转码环节）
· 网络探针爬虫+检测                   · 播放数据回传
· 指纹库建设与维护                    · 下架指令执行
· 水印/指纹/AI检测引擎               · 申诉发起
· 监管后台+数据大屏
· 申诉审核
```

---

## 二、系统架构

### 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-gateway（API网关）

| 项 | 说明 |
|----|------|
| 语言 | Go |
| 框架 | Kong 3.x |
| 职责 | 统一API入口、JWT鉴权、API Key验证、限流、路由、日志 |
| 部署 | K8s Deployment, 3副本 |
| 性能目标 | 10万QPS |
| 依赖 | Redis（限流计数）、Vault（密钥） |
| 开发团队 | 后端团队 |

#### 3.2.2 cc-code-svc（CC码生成与生命周期管理）

| 项 | 说明 |
|----|------|
| 语言 | 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-svc（UGC批量赋码）

| 项 | 说明 |
|----|------|
| 语言 | 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-svc（AI语义理解）

| 项 | 说明 |
|----|------|
| 语言 | 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_records（CC码记录表）**：

| 字段 | 类型 | 说明 |
|------|------|------|
| 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台 4C8G（PG主从）+ 3台 8C32G（Milvus）+ 3台 4C8G（ClickHouse） | 数据库 |
| **消息集群** | 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 | 后端 | ⭐⭐⭐ |
| 平台SDK（Go/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% |