直播系统源码，架构如何设计

原创

钠斯音视频开发-林经理

发布于 2025-10-24 18:01:26

12200

代码可运行

文章被收录于专栏：音视频开发音视频开发

运行总次数：0

代码可运行

1 核心设计目标（先定方向）

功能性：主播推流、观众播放、房间管理、弹幕/聊天室、礼物/支付、录制回放、统计监控。
性能/延迟：支持 HLS/HTTP-FLV（常规）与 WebRTC（低延迟）扩展。
可扩展性：流媒体与业务分离、水平扩展、CDN 分发。
安全性：推流/播放鉴权、防盗链、防刷、合规支付。
可交付性：清晰模块、单元/集成测试、CI/CD、容器化部署。

2 总体架构（分层图 — 文本版）

Clients
 ├─ 主播(OBS/APP)  ---> (RTMP/WebRTC) ---> Flow Ingress (流媒体集群 SRS/ZLMediaKit)
 ├─ 观众(Web/Mobile) ---> (HLS / HTTP-FLV / WebRTC) ---> CDN / Flow Origin
 └─ Chat clients (WebSocket) ---> WS Cluster (Swoole/Node)
 
Backend Services (REST / RPC)
 ├─ API Gateway (Nginx / Kong)
 ├─ Auth Service (JWT / short tokens)
 ├─ Room Service (PHP/Laravel or Hyperf)  <-- DB (MySQL) & Cache (Redis)
 ├─ Stream Controller (Hooks for on_publish/on_close)
 ├─ Chat Service (Swoole WS) + Redis Pub/Sub
 ├─ Billing/Gift Service (orders/payments)
 ├─ Recorder/Transcoder (FFmpeg jobs /流媒体内置)
 └─ Admin/Operator UI

Storage & Infra
 ├─ MySQL (metadata)
 ├─ Redis (在线/限流/计数)
 ├─ Object Storage (OBS / S3 / MinIO) for recordings
 ├─ CDN for HLS/TS/FLV distribution
 ├─ Monitoring (Prometheus + Grafana)
 └─ Logging (ELK / Loki)

3 模块拆解与职责

流媒体层（SRS / ZLMediaKit / Nginx-RTMP）
- 接收 RTMP 推流、产出 HTTP-FLV/HLS、支持 WebRTC（若需低延迟）。
- 提供回调：on_publish（推流开始）、on_close（推流结束）、http-flv/hls url。
- 负责录制（可选）或转交给转码服务。
API / 业务后端（PHP）
- 房间、用户、权限、礼物、订单、播放 token 生成与校验、回放管理。
- 接收流媒体的回调（验证 stream_key、更新房间状态、写 streams 表）。
- 提供 REST API 给前端与移动端。推荐框架：Laravel（生态）/Hyperf（高并发）。
WebSocket / 实时消息（Swoole 或 Node.js）
- 弹幕、聊天室、连麦信令、观众实时在线列表。
- 使用 Redis Pub/Sub 做多进程/多节点消息广播。
存储层
- MySQL：用户、房间、订单、消息日志（长存或落库异步化）。
- Redis：在线人数、限流计数、短期 token、房间状态。
- OSS/S3/MinIO：录制文件、回放片段、静态资源。
转码/录制/任务调度
- ffmpeg 批量转码/合并 TS → MP4，或在流媒体服务器中直接配置录制。
- 使用消息队列（RabbitMQ / Kafka）分发转码/持久化任务。
CDN / 边缘分发
- HLS/TS/FLV 走 CDN，origin 仅承载少量请求，节省带宽。
监控/告警/日志
- 关键指标：在线房间数、推流数、流吞吐（带宽）、CPU、推流成功率、播放器错误率、延迟。
- 采集：Prometheus + node_exporter + srs_exporter；日志送 ELK/Loki。

4 关键数据流与序列（两个常见流程）

4.1 推流时序（主播用 OBS 推流）

主播从后台拿到 stream_key。
OBS 推到 rtmp://ingest.example.com/live/{stream_key}。
流媒体服务器触发 on_publish HTTP 回调到：POST /hook/on_publish（body: name=stream_key,user=...）
API 后端校验 stream_key 是否存在且有权限；若允许返回 2xx，流媒体开始接收流。
后端更新 rooms.is_live=1、写入 streams（start_at）、触发 Kafka/Redis 通知。
前端观众打开房间 → 请求 GET /room/{id}/play-token → 后端生成短期 play_token（HMAC + expire）并返回。
播放器用 http://origin.example.com/live/{stream_key}.flv?token=xxx 拉流；origin 校验 token（nginx-lua 或流媒体内置 hook），或 CDN 通过签名校验。

4.2 断流与回放生成

主播关闭推流 → 流媒体触发 on_close 回调。
后端更新 streams.stop_at，将录制文件（若有）异步触发转码任务（消息队列）。
转码完成后将回放上传到 OSS，写回 streams.record_url。

5 重要设计细节（每项给出实现建议）

5.1 鉴权：推流与播放

推流（长时）：使用 stream_key（生成时与房间绑定），并在 on_publish 回调再校验。可加 IP 白名单/时效。
播放（短时）：生成短期签名 token（HMAC-SHA256），携带 expire timestamp。播放端带 token 请求流，nginx lua 或流媒体 server 验签。示例 token payload：base64(roomId|exp|sig)。
API：用户登录用 JWT/Session（HTTPS 强制）。

5.2 弹幕/消息一致性

WebSocket 仅做实时通信，消息写库异步化（先写 Redis 队列，消费者落库）。避免主链路阻塞。
对重要消息（礼物/订单）用事务与幂等设计，避免重复计费。

5.3 低延迟策略

常规观看：HLS（兼容）或 HTTP-FLV（较低延迟 ~3-5s）。
需要 0.5–2s 延迟：使用 WebRTC（SRS/ZLMediaKit 支持），但复杂度高（信令、TURN、ICE、编码转码成本）。
建议分产品线：购物/电竞用低延迟，回放/宽带直播用 HLS。

5.4 转码、分辨率与带宽

在推流端限定编码参数（H.264 baseline/main, keyframe interval 2s）。
服务器侧可做多路转码（1080p/720p/480p），或用 CDN+转码服务按需转码（节约资源）。

5.5 存储与回放

录制切片策略（例如 5 分钟一个 TS），合并后转 MP4 存 OSS。
针对合规保留策略实现自动清理（按天/按付费等级）。

6 数据库核心表（示例，供直接用）

-- users, rooms, streams, messages, gifts, orders
CREATE TABLE users (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  username VARCHAR(64),
  password_hash VARCHAR(255),
  role TINYINT,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE rooms (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  owner_id BIGINT,
  title VARCHAR(255),
  stream_key VARCHAR(128) UNIQUE,
  is_live TINYINT DEFAULT 0,
  viewers_count INT DEFAULT 0,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE streams (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  room_id BIGINT,
  start_at DATETIME,
  stop_at DATETIME,
  record_url VARCHAR(512),
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE messages (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  room_id BIGINT,
  user_id BIGINT,
  type VARCHAR(32),
  content TEXT,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  INDEX(room_id)
);

CREATE TABLE orders (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  user_id BIGINT,
  room_id BIGINT,
  gift_id INT,
  amount INT,
  status VARCHAR(32),
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

7 API 设计（关键端点示例）

POST /api/v1/rooms — 创建房间（返回 stream_key）
POST /api/v1/hook/on_publish — 流媒体回调（验证推流）
POST /api/v1/hook/on_close — 断流回调
GET /api/v1/rooms/{id}/play-token — 获取短期播放 token
GET /api/v1/rooms/{id} — 房间详情（is_live、hls_url）
WS /ws?token=xxx — 弹幕/聊天室连接（token 校验）

8 安全策略（要点）

所有 API 强制 HTTPS。
播放、上传、对象存储使用带签名 URL（短期）。
防刷：礼物/接口限速（Redis 计数器），异常检测（风控规则）。
日志审计与异常告警（支付异常、刷礼物行为、异常推流）。

9 可扩展性 / 弹性设计

流媒体层：水平扩展多个流媒体节点，使用统一调度（DNS 或负载均衡），推流落地到近源节点。
读多写少：观众播放由 CDN/边缘负责，减少 origin 压力。
WS 集群：使用 Redis Pub/Sub 跨节点广播消息。
数据库：主从/读写分离，热点数据放 Redis，长短期分离表策略。
任务：转码/后处理交给异步 worker（K8s Job 或 CICD 管理的队列服务）。

10 运维与监控（必做）

监控指标：流数量、推流失败率、推流断流率、带宽使用、CPU、延迟、错误码分布。
日志采集：nginx/srs logs → ELK；应用 logs →集中化。
自动报警：Prometheus Alertmanager（带抑制规则）。
灾备：跨机房/多region 部署、CDN 多回源策略。

11 源码仓库与代码结构（单仓 + 微服务混合示例）

live-system/
├─ services/
│  ├─ api/                # PHP 后端 (Laravel/Hyperf)
│  │   ├─ app/
│  │   ├─ routes/
│  │   ├─ tests/
│  │   └─ Dockerfile
│  ├─ ws/                 # WebSocket 服务 (Swoole or Node)
│  │   └─ ...
│  ├─ streamer-hooks/     # Hook handlers for on_publish/on_close
│  └─ worker/             # 转码、录制后处理 worker
├─ infra/
│  ├─ srs/                # srs conf / docker-compose for local dev
│  ├─ nginx/              # nginx conf including lua token verify
│  └─ k8s/                # helm charts / manifests
├─ docs/
│  ├─ architecture.md
│  └─ runbook.md
├─ scripts/
│  └─ deploy.sh
└─ docker-compose.yml