我的毕业设计「视创奏协」开发全记录
写在前面
这是我的本科毕业设计项目——一个基于 Spring Cloud 微服务架构的视频协作审阅平台，产品取名叫**「视创奏协」**。
项目曾经短暂上线运营过，但很快我就主动把它下线了。不是因为功能做不出来，恰恰相反，是当我真正把它部署上线、投入真实使用场景之后，才发现了很多在学校实验室里、在代码调试中永远发现不了的现实问题。
这篇文章既是对毕业设计的完整总结，也是对这段从开发到上线再到下线经历的深度复盘，涵盖了微服务架构设计、云原生部署、视频处理技术选型、SaaS产品成本核算等多个方面的思考，配合完整的界面截图，希望能给做类似项目的同学一些参考。
项目背景：为什么要做视频审阅平台？
做过影视后期、视频创作的朋友应该都懂传统审片流程有多痛苦：
- 导出视频文件 → 发微信/QQ传给对方 → 对方看完回一句”3分20秒那个镜头改一下”
- 然后你要反复确认：“3分20秒是哪个画面？具体要改什么？”
- 意见分散在各个聊天记录里，改了一版又一版，最后谁也记不清哪条意见对应哪个版本
市面上不是没有成熟的在线审片产品，比如 Adobe Frame.io、国内的阅流等，它们在视频协作批注方面已经做得相当不错。但在2025年做项目调研时，我发现两个问题：
- 很少有产品把 AI大模型内容审核 深度整合进视频审阅工作流中
- 很多产品还是单体架构，在团队并发量高的时候容易出现性能瓶颈，而云原生微服务架构凭借优秀的扩展性和弹性伸缩能力，正在成为企业级应用的主流选择
于是，结合我在校期间学习的微服务和云原生知识，就有了这个基于 Spring Cloud 的视频审阅平台项目。
技术栈选型：云原生全链路实践
整个项目从设计之初就完全按照云原生理念进行技术选型，完整跑通了从代码提交到容器编排部署的全流程：
前端技术栈
- Vue 3 + Element Plus：主流前端框架和组件库，开发效率高
- XGPlayer：字节跳动开源的Web视频播放器，这是个非常关键的选型。它能让原本不支持流式加载的普通MP4文件，实现端侧按需分段加载，省去了服务器端提前转码切片的开销，在项目初期帮了大忙
- Vite构建工具，开发体验流畅
后端微服务技术栈
- Spring Boot + Spring Cloud：微服务全家桶，这也是毕业设计的核心技术点
- Nacos：服务注册发现与配置中心，直接使用阿里云微服务引擎MSE，省去了自己部署运维的麻烦
- Spring Cloud Gateway：统一API网关，处理路由、鉴权、限流等横切关注点
- MyBatis-Plus：持久层框架，单表CRUD操作非常便捷
- JWT双令牌认证：Access Token + Refresh Token机制，实现无感刷新用户登录状态
- OpenFeign：微服务之间的声明式服务调用
数据存储方案
- MySQL（阿里云PolarDB）：存储用户、项目、批注等结构化业务数据
- Redis（阿里云Tair）：缓存热点数据、存储验证码、处理分布式会话
- 阿里云OSS对象存储：存储视频文件和图片资源，采用前端直传方案，文件数据流不经过后端服务器，大大节省了带宽和服务器压力
DevOps与部署运维
- Docker：所有服务都容器化打包，环境一致性有保障
- Kubernetes (K8s)：集群编排调度，实现服务的高可用部署和弹性伸缩，最终部署在3台2核4G配置的ARM服务器上
- GitHub Actions：CI/CD流水线，代码提交到main分支后，通过QEMU自动构建AMD64与ARM64双架构Docker镜像，自动推送到阿里云容器镜像服务ACR
- 阿里云Green内容审核：接入大模型视觉审核能力，实现AI智能视频内容检测
Nacos服务注册中心中运行的所有微服务实例列表：
阿里云ACR容器镜像仓库中存储的各服务Docker镜像：
配合GitHub Actions实现了完整的自动化CI/CD流水线，从代码提交到镜像构建推送再到部署更新，全程无需人工干预：
整个系统最终部署在K8s集群上，五个核心微服务都以多副本方式运行，保证高可用性：
系统架构设计解析
这部分放一些架构图和流程图，给想要学习微服务设计的同学做参考。整体架构按照云原生理念设计，采用分层架构思想：
整体系统分层架构
系统从下到上分为基础设施层、数据持久层、业务服务层、服务治理层、接入层和表现层共六层：
微服务模块划分
按照领域驱动设计（DDD）的思路，将系统拆分为五个独立的微服务，每个服务有自己独立的数据库，服务之间通过OpenFeign进行调用：
核心流程设计
JWT双令牌认证鉴权流程
系统采用Access Token + Refresh Token的双令牌机制，Access Token有效期短降低泄漏风险，过期后通过Refresh Token无感刷新，网关层统一处理鉴权逻辑：
项目成员邀请流程
通过JWT令牌生成带过期时间的邀请链接，被邀请人点击链接登录后即可加入项目：
OSS预签名直传时序图
为了节省后端服务器带宽，文件上传下载都采用预签名URL直传方案，前端直接与OSS对象存储交互，后端只做权限校验和URL签发：
视频评审工作流程图
视频上传后进入评审流程，评审人员可以发表带时间戳的批注，对批注进行回复讨论，最终标记审核状态：
AI异步内容审核时序图
内容审核采用异步调用方式，不阻塞用户操作，审核完成后回调更新结果：
数据库设计
数据库设计遵循阿里Java开发规范，不在数据库层使用外键，所有关联通过代码逻辑实现。主键采用UUID v7标准，既保证分布式环境下的唯一性，又具有基于时间的有序性。
整体ER图如下：
核心功能实现：五个微服务模块
整个系统按照领域驱动设计的思路，拆分成了五个独立的核心微服务：用户管理服务、项目管理服务、文件管理服务、批注管理服务、内容审核服务，服务之间通过OpenFeign进行调用。
1. 用户管理与权限系统
- 支持手机号、邮箱双注册方式，集成图形验证码、短信验证码、邮箱验证码三重验证
- JWT双令牌认证机制，Access Token过期后自动用Refresh Token刷新，用户无感知
- 项目内三级角色权限体系：项目创建者（所有者）、项目管理员、普通成员，不同角色拥有不同操作权限
登录注册界面集成了图形验证码，有效防止机器批量注册：
系统登录页面，支持用户名/邮箱/手机号多种方式登录：
2. 项目全生命周期管理
- 项目状态流转：待开始 → 进行中 → 已完成 → 已归档，完整覆盖影视项目生产流程
- 支持生成带过期时间的邀请链接，方便团队成员快速加入项目
- 项目控制台展示资源概览统计，包括文件数量、批注数量、存储占用等数据
登录后进入的项目控制台Dashboard，左侧是项目列表，右侧展示项目概览：
创建新项目界面：
项目状态可以在待开始、进行中、已完成、已归档之间流转切换：
项目信息编辑界面：
项目成员管理界面，可以查看所有成员及其角色：
生成项目邀请链接，支持设置链接过期时间：
3. 文件管理与OSS存储
- OSS预签名URL直传：前端向服务器请求临时授权后，直接将文件上传到阿里云OSS，不占用后端服务器带宽，上传速度更快
- 多级文件夹嵌套结构，支持文件夹创建、重命名、移动操作
- 面包屑导航：在目录层级较深时，用户可以清晰看到当前路径并快速跳转到任意上级目录
- 完整的两级回收站机制：普通删除只是逻辑删除，文件进入回收站，支持一键恢复；确认彻底删除才会物理删除文件并释放OSS存储空间，有效防止误操作
点击上传文件按钮弹出的上传选择窗口：
文件上传过程中显示实时进度条：
右键点击文件或文件夹弹出的上下文操作菜单：
删除文件时的防误触确认机制，需要输入完整文件名才能确认删除：
多级文件夹配合面包屑导航，影视项目中再多的素材文件也能条理清晰地管理：
考虑到影视项目中误删素材可能造成严重后果，专门设计了完整的回收站功能，删除的文件默认保留30天，可以随时恢复：
从回收站恢复文件时的确认弹窗：
彻底删除文件时需要手动输入”确认删除”才能永久清除数据：
4. 核心功能：视频时间戳批注审阅
这是整个视频审阅平台最核心的功能，也是区别于普通云盘的关键特性。
- 播放器进度条打点功能：用户发布批注时，系统自动记录当前视频播放时间戳，在播放器进度条上生成带有批注人头像的蓝色锚点标记
- 点击进度条上的头像锚点，或者点击右侧批注卡片，视频会自动跳转到对应的时间点，精准定位到需要修改的画面
- 批注支持多层级回复，可以针对某条意见展开讨论，形成完整的审阅讨论线程
- 视频审核状态标记：可以为视频设置待审核、审核中、已通过、需修改等状态，鼠标悬停还能查看完整的状态变更历史记录
视频评审主界面，左侧是XGPlayer播放器，右侧是评审意见面板，团队成员可以实时看到所有批注：
在播放器下方输入框输入批注内容，发送时自动绑定当前视频时间戳：
进度条上的蓝色圆形头像锚点就是批注打点，点击即可直接跳转到对应画面：
批注支持多层级回复，可以针对某条意见展开讨论：
可以为视频设置审核状态标记（待审核、审核中、已通过、需修改等）：
鼠标悬停在状态按钮上可以查看完整的审核状态变更历史记录：
5. AI智能内容审核
这是本项目区别于当时市面上其他同类产品的一个差异化功能点。接入了阿里云Green内容审核服务的大模型视觉审核能力，可以对视频进行逐帧检测：
- 识别涉黄、涉暴、涉政等违规内容
- 检测广告引流、二维码、第三方链接等内容
- 对每个风险点给出时间戳位置、风险类型和置信度评分
- 按风险等级（高风险、中风险、低风险、通过）分类展示结果
AI智能审核完成后，会列出所有检测到的风险帧概览：
点击进入详情可以查看每个风险帧的具体内容、时间戳和置信度，点击还可以直接跳转到对应视频时间点：
上线运营遇到的现实问题：为什么决定下线？
代码写完、功能测试通过、毕业论文答辩顺利结束后，我就把项目正式部署上线了，想着说不定真的能吸引一些小工作室或者创作者来用。
但现实很快就给我上了一课。上线运营不到一个月，我就做出了决定——主动把项目下线。原因不是技术上做不出来，而是一系列在开发阶段没有充分考虑到的现实问题：
1. OSS对象存储与流量成本太高，个人开发者难以承受
视频类产品和普通图文类产品完全不同，存储成本其实只是小头，下行流量费用才是真正的成本黑洞。
一个几百MB的视频文件，只要有几个人来回看几遍，流量费就蹭蹭往上涨。阿里云OSS的流量费用不低，个人开发者根本没有办法和大厂的带宽成本优势相比。如果用户量真的做起来，流量费用可能是个天文数字；如果用户量做不起来，那项目本身也没有持续运营的意义。这是一个很尴尬的死循环。
2. 视频转码方案悬而未决，技术选型存在分歧
项目开发阶段为了赶进度，我利用XGPlayer的特性直接播放原片MP4，没有做服务端转码处理。但上线后实际使用发现问题很多：
- 不同编码格式（H.264、H.265、AV1等）的视频在不同浏览器上兼容性不一致
- 没有多码率自适应，用户网络环境差的时候会频繁缓冲
- 大体积视频加载慢，拖动进度条响应延迟明显
视频转码有两条技术路线，我一直没下定决心选哪个：
- 云服务商转码API（如阿里云媒体处理）：省心省事，转码效果好，还能自动做加密和多码率适配，但是按分钟计费，长期使用成本很高
- 本地服务器FFmpeg转码：一次性投入服务器成本，后续没有持续费用，但是需要高性能服务器，最好配备GPU加速转码，而且自己要处理分布式转码队列、容错等问题
这个核心技术决策点到项目下线也没有找到完美的解决方案。
3. 微服务架构过重，不适合中小工作室私有化部署
做毕业设计的时候满脑子想的都是”云原生”、“微服务”、“高可用”，觉得架构越复杂越能体现技术水平。
但真正上线后才发现，五个微服务 + Nacos注册中心 + Gateway网关 + MySQL + Redis + Kubernetes，这一整套技术栈部署运维的复杂度极高。别说普通的影视工作室了，就算是懂点技术的个人用户，看着这套架构也会头大。人家本来只是想找个简单方便的工具审个片子，你让人家先学习K8s概念、搭建一套集群？这完全不现实。
架构选型从来不是越新越好、越复杂越好，而是合适最重要。对于这种规模的产品，单体架构或者简单的模块化单体可能才是更务实的选择。
4. 产品核心卖点差异化不足，市场竞争激烈
虽然我加入了AI内容审核功能，但说实话，这并不是视频审阅产品的核心痛点。
用户选择一个审片工具，最核心的需求永远是”方便地在视频上打点批注、团队成员协作讨论、版本对比”。在这些核心功能上，Frame.io、阅流等成熟产品已经积累了多年，做得非常完善了。我的产品虽然技术栈很新，但在核心体验上并没有形成足够强的差异化，没有给用户一个必须从成熟产品迁移过来的理由。
5. 计费模式不清晰，商业模式没想明白
To C用户按量计费？还是To B团队包月订阅？还是私有化部署一次性收费？
这些最根本的商业问题，我在开发阶段完全没有认真考虑过。等真正上线了才发现，写代码其实是最简单的部分，定价策略、用户获取、成本控制这些商业问题，比写代码难上十倍百倍。
经过一段时间的思考，我终于想明白了：这种视频审阅产品的形态，其实更适合 To B私有化部署，而不是做面向公众的公有云SaaS服务。
后续计划：开源归档与新项目启动
虽然这个版本的产品下线了，但这段经历带给我的经验和思考是非常宝贵的。接下来我有两个方向的计划：
1. 项目代码开源归档
我准备把这个项目的代码整理之后在GitHub上开源，作为毕业设计的完整交付，也给想要学习Spring Cloud微服务开发、Kubernetes云原生部署、Vue3前端开发的同学提供一个可参考的完整项目案例。
代码不算完美，架构设计上也走了弯路，但从前端到后端、从CI/CD到容器编排，整套流程是完整跑通了的，作为学习项目应该还是有参考价值的。开源后代码会处于归档状态，不会再继续添加新功能，就让它作为本科阶段的一个纪念安安静静待在那里。
2. 启动新项目：面向飞牛OS的Docker版视频审阅工具
这次踩了这么多坑之后，我反而更想把视频审阅这件事做对、做精简。我准备在这个项目的经验基础上，启动一个全新的分支项目，核心思路完全转变：
- 专精小而美：不再盲目追求大而全的微服务架构，回归产品本质，把”视频打点批注”这一个核心功能做到极致好用
- Docker一键部署：面向飞牛OS（fnOS）、群晖等NAS系统，还有普通Linux服务器，一个Docker Compose配置文件就能跑起来，不需要懂K8s，个人用户和小型工作室都能轻松部署
- 混合云架构设计：本地NAS负责视频存储和FFmpeg转码计算，云端对象存储只负责CDN分发和播放网络加速，兼顾数据隐私、成本控制和播放体验
- 同时覆盖To C和To B场景：个人用户可以一键安装在自己的NAS上使用，小型团队也可以进行私有化部署，维护成本低，功能简洁不繁杂
新项目的具体方向大概就是这样，具体实现的时候还会根据实际情况调整。
经验总结与感悟
做完这个毕业设计项目，最大的收获不是学会了多少具体的技术框架，而是真正明白了一个道理： 写代码只是做产品的很小一部分。
在学校里做课程设计或者毕业设计，你只要把功能实现了、测试用例跑通了、论文写够字数了，就能拿高分。但当你真正把一个产品放到公开的互联网上，你会发现：
- 服务器要花钱，带宽要花钱，存储要花钱，甚至发短信验证码都要花钱，每一项资源都是成本
- 用户永远不会按照你设计的理想路径去使用你的产品，你要考虑各种异常场景和边缘情况
- 技术上最酷、最前沿的方案，往往不是商业上最合适、最经济的方案
- 架构设计不是越复杂越厉害，能匹配业务规模和团队能力的架构才是好架构
- 产品从0到1写出来不难，难的是从1到100持续运营和迭代
这个项目从商业角度来说不算成功，但它是我第一次真正意义上从头到尾完整走完一个产品从需求调研、技术选型、架构设计、编码开发、测试部署到上线运营、复盘反思的全流程。这些在开发和运营过程中踩过的坑，是书本上和课堂里学不到的宝贵经验。
特别感谢大三元传媒工作室的伙伴们，在系统功能设计期间从影视行业一线使用角度提出了很多宝贵的实战意见，让这个系统不只是一个纸上谈兵的毕业设计Demo，而是真的尝试按照实际生产场景来设计的。也感谢我的指导老师石生金老师，从架构论证到论文梳理都给予了悉心指导。
本科四年的学习生涯也快画上句号了，这个项目算是给自己大学阶段的技术学习一个交代吧。
等新项目有实质性进展了，我会再写文章更新。
项目代码地址：整理完成后会在GitHub公开，敬请期待。如果这篇文章对你有帮助，或者你对视频审阅工具、微服务开发、飞牛OS Docker应用感兴趣，欢迎持续关注我的博客。