Netflix Blog- 重构视频GateKeeper

      这篇文章Re-Architecting the Video Gatekeeper  是出自 Netflix Technology Blog。

       Netflix上的视频需要通过Title Operations 团队的策划,使其遵守的合同;字幕、配音、翻译能够提供给合适的人群;标题名称和概要可供使用和翻译;满足各个国家的成熟度等级(分级)。

        Gatekeeper是Netflix的系统, 他通过汇集多个上游系统数据, 应用一些业务逻辑,为每一个国家地区每一个视频状态的输出来完成器规定任务。GateKeeper 设置这些视频是否对用户可见。为Title Operations 指出缺少的内容, 协助其工作。

    现存问题:

      GateKeeper是一个事件驱动的系统,上游系统每个改变都会向GateKeeper发送事件,GateKeep再通过访问每个上游服务来响应事件。可能会出现下问题:

  • I/O  瓶颈
  • 处理延时
  • 事件丢失

    而主动扫描处理一些指定目录可以缓解这些问题, 但是增加了更多的事件。

    解决方案:

      使用技术:Hollow  可以看下这篇文章使用技术  Hollow ( Drew Koszewnik),( 2016年,是这篇的作者)

      Netflix Hollow是一个java库和工具集,用于将内存数据集从单个生产者传播到许多消费者,以实现高性能的只读访问。 适合小到中级数据集  Hollow

     第一阶段:

     使用Hollow为每个上游系统在GateKeeper增加缓存, 在指定周期内循环迭代处理所有国家地区的视频,并生成完整输出。

     第二阶段:

      由于第一个阶段时间片相对较长, 整个数据来自实际数据源,一个迭代周期需要很长时间。需要进一步优化。

     将Hollow分为更小时间片单位, 应用程序将每次的更改通过kafka推送 Hollow,辅助周期性的整个数据源扫描来防止数据遗漏。

  效果:

    性能及可用性提高:消除了I/O瓶颈,提高了性能,单个上游系统故障下可以通过过时数据进行评估。

    对于新投产版本,将某一个时间X的数据做为输入, 将其输出结果其与生产版本应用的输出结果进行对比(diffed )来准确判断是否达到预期效果。对于开发,验证,部署都比之前有了很大提高, 安全性方面也比以前架构更高。

    在文末也写道将在未来几个季度实现这一目标。

    对于文中描述的实时推送,全量补齐方式,实施的项目中也使用过,不过是联机+批量模式:报文从一个系统A实时推送到系统B, 夜间再通过下发批量进行全量更新补全推送时丢失的信息。

     对于数据重放到预发布版本,与生产版本比较执行执行结果, 来验证新版本是否达到预期效果,和我现在项目中验证方式不一样, 目前投产后通过实际交易进行验证, 如果能方便将相关数据重放到新版本进行验证,确实将减少不少验证的工作, 不过也需要相应的应用做出相关的改造才可以。 

Be First to Comment

发表评论

电子邮件地址不会被公开。 必填项已用*标注