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

1次阅读

共计 4082 个字符,预计需要花费 11 分钟才能阅读完成。

导读:短视频在现在曾经是十分重要的内容载体,在短视频播放时如给予用户进行如相干视频、商品、游戏、流动等优质内容的举荐,不仅能晋升用户的应用粘性,也能极大的丰盛内容的生态,本文会具体介绍在短视频 APP 相干页面做内容举荐入口地位的设计实际。

全文 3608 字,预计浏览工夫 10 分钟

一、背景

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,加上高并发申请,服务器容易宕机。
  • 熔断
  • 降级开关

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 源码调试与剖析

正文完
 0