SSM与Django混合架构的在线视频网站开发全流程复盘

1. 项目整体设计与架构思路先说说这个项目的来历。早前有个做校园影视社团的朋友找我说社团每年拍了不少作品但一直靠百度网盘传来传去别人想看还得挨个申请链接很麻烦。想要一个“像B站那种”的网站能上传、能在线播放、能分类管理还要能控制谁能看。我当时一听这需求其实非常典型——本质上就是一个在线视频网站开发项目核心流程围绕“视频上传——转码——存储——在线播放——内容管理”这条链路展开。技术选型上标题里同时出现了Java和SSM、Django这不是笔误而是我当时真实采用的混合架构Java SSM 负责核心的后端API和视频处理调度Django 那套做了管理后台和内容运营界面。为什么这么拆下面我会把理由讲透包括为什么不在两者之间二选一以及两个框架之间怎么协作。这篇文章我就把整个项目从构想到落地的过程完整复盘一遍适合正在做视频类毕设、想搞个人视频站、或者刚接触流媒体服务开发的朋友参考。项目本身不算高深但视频编码、在线播放器、并发上传这些模块里确实藏着不少坑我把踩过的都整理出来了。1.1 需求拆解看似简单的视频站实际要处理三类核心问题做项目最怕的就是上来就写代码。先把需求拆清楚比什么都重要。视频网站的表面需求很简单——游客能浏览视频列表、注册用户能上传视频、管理员能审核和删除。但往深了挖有三个绕不开的技术问题第一是存储与分发问题。一个几分钟的短视频可能就有几十上百MB如果不做任何处理用户打开页面要加载半天。更麻烦的是不同用户网络环境差异很大有人千兆宽带有人还在用手机4G同一个视频很难一套参数都照顾到。所以视频不能“原样传上去就完事”必须做转码、抽封面、多清晰度适配。第二是内容管理问题。视频不是传上去就自动能播需要审核、分类、打标签、设置可见范围还要处理用户举报。这些内容运营操作如果都写在播放页面里代码会乱成一锅粥。所以我单独用Django做了一套后台管理界面把“面向用户的前台”和“面向运营的后台”彻底分开。第三是在线播放体验问题。播放器要支持拖动进度、清晰度切换、记忆播放位置还要适配备不同的浏览器和设备。这些需求单靠一个video标签往往搞不定我在项目里选用了成熟的HTML5播放器方案后台上传的视频统一转成MP4格式兼容性最好。把这三类问题想清楚架构基本就浮出水面了Java服务端做视频处理和核心接口Django做管理后台前端用现成播放器组件数据库负责记录视频元信息和用户行为。1.2 为什么选SSMDjango混合架构每个框架只做自己最擅长的事很多朋友看到标题里有Java又有Django第一反应是“这俩为什么要混着用”我当时也有过纠结。最开始想过全用SSM一把梭后来发现管理后台那些表格、筛选、统计页面如果用Java原生态写光增删改查就要写一大堆Controller和HTML模板效率太低了。Django自带Admin和数据模型管理做这类后台简直是为它量身定做的。反过来视频处理这块——包括调用FFmpeg转码、对接对象存储、处理上传的并发请求——我又觉得Java生态更顺手。SSM里的Spring管理事务和依赖很成熟MyBatis写复杂的SQL查询非常灵活遇到性能瓶颈也好排查。于是我把项目拆成两个服务视频服务端Java SSM负责视频上传接口、视频转码任务调度、播放地址生成、用户和权限体系、视频信息CRUD、播放量统计等核心业务。对外提供RESTful API。运营管理端Django负责管理员登录、视频列表管理、分类管理、审核状态流转、数据看板。它通过HTTP请求调用Java服务端提供的接口自己不直接碰视频文件。两个服务之间通过JSON格式的API通信数据表各自独立公共的数据通过接口同步。这样做的最大好处是两边的代码互不干扰前端、移动端将来要接入只要对接Java那套API就行Django后台再怎么改也不影响前台服务。1.3 数据库和表结构设计从视频元数据到用户行为在线视频网站的核心数据结构并不复杂但有些细节容易踩坑。我用MySQL作为主数据库主要设计了几张表用户表user除了常规的账号密码字段必须加上avatar头像地址、vip_level会员等级、status封禁状态。视频网站的用户体系跟普通博客不一样要考虑“上传者”和“观看者”双重身份所以我在表里加了upload_count字段方便做上传频率控制。视频信息表video这是整个项目的核心表。最基础的字段是标题、简介、分类ID、封面图URL。但有几个字段很多人都想不到——一个是original_name记录用户上传时的原始文件名防止因为重名而丢信息一个是storage_path记录视频文件的存储路径或对象存储Key还有一个是transcode_status转码状态字段我是用枚举值管理的0表示待转码1表示转码中2表示转码成功3表示转码失败。这个字段看起来不起眼实际开发中救了我无数次。如果不记录状态转码任务一多你根本不知道哪个视频到底好了没有。分类表category简单的树形结构用parent_id支持二级分类。比如“影视”下面可以分“电影”“剧集”“教程”下面分“Java”“Python”等。标签表tag和视频标签关联表video_tag做内容检索必备。视频网站如果只能靠分类筛选视频一多就找不到了。标签表让用户可以按“4K”“航拍”“教程”等维度搜索。此外还有评论表comment、收藏表favorite、播放记录表play_history。播放记录表我加了一个progress字段——记录用户上次播放到多少秒。这个功能在长视频网站属于刚需B站、爱奇艺都有“继续观看”功能就是靠这张表实现的。2. 核心技术点拆解视频上传、转码与播放链路架构搭好了接下来是视频网站最核心的“命脉”——视频文件从上传到播放的完整链路。这条链路做得好不好直接决定用户体感。我把整条链路拆成三段上传、转码、播放。每段都有不少值得说的细节。2.1 视频上传大文件怎么传才不卡、不怕断视频文件跟普通图片不一样动不动就几百MB如果按普通表单一次性POST上去会遇到三个问题请求超时、内存溢出、断点续传没法做。所以我的上传方案设计成“预签名上传 分片上传”。所谓“分片上传”就是把一个大文件切成若干小块我这边每片默认5MB前端拿到文件后先计算MD5然后逐片上传。Java服务端接收到分片后存储到临时目录等所有分片传完再合成完整文件。这个方案的好处是哪一片传失败了只需要重传那一片不用整个文件从头来。前端上传我用了Web Uploader的改良版不过现在用Vue的话可以考虑vue-simple-uploader原理都一样。关键点在于后端接口要设计好三个POST /api/upload/init初始化上传传文件名、文件大小、分片数量后端返回uploadId。POST /api/upload/part上传单个分片带上uploadId和分片序号。POST /api/upload/complete所有分片传完后通知后端合并文件。有件事必须提醒务必要在合并时校验文件完整性。我当时的做法是前端计算整个文件的MD5后端合并后也计算一次MD5两个值一致才认为上传成功。否则网络抖动导致分片错乱合并出来的文件可能会损坏播放的时候直接黑屏。上传时还有一个“并发控制”问题。Spring Boot默认的Tomcat最大并发线程是200如果所有人都同时在传大文件线程瞬间被打满。我当时的解决方案是把文件流写入操作放到异步线程池里执行Controller层只接收请求并立即返回“正在接收”的状态。这样前端可以继续传下一个分片后端也能把耗时的IO操作从请求线程里剥离出来。2.2 视频编码技术选型为什么所有视频都统一转成H.264视频编码是整个项目技术含量最高的部分也是很多人最陌生的部分。我直接说结论所有上传的视频最终都会被FFmpeg转成H.264编码、AAC音频、MP4封装格式。为什么选H.264原因很简单兼容性。H.264是当前浏览器和移动设备支持最广泛的视频编码格式。如果你想尝试H.265HEVC规格是更好、压缩率更高但很多浏览器不支持硬解用户看视频时CPU占用会飙升还会出现花屏、音画不同步问题。做网站不是搞科研选最稳的方案才是对的。FFmpeg的转码命令是我调试次数最多的部分。最基本的转码命令长这样ffmpeg -i input.mp4 -c:v libx264 -preset veryfast -crf 23 -c:a aac -b:a 128k output.mp4解释一下几个关键参数-preset veryfast编码速度预设从ultrafast到veryslow越快压缩率越低、CPU占用越低。网站场景我一般用veryfast兼顾转码速度和文件体积。-crf 23画质控制参数范围0到51越小画质越好、文件越大。23是偏均衡的取值电影级压制常用18但视频网站没必要那么奢侈。-b:a 128k音频码率。普通视频128k够了音乐类视频建议192k。针对不同清晰度我会生成多个版本比如一个1080p版本给大屏用户一个720p版本给大多数用户一个480p版本给手机流量用户。转码不是简单“跑一遍命令”而是要把原视频按比例缩放所以我在Java代码里调用FFmpeg时会用-vf scale1280:720这类参数强制宽度。关于多清晰度切换我有一个经验教训音频参数在不同清晰度之间保持一致。因为播放器切换清晰度时如果音频编码参数不一致容易产生短暂卡顿甚至音画不同步。所以我把音频转码参数固定了只调整视频分辨率和码率。2.3 封面图截取很多人忽略的一个“隐形需求”视频列表页总不能全部显示黑底播放器所以每个视频都需要封面图。我的做法是转码时顺手用FFmpeg截取视频的某一帧作为封面ffmpeg -i input.mp4 -ss 00:00:03 -vframes 1 cover.jpg-ss是跳转到第3秒-vframes 1是只截取一帧。封面截取有几个注意点不要选第0秒因为很多视频开头是黑屏或字幕封面很难看也不能截得太靠后万一视频很短就截不到了。我在代码里会先通过ffprobe获取视频总时长然后取总时长的10%那一帧确保每张封面截出来的画面都相对有代表性。截完封面还有一个细节封面要压缩。原视频的帧可能是1920×1080直接当封面会让列表页加载很慢。我写了一个尺寸判断逻辑宽度超过640就缩放并转成JPG格式。2.4 在线播放器实现如何让进度拖动又快又准播放器部分我选的是Video.js它最大的优势是开源、社区活跃、自定义皮肤方便。同时配了videojs-contrib-hls插件来做HLS流的支持。这里涉及一个流媒体服务的核心概念——HLSHTTP Live Streaming。HLS的原理是把视频切成很多小段比如每6秒一段生成一个.m3u8索引文件播放器按顺序加载这些段。它的好处是天然支持多清晰度切换、拖动进度也直观——用户拖到哪个位置播放器就去下载对应的分片不需要加载整个文件。我原先是打算把所有视频转成HLS格式的但后来发现一个很实际的问题MP4文件的moov元数据默认放在文件尾部浏览器播放器加载MP4时会先下载整个文件才知道时长信息导致“打开视频转圈很久才开始播”。解决办法是生成MP4时加上-movflags faststart参数FFmpeg会把moov元数据移到文件头部。加上这个参数后MP4在浏览器里基本能做到“秒开”。这也是为什么很多在线视频网站至今仍然用MP4格式的原因之一。如果你一定要用HLS也有个坑要提HLS分片文件是.ts格式浏览器直接加载会跨域报错必须在服务端配置CORS头Access-Control-Allow-Origin。我当时的Java服务是加了一个响应拦截器对所有媒体资源请求统一添加CORS头。播放进度的保存我是在播放器触发timeupdate事件时节流比如每5秒向后端发送一次当前进度。用户下次打开页面时后端把进度返回播放器currentTime()直接跳过去。这里有个细节必须做——校验返回的进度值不能大于视频总时长。我见过有人直接把数据库里存的进度拿来做跳转结果视频被重新转码重新上传之后老进度比新视频长度还长播放器直接异常。所以我在播放器里加了一个判断进度大于总时长95%时说明用户上次基本看完了干脆从头播放。3. SSM核心业务实现与Django后台开发前端播放器能动了后端业务逻辑才是网站的“大脑”。Java服务端的业务模块主要包括用户体系、视频管理、评论和互动Django后台则聚焦运营人员的使用场景。两边配合起来整个系统才算完整。3.1 Java端视频业务模块实现从列表查询到详情展示视频列表接口是我第一个写的接口。需求很朴素支持分页、支持按分类筛选、支持按关键字搜索。但写的时候要避免隐藏的性能坑——如果直接用MyBatis做模糊查询一旦数据量大SQL就会全表扫描。我在video表的标题和简介字段上加了组合索引查询时用LIKE CONCAT(%, #{keyword}, %)的写法数据量在几万条以内性能完全够用。视频详情页的接口要一次性返回多少数据这里我踩过坑。最开始的方案是详情接口里同时把评论也查出来结果一个接口嵌套了五六张表SQL写得很长查询效率也不理想。后来我拆成了三个独立接口视频详情、评论列表、相关推荐。这样前端可以按需请求还能做懒加载评论只在用户滚动到评论区时才请求首屏加载速度快了很多。播放量统计我用了最简单的方案在详情接口里做update video set play_count play_count 1 where id ?。这个方案在小规模项目里是没问题的但如果将来要做高并发统计就得引入Redis这类中间件先把播放量异步累加再定期刷到数据库。不过考虑到社团使用量级不大数据库直接累加也扛得住重要的是把逻辑做对。3.2 用户权限体系SSM的登录态管理怎么做才安全视频网站有明确的权限层级游客只能看视频注册用户可以上传和评论管理员可以审核和删除。SSM框架下我选了JWTJSON Web Token做登录态没走传统的Session。原因很简单Session依赖服务端存储将来如果要把服务拆成多实例部署Session同步会很痛苦JWT是无状态的服务端不用存登录信息扩展性好。JWT的实现流程不复杂用户登录成功后后端用私钥生成一个包含用户ID、用户名、过期时间的Token返回给前端前端每次请求在Header里带上Authorization: Bearer token后端通过拦截器解析Token并校验。这里有个硬性知识点——JWT的签名密钥绝对不能硬编码在代码里更不能提交到Git仓库。我当时的做法是放在配置中心用环境变量注入。权限校验用Spring的拦截器实现我定义了三个级别AuthInterceptor校验Token有没有过期。AdminInterceptor在Auth基础上再查数据库确认用户角色是管理员。拦截器配置好之后在SpringMVC的配置里指定哪些路径走哪些拦截器。比如/api/admin/**走AdminInterceptor/api/video/**部分接口需要登录才给播放地址部分公开。有一个细节特别容易犯不要把视频文件本身的访问也放到鉴权体系里。如果播放器的src地址需要带Token才能访问用户把链接分享给别人就播放不了反而麻烦。我的做法是视频文件地址是公开的但用户需要“能拿到这个地址”才行。也就是说获取播放地址的接口做了登录校验一旦拿到地址在这个有效期内是可以直接访问的。这相当于把安全边界放在了“地址发放”环节而不是“文件访问”环节。3.3 Django后台开发为什么后台用Python写反而更快Django那边我把它拆成了两个App一个是video_admin负责视频管理一个是dashboard负责数据统计。Django的ORM写后台的增删改查确实省事。比如视频列表管理我只定义一个模型然后使用ListView做列表页面再用Admin站点定制操作按钮。Django自带的Admin其实很强大如果只是给运营同事做内部管理工具直接复用Admin完全可以。不过因为视频审核需要有“通过/驳回/下架”这几个自定义状态流转我在模型里加了status字段并在Admin Action里注册了对应的操作函数运营人员勾选视频后下拉菜单选择状态就能批量处理。Django调用Java端API是通过requests库。代码很简单import requests def sync_video_status(video_id, status): resp requests.post( fhttp://localhost:8080/api/admin/video/{video_id}/status, json{status: status}, headers{Authorization: fBearer {admin_token}} ) return resp.json()这里要记得设置超时时间避免Java服务端挂了之后Django后台一直卡住。我的建议是统一封装一个HTTP客户端工具类统一管理超时、重试、异常捕获。3.4 前后端接口约定与调试技巧两个服务之间通信最容易出问题的是接口约定不规范。我建议大家在项目开始前先写一份API文档哪怕用Markdown都行。明确每一个接口的路径、请求方式、请求参数、返回结构。这样做的好处是两边开发可以并行不用天天等着对方联调。调试时我常用的技巧是用Postman保存所有接口的测试集合每次改完Java代码直接跑一遍回归测试。遇到Django返回的数据不对第一步不是去查Django代码而是先用Postman直接请求Java接口确认Java这边返回是否正确。这样可以快速定位是服务端的问题还是Django调用的传参问题。在Java端开启application.yml里的mybatis.configuration.log-impl: org.apache.ibatis.logging.stdout.StdOutImpl打印SQL日志。我后来排查很多数据问题都是靠看这条SQL日志发现的比如字段名拼写错误、参数没传进去日志里一目了然。4. 视频内容管理与运营功能实战视频上传、转码、播放这些“硬能力”做完之后网站能不能长期运营还要看内容管理做得细不细。这一节我讲讲分类管理、用户举报、推荐逻辑这几个容易被忽略但又很影响体验的模块。4.1 分类与标签体系给视频做多维度的“编目”视频网站的视频数量一旦上千靠人工一个个找视频就不现实了。分类和标签体系就是解决这个问题的。我的分类表设计是支持二级分类的。一级分类比如“影视”“教程”“音乐”“生活”二级分类比如“教程”下面有“Java开发”“Python开发”“摄影剪辑”。视频发布时用户必须选择一个一级分类二级分类选填。标签体系我处理得比较谨慎。用户填标签容易乱填什么“好看”“厉害”都来了。我做了两个限制一个是前端使用标签输入框时优先从已有标签库里自动补全减少用户自由输入第二个是后端保存标签时做长度和内容校验过滤掉纯符号、太长的词。打完标签后推荐视频就简单了——取当前视频的标签在video_tag表里找相同标签的视频按播放量排序取前20条。这个逻辑虽然朴素但实际效果不错比纯按分类推荐精准得多。4.2 视频审核与状态流转上传后不是马上能看的做视频网站审核环节必须要有。否则有人传个违规视频上去影响很不好。我设计了四态状态机待审核0→ 审核通过1→ 上架展示 待审核0→ 审核驳回2→ 用户可修改后重新提交 已上架1→ 管理员下架3→ 前台不再展示这个状态流转关系我建议画成一张表格放在项目文档里开发时不容易乱。Java端的审核接口是一个简单的Update操作但有一个业务点必须考虑驳回时要写原因。我在video表里加了一个audit_remark字段。用户端会显示审核不通过的原因比如“标题有违规词”“画质太模糊”。这样用户知道怎么修改整个流程才闭环。4.3 互动功能评论、点赞、收藏的实现要点评论模块的数据库设计看起来简单实际上有个过滤问题是绕不开的——垃圾评论。视频网站一旦有了公开评论就会有各种广告和乱码。我做了两层过滤前端提交评论前做一次基础校验比如长度不能低于1个字、不能超过500字。后端保存时做敏感词过滤。我在项目里维护了一个敏感词库用Trie树实现高效匹配命中后替换成***。评论列表的展示需要性能优化。直接查评论表然后逐条查用户信息会产生N1查询。我当时的做法是在评论表里冗余了用户昵称和头像字段查询评论时只查一张表就够了。当然这会导致用户改昵称后历史评论的昵称不变但对于社内小站来说完全可以接受。5. 常见问题与排查技巧实录这一部分是我最想写的。项目开发过程中踩过太多坑有些问题查了半天才发现原因特别低级。我把最有代表性的几个问题整理出来方便大家少走弯路。5.1 上传大文件报错连接被重置现象传一个300MB的视频传到一半前端报“连接被重置”。排查过程一开始怀疑是Nginx的问题查了client_max_body_size配置为0不限制但仍然报错。后来抓包发现Tomcat默认的maxPostSize是2MBSpring Boot并没有完全继承这个配置但在有multipart配置时还是会受影响。我是在application.yml里加了配置spring: servlet: multipart: max-file-size: 2GB max-request-size: 2GB同时因为做了分片上传单片只有5MB所以这个限制主要影响的是合并后的大小校验。但不管怎样配置加上总没错。5.2 视频拖动进度条时一直转圈现象视频能播放但一拖进度条就卡住有时还会直接跳到从头开始。排查过程这是典型的MP4 moov元数据问题。旧版FFmpeg转码出来的MP4默认moov在文件末尾播放器要拖动进度就得先下载完整文件过程当然卡。解决方法是加-movflags faststart。代码里修改转码命令后重新转码问题立刻解决。这里我特别想强调不要以为同一个命令在命令行跑没问题Java调用FFmpeg就一定没问题。我在Java代码里用ProcessBuilder调用FFmpeg时第一次踩的坑竟然是因为路径里有空格命令解析错误。解决办法是用ProcessBuilder而不是拼字符串ProcessBuilder pb new ProcessBuilder( ffmpeg, -i, inputPath, -c:v, libx264, -preset, veryfast, -crf, 23, -movflags, faststart, outputPath );5.3 Django后台请求Java接口超时现象Django管理后台点“审核通过”按钮页面转半天最后报超时错误。排查过程检查发现Java端的审核接口本身执行很快Postman直连Java没问题。但Django后台的requests请求没有设置超时时间默认是无限等待。后来发现是Java服务的线程池满了大量转码任务占用了线程。我做了两个改进转码任务从请求线程池挪到了单独的ExecutorService并且给所有Django调Java的requests统一加了timeout10。改完后再也没出现过卡死。5.4 视频列表页加载图片太多导致页面卡顿现象视频列表页一次展示20个视频每张封面图都是原图一屏加载下来页面要好几秒才能完全显示。排查过程这是懒加载和图片压缩没做好的典型问题。我在列表接口里返回的封面地址统一指向一个缩放后的小尺寸版本如640宽度原图只在播放页使用。同时在前端给所有封面图加上了loadinglazy属性。这两步做完列表页加载速度提升非常明显。5.5 常见问题速查表问题现象大概率原因解决办法上传大文件连接重置multipart大小限制未配置调大max-file-size分片上传视频播放黑屏但音频正常视频编码格式浏览器不支持统一转码为H.264AACMP4拖动进度条卡顿MP4 moov元数据在文件尾部加-movflags faststart审核操作超时请求未设置超时时间/线程池被占满设置timeout独立转码线程池列表页加载慢封面图太大且没有懒加载压缩封面图加loadinglazy登录后接口仍报401JWT密钥不一致或过期时间太短检查配置中心的密钥适当延长过期时间转码命令执行失败Java拼串调用FFmpeg出错改用ProcessBuilder传参6. 项目落地过程中的几个补充经验项目能跑通是一回事真正经得起用又是另一回事。最后这块我聊几个偏“工程化”但对项目长期维护很有帮助的点。6.1 环境一致性问题本地能跑服务器上就挂我在部署到社团服务器时遇到过Java服务启动正常但只要一请求转码任务就报“找不到ffmpeg”的错误。查了半天才发现是服务器上没有装FFmpeg而我本机是有的。这个坑看起来很蠢但在团队协作开发时非常常见。所以项目第一件事就是把依赖环境写清楚我用一个deploy.md记录了以下内容JDK版本1.8不要用11以上的版本有兼容性问题Maven版本MySQL版本5.78.0的密码认证方式不同需要额外配置FFmpeg版本4.x稳定版旧版在H.265支持上有差异Python版本和Django版本3.8 Django 3.2LTS版本最稳有了这个文档新成员加入或者重新部署时照着一步步装基本半小时搞定。6.2 转码任务失败的自动重试机制视频转码不是每次都能成功的。有些视频编码格式很特殊FFmpeg处理时中途报错。我第一次做的时候转码失败就是个失败运营人员得去后台手动重新触发非常麻烦。后来我写了一个简单的重试机制转码任务状态为“失败”时允许人工点击“重试”按钮。重试时不是重新ffmpeg -i整个任务我会先检查输出目录里有没有已生成的部分文件如果有说明是截封面那一步挂了跳过重新截如果输出目录里没有任何文件说明主转码失败完整重跑。这个“分步重试”逻辑帮我节省了大量等待时间。6.3 用户上传视频的格式校验提前拦截比事后处理省事在上传接口里我用了两层格式校验。前端在上传前检查扩展名和MIME类型只允许MP4、MOV、AVI、MKV这些常见格式。后端收到文件后用FFprobe获取真实编码信息如果检测到音频流缺失或分辨率超过4K直接返回错误拒绝转码不让无效文件进入转码队列。因为转码是非常消耗CPU的任务提前把垃圾文件拦掉等于给服务器省了资源。6.4 部署建议小型视频站也值得上对象存储如果你做的是个人项目或者演示用把视频放在本机磁盘完全没问题。但如果打算长期运营我强烈建议把视频文件放到对象存储上比如阿里云OSS、腾讯云COS或MinIO私有化部署。这样做的好处是视频文件不占用业务服务器的磁盘和带宽对象存储自带CDN加速用户在不同地区都能流畅播放将来服务器迁移视频文件不用跟着搬来搬去。项目我最后就是接入了MinIO做演示——私有化部署的对象存储跟S3协议兼容Java端用它的SDK上传下载非常方便。你把“本地存储路径”那套代码抽象成一个StorageService接口本地和对象存储各写一个实现以后想切就切代价极小。6.5 日志与监控别等用户告诉你网站挂了网站开发完最容易忽略的是日志。我一开始只在控制台看日志后发现视频转码失败这种异步任务的问题根本不会被及时发现。后来我把日志分成了三类访问日志记录所有接口请求和响应时间。转码日志记录每次转码任务的输入、输出、命令、耗时、结果。错误日志单独记录所有异常堆栈按天滚动。转码日志让我能清晰地看到每个视频在哪个步骤失败排查效率提升了不止一个档次。如果你连日志都懒得做至少把FFmpeg命令的输出完整记录下来别只读个退出码——FFmpeg报错的具体原因全在stderr里。最后再分享几个小技巧项目做完了有些细节虽然当时只是随手处理但现在回头看都是决定体验的关键点。第一个是视频列表页的排序规则。默认排序我用的是综合排序——播放量和发布时间各占权重。当时运营的朋友问我能不能让新发布的视频排在前面我给他做了一个筛选按钮列表页支持“最新”“最热”“收藏最多”三种排序方式。实现上就是在Service层根据sortType拼接不同的ORDER BY非常简单但用户会觉得网站“很懂”。第二个是搜索功能不要复杂化。我当时很想上一套Elasticsearch做全文搜索后来冷静了一下内容也就几千条MySQL的LIKE查询够了。真的上ES还得维护数据同步、分词器、高亮逻辑复杂度直接拉高一个量级。做项目要先想清楚规模再决定技术复杂度。等数据量真到不了才会考虑接ES现在别自找麻烦。最后说一下我对这套SSMDjango混合架构的看法。如果今天让我从头再选一次我可能不会再用两套技术栈了。原因不是混合架构不好而是现在Spring Boot做后台管理系统也很快Vue Element UI做管理界面同样方便。但在当时的技术水平和团队配置下混合架构让我用最低的学习成本完成了最合适的分工——Java啃硬骨头Django管运营界面。项目最终落地效果很好社团的朋友用得也顺手。做项目就是这样不存在什么“标准答案”把你手上的牌打好把每个环节的原理吃透这就是最好的架构。希望这篇复盘能给你一点参考少踩几个我踩过的坑。