短视频APP相关推荐资源位的高扩展高可用工程实践 _可用

男儿欲遂平生志，五经勤向窗前读。这篇文章主要讲述短视频APP相关推荐资源位的高扩展高可用工程实践相关的知识，希望能为你提供帮助。
一、背景 1.1 推荐产品的流量精细化运营搜索行为的用户通常较为明确自己的需求和问题，技术的重心是针对问题返回准确的答案。推荐产品则反之，用户消遣时间是主要的目的，技术的重心是帮助用户挖掘潜在需求，需要通过与用户的交互逐步了解用户的喜好，给予用户提供相应的内容、服务等。如果说用户观看完当前视频再次请求，我们给予推荐新的视频主要是基于用户纬度进行内容推荐，那在当前视频播放时我们在本页面及时推荐一些内容服务就是细化到用户+视频维度，这就是短视频相关资源推荐位的意义和价值。
1.2.资源位示例

文章图片

1.3 这个位置要具备怎样的能力通用性：由于短视频内容可能在多个APP或者产品中都会进行分发，并且主要分发形式都是视频列表页、视频落地页等，所以这个位置是共性需求。再此基础上如果每个产品独立去开发这个位置就是重复劳动，成本高昂，所以我们需要一个通用的能力来解决这个问题。
稳定性：短视频的分发的量级是非常大的，并且经常出现在APP首页这样关键的位置，那么服务的稳定性无疑是非常重要的一环，极端情况下服务彻底不可用也不能影响视频播放本身。
扩展性：如示例所示这个位置除了提供视频、文章等内容服务外，还会提供活动推广、游戏下载、商品挂载等服务，这些内容及服务可能来自于各个产品线，怎么快速、低成本的接入管理这些产品线的内容和服务是快速丰富这个位置能力的关键因素。
智能性：这个位置接入的内容和服务足够多后，更重要的就是给予用户推荐更合适的内容和服务，以及在一些服务的性能出现问题进行降级，让这个位置充分的发挥其价值。
二、设计与实践 2.1 抽象化、标准化解决通用性问题资源位最核心的能力就是：
1. 给谁分发展示
2. 分发什么内容
由此可以抽象出以下位置分发能力和卡片内容定义两个部分。

文章图片

产品侧只需要定义好卡片的样式内容和决定分发的位置和人群等就可以将自身内容、服务输出给指定用户，这就是第一个阶段，提供通用性内容服务-> 用户的通路。
2.2 高并发下保证可用性、降低平响作为一个面向多个产品线的基础服务，应用场景如首页、活动页等，qps的量级将至少以10w为单位计数，设计上响应时间需要稳定控制在50ms内，从而避免对产品本身的性能造成影响。
2.2.1 降级策略保证整体可用性
1.降级的定义
因流量或服务器压力剧增，可能引发服务宕机或级联性崩溃。在有限资源的情况下，服务端不得不按优先级区分处理业务，即优先保证核心业务的正常运行，而对非核心业务用做简单折中处理，如快速失败，或返回缓存数据等等，避免占用更多资源，称之为服务降级。降级的目的是在服务自身性能达到瓶颈，或网络硬件应用等依赖的资源出现异常时，尽可能保证核心业务正常运行，进一步保证系统整体的可用性和稳定性。
2.降级的特点

降级是服务的自我保护机制，为了整体不被拉跨，放弃部分服务的可用性，丢车保帅。
因非核心任务被降级处理，从用户角度来看，现象就是可能服务变的不可访问，或者数据过期，因此一定上程度降低了用户体验。

3.常用策略
限流(拒绝, 缓存), 熔断(快速失败, 缓存)

限流：从一定程度上来说，大流量是增加服务器压力的万恶之源，短时间内的高并发，服务器会启用大量线程池，CPU切换压力增大，如果线程池达到上限，更多请求会阻塞在内存空间，各服务接口都会受影响。如果同步访问数据库，或远程服务，磁盘读写性能和网络延迟会成为性能瓶颈，影响TPS，加上高并发请求，服务器容易宕机。
【短视频APP相关推荐资源位的高扩展高可用工程实践】熔断
降级开关

4.选取策略
资源卡片的内容和服务大多由内容服务团队提供，所以我们需要实时监测这些服务，避免由于某个服务的问题导致整体服务出现问题。

设置熔断开关，如调用服务可用性低于设定阈值，直接熔断断开调用，直至后续多时间片监测确认服务恢复。
制定性能分发权重，可用性较差、平均响应时长较长的服务降低其分发权重。

2.2.2 存储优化，提升平响、稳定性
1.业务需求和特征
业务数据特点：

物料和视频或者用户强相关

分发侧需求：

平响要低，不能影响自己的核心业务。
稳定性要高，可用性不能低于99.9%。

业务进行分类：

要求和某些视频绑定需要稳定下发的
要求高优下发的
需要实时请求下游服务进行计算的

用户使用特征：

用户都是就近请求服务，通常非机房级别故障，不会产生跨机房请求
绝大部分的内容是我们推荐给用户，用户对于大部分内容的一致性的要求没有那么高。

2. 基于以上需求特征确定存储方案如下

根据业务数据特点和分发侧需求我们可以选取key value型存储，变更性能好。
根据业务进行分类和用户使用特征，我们对不同地区之间的数据一致性要求不高，在不考虑降级策略以及抛却一些需要实时请求的下游业务情况下，如果想通过平台进行性能优化，那变动不是很频繁的业务我们只能尽可能的让他们把数据存到我们这里统一管理，增加一些本地缓存作为二级缓存来进一步提高可用性。

文章图片

2.2.3 多路数据获取，性能优先
并发多路请求下游服务，设定超时时间，将最终未超时返回的数据进行后续策略处理确定最终分发数据。由于受限与机器连接数，核心要点是要平衡好并发的数量和超时时间，二则呈负相关。
我们的目的是尽可能的请求更多的服务来获取内容和服务以便给出用户最佳推荐，达成这个目的依赖于我们对于服务的精细化管理。
2.3 平台工具化保证快速业务接入1. 设计背景：

条件繁杂：资源位已接入数以十计的业务且持续增加，每种业务都涉及业务数据的组装，分发端、版本、位置的控制，各种小流量实验的加入等需求，重复性工作较多，且质量把控成本高。
业务变更频繁：日常迭代中经常收到诸如某业务跳转地址更、物料信息、小流量实验号、业务优先级、下发版本的变更需求，经常面临开发五分钟，上线几小时。
业务逐渐复杂：随着业务的大量接入，每次上线的回归测试将变得成本越来越高，各种业务的监控维护也越来越复杂。
case咨询：pm或者用户咨询不符合其预期下发的原因，研发需要查看代码核对逻辑复现线上，成本高昂。

2. 设计目标：

业务规则抽象化：业务代码进行规则抽象，支持规则组合、插拔和热更新。
业务上线配置化：老业务变更和新业务接入通过已有规则和新增规则配置化完成上线。
业务回归测试监控自动化：通过建立自动化监控及回归测试机制来降低业务复杂带来的成本。
业务流程可见性：当业务遇到不清楚的问题时，可以非常清晰的发现是哪个环节导致。

2.3.1 资源模板化、下发规则插件化，应用规则引擎，灵活组装上线
1.业务方选取展现物料模板，填充物料，确定展示样式。
2.下图下发规则组件化由接入业务方自由选取组合，平台进行最终审核上线。

文章图片

规则引擎运转步骤：
1. 创建规则引擎对象
2. 向引擎中加载规则集或更换规则集
3. 向引擎的前置过滤规则提交需要被规则集处理的数据对象获取处理结果
4. 根据处理结果获取需求的物料数据
5. 将物料数据提交给规则引擎的后置聚合规则
6. 输出引擎执行结果

文章图片

规则引擎核心设计：

规则的核心为两个部分：

1. 判断资源在哪里出与不出，业务上由于已经沉淀出绝大部分的规则，且规则变化不大，核心在于规则中的条件变更，所以基于业务和成本考量不建设复杂的规则编辑和解析能力，规则将以组件化的形式存在，可以动态维护规则得变量参数，如app下发规则，规则变量参数为下发端的名称，应用规则时变量参数为端名称、条件、是否下发，如新业务需要新增规则再进行组件开发，主要核心能力在于组装管理规则组件。
2. 判断资源出什么，业务方选择物料模板填充物料，如跳转地址以及地址里的参数和用户、端、版本等因素都会有一定的关系，所以在输出的时候需要进行动态的转化，这个也需要通过规则得方式进行数据转化。

规则之间的关系：

且：规则定义为执行的一条执行链路，所有的规则都命中为下发则下发，一条命中不下发则不下发。
从属：规则存在从属关系，有配套父子关系，如规则a下有从属b、c，配置a时可以配置从属b、c规则，如版本和规则下发规则从属与端下发规则，只有端下发规则生效从属规则才有意义，完整规则链条是：a(分发端) b (> =xx版本) c(在端什么页面)进行下发。
2.3.2 资源下发录制回放
通过记录并模仿用户的行为完成case的复现、业务探活、上线回归。

流量行为录制，通过服务标准化日志打印输出，统一用户请求行为日志，将日志收集至录制平台，对日志进行清洗、分类、聚合，构建核心功能回归路径、用户请求路径，完成用户行为和核心功能的请求录制。
流量行为回放，通过录制的流量行为构建对服务进行请求，拿到请求的结果与录制时的结果对比，输出报表，完成报告分析报告。

文章图片

2.4 智能调度分发策略保证用户体验通过前后端打点，获取推荐卡片的点、展、观看时长等数据，结合实验进行统计分析，动态完成业务质量评估结合用户画像来实时调整下发策略。

文章图片

2.4.1 接入业务质量评估及迭代处理
根据下发资源卡片的打点数据，定期进行业务自动化评估，根据评估数据，持续迭代淘汰质量较差的业务资源。

2.4.2 动态策略返回最优内容
根据用户画像及接入业务服务的性能及健康状态，实时计算资源下发的分配份额，基于份额进行资源下发调配。
三、总结前期重通路及可用性完成基础能力构建，打通业务侧内容、服务供给，用户侧内容消费、服务使用的闭环，通过存储优化、性能优化保证了服务的可用性。后期重效率、质量通过平台建设，应用插件设计、规则引擎提升业务接入效率，通过流量回放来降低事故率、业务回归测试成本，最终通过智能调度策略保障平台生态质量，避免无序扩张而影响应用资源卡片的业务本身。
推荐阅读：
百度小程序包流式下载安装优化
前端工程化之FaaS SSR方案
日志中台不重不丢实现浅谈
百度ToB垂类账号权限平台的设计与实践
视觉Transformer中的输入可视化方法
深入理解 WKWebView (渲染篇) —— DOM 树的构建
深入理解 WKWebView（入门篇）—— WebKit 源码调试与分析