小抖音架构设计

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

场景一：

分析：

在首页信息流中随机刷到某部电影解说的一集，通常这种解说都是3集起，一集看完觉得很有意思，进入作者主页急不可待地寻找下一集。这时你就会遇到一个问题，抖音是根据算法推荐内容，不是按照发布时间推荐，可能有一些时间加权，但是依然需要你从作者花花绿绿的列表封面里做判断，到底哪个是自己刚才看过的那个？

相信抖音的作者们也意识到了这个问题，他们会选择将3集内容的封面进行加工，加上剧集名称和集数标识，甚至看起来像一个海报，便于用户识别，吸引点击。

问题：

第一：如果你对刚才看到的视频内容不够熟悉，而作者列表里的封面信息又不能很好地体现原视频信息，那你依然无法快速找出哪个是刚才看到的视频；
第二：若刚才看的内容是该作者发布很久的视频，恰巧这又是个高产作者，那你可能需要在作者个人主页列表里滑动很久，才能找得到，甚至你稍不留神就会错过。这时你反复寻找不到，就只能气急败坏的退回到首页，带着遗憾，划到下一个视频。

目前抖音的解决方式是：就是从首页信息流视频进入作者主页后，会在刚才播放那个视频封面，打上“刚刚播放”的字样，这样就可以一眼锁定哪个是刚才看的那个视频。

痛点：但是这样子如果作者的视频很多还要翻半天找到自己刚刚播放的视频

而我个人觉得最好的解决方案是，不仅添加“刚刚播放”的文字，而且从首页进入作者主页时，位置应该直接落焦在这个刚刚播放的视频。

其实，这个痛点场景，不仅仅是电影、剧集解说存在，其他带有时间线的内容类型或多或少都存在。

场景二：

分析：

相信大家刷抖音时，消耗时间最多的就是首页信息流，抖音的产品经理也知道，所以首页主屏里塞下了越来越多的东西。

从账号id、头像、点赞、评论、分享、视频标题、配乐信息，到地理坐标、商品推荐、相关热点、热点排行等等，这些按钮、文案、链接信息，除了给用户带来一些便利，提升了某些产品指标，同时也带来了一些不便。

比如：一些创作者会把很多内容信息以字幕形式随着视频播放，而此时固定的标题文字，会遮挡住字幕信息。

再比如：足篮球视频本来就不合适竖屏播放，很多精彩的看点，就在画面边缘，此时那一个个圆形、心形、椭圆和箭头，就成了看球的“马赛克”，令人望眼欲穿。

解决方案：就是再增加一个按钮。是的，你没看错，是再增加一个。

但是，它的功能是：点击之后收起当前视频里其他所有按钮符号和文案，让画面内容最完整的呈现出来，且这种无干扰的画面仅在当前视频呈现。

如果播放下一个视频时，会恢复常规设置，这样就既能满足用户在特定视频里，关注细节的需求，又不严重影响其他功能露出。

场景三：

分析：

如果你常刷抖音，一定也有这样经历，因为回忆使然或者误刷新，想回看之前的某个视频，若是一般的长视频应用，此时你只需要打开“历史记录”的页面，就可以得偿所愿。

但可惜的是，抖音并没有提供这种回查回溯功能。这固然是因为用户整体上对长视频和短视频的回看、追看需求程度不同。

想到的解决方案是：

首先：可以不同于长视频应用的历史视频逐条展示，抖音的历史视频可以选择按日期查询，仅在查询操作行为后给当天相应记录，避免负载无需求的数据；
其次：“历史记录”功能可以放在APP里比较深的入口，只用来满足那些确实有强烈需求的用户。

场景四：

分析：

当某个粉丝量很大的博主上传视频时，如果按照单一节点来上传文件到oss中，会出现oss节点负担大的问题，因为会伴随大量粉丝观看视频。

想到的解决方案：

我们通过架设多个oss节点，在大v上传视频时，我们可以通过一致性hash算法，选出负载均衡的节点，这样可以保证，每个oss节点都承担了差不多的压力

目录结构分析：

cmd 目录：包含启动应用程序的代码，以及与数据访问层（dal）和路由层（router）相关的代码。

config 目录：包含应用程序的配置文件。

data 目录：包含应用程序使用的数据文件，例如日志文件等。

docs 目录：包含应用程序的文档和说明文件。

internal 目录：包含应用程序的核心代码，包括错误处理（errmsg）、请求处理（handler）、中间件（middleware）、模型（model）、数据访问层（repository）、响应处理（response）和服务层（service）等。

k8s 目录：包含 Kubernetes 集群相关的配置文件。

pkg 目录：包含应用程序的公共代码和依赖项。

scripts 目录：包含应用程序的脚本文件，例如部署脚本等。

test 目录：包含应用程序的测试代码和测试数据。

当前架构解决方案：

根据场景分析，我们采用高并发、高可用性、可伸缩性的架构方案，以满足大量用户同时访问和上传视频的需求。

目录结构中，应用程序的核心代码放置在 internal 目录下，可以根据不同的功能划分为不同的子目录。例如视频相关的服务层代码可以放置在 internal/service/videoservice 目录下，同时可以使用 GORM ORM 框架来进行数据库操作，使用 RabbitMQ 消息队列来进行异步消息传递，使用七牛云 OSS 来存储视频文件等。

另外，需要保证应用程序的可测试性和可维护性，可以在 test 目录下编写相应的测试代码，并在 scripts 目录下编写相应的部署脚本，以方便进行测试和部署。同时，及时更新和维护相关的开发文档，以方便团队成员进行协作和迭代开发。

用户界面与路由层之间通过 HTTP 进行通信。
路由层通过 RPC 协议与业务逻辑层通信。
业务逻辑层通过数据库、缓存、对象存储、消息队列等技术访问数据，实现相关业务逻辑。
鉴权层实现用户身份验证、授权等功能。
服务发现层实现服务注册与发现功能，保证分布式系统中各个服务之间的协作与通信。
目录结构中的各个模块可以对应到上述不同的层次。