tinyTikTok 服务功能｜青训营笔记本篇文章归档于 “第五届字节跳动青训营”，主要是为了完成和记录掘金的 “伴学笔

这是我参与「第五届青训营」伴学笔记创作活动的第 32 天

本篇文章归档于 “第五届字节跳动青训营”，主要是为了完成和记录掘金的 “伴学笔记创作活动” 活动，如果你对我的其他文章感兴趣，可以去我的专栏中逛逛看有没有你想要的东西。

放在前面的话

原本是想放具体的截图演示和源码解析的，不过 tinyTikTok 已经烂尾了（一个人干所有事有点累

现在的 tinyTikTok 在项目总结里有概括（从总结开始写文档，足以看出来有多烂尾了hhhh），所以我这里就干脆画画饼好了

心中的 tinyTikTok

优雅退出：其实思路很简单，创建一个无缓冲的 channel quit，监听系统中断。通过 signal.Notify 函数调用，可以将进程收到的中断信号，并发送给 channel quit。其他服务阻塞当前 goroutine，等待从 channel quit 接收关停信号，接着就是一系列退出服务的操作和日志记录。

对象存储：先将视频压缩，并生成对应的 url 和封面（这个用 FFmpeg 应该还是挺容易的），然后 mysql 里存进视频表，视频存进 oss 里，字节内部用的 tos，业界标准一般是 s3，但其实可以考虑用 minio，这样搭建起来也会方便很多。这里的优化角度其实蛮多的，比如上传视频时，可以采用分治的思想，切割一下再上传，即使数据传输失败，也只用重试极小的一部分数据。

资源授权：可以用 Casbin 来进行复杂的资源管理，但以目前的需求来看，采用 RBAB 即可，至于框架选择，Casbin 云云，感觉优秀的框架还是蛮多的，切忌自己造轮子。

同步采集：通过分析基础接口和社交接口，可以判断当前场景的特点：读多写少。因此采用同步采集即可，面对仅有可能存在高并发场景的点赞接口，统一用 kafka 或者 redis 去削峰即可，如果实在担心性能问题，异步去采集便可。并且，还可以将特定的数据采集接口化、插件化，扩展性再次拉满。

异步上报：老生常谈的问题了，一个合格的 gopher 都应该学着去用 groutine 去异步消费缓存中的数据，这里便不再赘述。

代码生成：诸如 API 文档，都可以利用 openapi、sweagger 去生成，集成到 makefile 里即可

一键部署、全链路压测、功能性压测、单测覆盖率 80%（mockhttp 测试接口、mocksql 测试数据库）、打包镜像......（饼先画到这里吧

放在最后的话

不想回避这次的失败，它应该被记住，即使烂得跟坨粑粑没区别。