74 lines
5.4 KiB
Markdown
74 lines
5.4 KiB
Markdown
# Hightube - 开源直播平台项目文档与实现方针
|
||
|
||
## 1. 项目概述
|
||
Hightube 是一个针对网络应用开发课程大作业的跨平台开源个人直播平台。旨在提供用户注册、登录、开启个人直播室以及实时评论（后续迭代弹幕）等互动功能。
|
||
|
||
## 2. 技术栈架构与评估
|
||
|
||
### 2.1 客户端 (Flutter)
|
||
- **目标平台**: Windows, Linux, Android, Web
|
||
- **优势**: 一套代码编译多端运行，UI 表现力强且一致性好。
|
||
- **挑战**: 桌面端和 Web 端的音视频采集（推流）和硬件加速播放（拉流）生态可能略逊于移动端，需仔细调研第三方插件的跨平台支持度（例如 `video_player`, `fvp` 等拉流插件；推流端前期可借用 OBS，后期再实现原生/插件推流）。
|
||
|
||
### 2.2 服务端 (Go 或 Rust)
|
||
- **推荐选型**: **Go** (Golang)。
|
||
- **理由**: 直播服务本质是一个处理大量高并发连接和音视频协议的网络应用。Go 的 Goroutine 并发模型非常适合处理长连接（如 WebSocket 和 RTMP 推拉流）。且 Go 拥有完善的流媒体和网络编程库，可以让你专注于业务逻辑而非底层内存管理，开发周期更贴合大作业的进度。
|
||
- **备选**: Rust。性能卓越且内存安全，是极佳的加分项，但处理复杂协议的学习曲线和开发成本较高。
|
||
|
||
### 2.3 数据库与存储
|
||
- **关系型数据库**: **SQLite**
|
||
- **理由**: 作为课程大作业初期/MVP版本，SQLite 轻量且无需额外配置服务端即可运行。
|
||
- **扩展性设计**: 直播和评论的并发写入特性，如果后续升级或实际部署，SQLite 的并发写性能可能是瓶颈。**建议在后端使用 ORM 框架（如 Gorm/SeaORM）**，这样可以利用同一套代码在未来无缝迁移至 PostgreSQL 或 MySQL。
|
||
|
||
## 3. 核心架构设计
|
||
|
||
系统将分为三个主要逻辑模块：
|
||
1. **API 服务 (业务后端)**: 处理用户认证（注册/登录/JWT）、直播间创建/配置管理、获取推流凭证（Stream Key）、以及持久化历史评论。
|
||
2. **Media 服务 (流媒体中心)**: 核心服务。负责接收主播的音视频流（推荐使用 RTMP 协议接入），并将其分发（转封装/转码）给观众端（例如 HTTP-FLV, HLS 或 WebRTC）。初期可以将该服务与 API 服务跑在同一个进程内。
|
||
3. **互动服务 (WebSocket)**: 为当前活跃的直播间提供低延迟的实时评论广播和弹幕分发通道。
|
||
|
||
---
|
||
|
||
## 4. 阶段性迭代计划 (Roadmap)
|
||
|
||
本项目采用敏捷开发、逐步迭代的策略，从核心底层做起，直至完善前端交互。
|
||
|
||
### Phase 1: 核心流媒体服务构建 (推拉流基石)
|
||
*目标：跑通纯流媒体的“推、拉”数据通路，这是整个项目的核心难点。*
|
||
1. **技术确认**: 确定后端的开发语言与流媒体协议（首选 RTMP 接收，HTTP-FLV / HLS 分发）。
|
||
2. **服务端搭建**: 实现 TCP 监听，能够解析基础的推流握手和音视频数据包包头（可手写核心逻辑或引入开源基础库辅助）。
|
||
3. **推流测试**: 不写前端推流代码，直接使用第三方工具（如 OBS Studio）配置推流地址向我们的本地服务器推流。
|
||
4. **拉流测试**: 不写前端播放器，直接使用本地播放器（如 VLC）或基于网页的测试工具（flv.js）测试拉取直播流。
|
||
|
||
### Phase 2: 基础业务 API 与数据库搭建
|
||
*目标：建立平台的基本业务逻辑和数据存储，实现账号与权限控制。*
|
||
1. **数据库设计**: 引入 ORM，设计基本的 `users` (用户表) 和 `rooms` (直播间表)。
|
||
2. **API 开发**:
|
||
- 用户注册与登录，颁发 JWT Token。
|
||
- 获取/重置个人专属推流密钥（Stream Key）。
|
||
- 获取当前活跃状态的直播间列表。
|
||
3. **安全鉴权**: 改造 Phase 1 的流媒体服务，在接收推流时校验推流地址中的 Stream Key 是否合法并对应正确的用户房间。
|
||
|
||
### Phase 3: 客户端 MVP 版本构建 (观看端)
|
||
*目标：用户可以使用我们自己的 Flutter 客户端进行注册并观看直播。*
|
||
1. **Flutter 框架初始化**: 搭建跨端项目架构，配置网络请求拦截器（携带 Token）。
|
||
2. **基础 UI 开发**:
|
||
- 登录与注册页面。
|
||
- 平台首页（大厅），展示通过 API 获取的直播列表卡片。
|
||
- 直播间详情页。
|
||
3. **播放器集成**: 引入并在四个平台上跑通 Flutter 视频播放插件，实现在直播间页面动态加载 HTTP-FLV 或 HLS 流媒体链接。
|
||
|
||
### Phase 4: 实时互动服务 (评论系统)
|
||
*目标：增加平台的社交互动性。*
|
||
1. **后端 WebSocket 服务**: 建立基于 `room_id` 的 WebSocket 广播群组（Hub 模式）。
|
||
2. **前后端联调**: 客户端进入直播间后自动连接 WebSocket 服务，实现收发消息。
|
||
3. **弹幕预演**: 客户端除了在底部展示聊天列表外，开始尝试利用 Flutter 的 `Stack` 布局机制，实现简单的文字横向漂移弹幕层。
|
||
|
||
### Phase 5: 客户端开播体验 (完全体)
|
||
*目标：摆脱 OBS，使用我们的应用自行调用软硬件资源进行推流开播。*
|
||
1. **开播 UI**: 客户端新增“主播控制台”界面。
|
||
2. **多端推流探究**: 调研 Flutter 中的音视频采集和推流插件（如 `flutter_webrtc` 或相机结合底层编码推流库）。
|
||
3. **整体整合与测试**: 对四大平台进行兼容性测试、性能调优和 UI 美化，准备课程答辩演示。
|
||
|
||
---
|
||
*本文档将作为整个大作业项目的开发基准与进度追踪参考。* |