作者| 阿里文娱技术专家 弥少

一、背景与概要

针对优酷的多种播放渠道（移动端、PC 软件、OTT、H5 等），多种播放场景（直播、点播 等），需要一种可快速将相关配置下发实践并可观察对应播放体验指标变化的配置系统。这种配 置系统需要具备快速配置下发、实时数据反馈并结合优酷的播放场景配置改善播放体验的策略。
针对这种需求，我们开发了云控平台，云控平台除提供基础的配置能力外，结合优酷的播 放场景，重点在可靠性和实时性、AB 分桶、数据联动、易用性等方面有所改进，更贴近优酷 播放的业务场景。同时云控平台还支持带有策略决策和运营能力的专题场景，例如优酷的流控 场景等。

二、高可靠、高并发、高生效率

云控平台的基础能力之一就是配置能力，如何将配置实时并且可靠性地在端侧生效是配置 能力的重要目标。以往的配置下发平台要么使用拉模式要么使用推模式，都各有利弊。

1. 拉模式

优点：客户端可多次拉取，并且可采用短连接，拉取的效率较高。后台服务架构比较简单，容易实现。
缺点：依赖于拉取的时机，易造成生效时效不够高的问题。客户端通过轮询机制，会频繁拉取，浪费资源。

2. 推模式

优点： 灵活配置，可按需推送，触达率高。
缺点：需要在服务端与客户端之间实现长链接，比较消耗资源。 需要实现去重下发，防止相同的配置多次下发到端上。

3. 云控平台使用推拉结合的模式

云控平台通过提供两个接口来进行配置的下发和更新，通过启动时全量拉取配置与心跳时 变更配置推送配置，推拉结合的方式更快速有效地将配置更新到端上。在心跳接口，云控通过 识别出变更的配置项，只将变更配置项下发，大大减少了配置项的下发总量。
1）APP 启动时全量更新配置接口-拉接口；
2）APP 前台保活期间的心跳接口-推接口；

在生效率上，云控平台在 3 分钟可达 95%以上，3 小时可达 99%以上的生效率，满足业务 场景的需求。
在云控平台内部，底层使用一套规则引擎服务，为了提高引擎服务的性能，所有的配置项 都被会加载到服务器的内存中执行，在服务器内部将配置条件和匹配内容的通过 key-value 结构 进行存储，引擎服务经过配置的优先级来执行所有的配置条件，当有命中后，可快速获得匹配 对应的内容，并将配置的内容返回给端上。每个设备命中的配置项集合都会被设置一个 md5 值 下发，这个 md5 值既可让云控平台追溯每个设备命中的配置项集合，也可让云控平台知道这个设备的当次请求是否涉及配置变更，在心跳接口中可下发有变化的配置内容，提高云控平台的 心跳接口的性能和下发能力。考虑到实际配置的内容会越来越大，云控平台在初期设计的时候， 就考虑到了使用 CDN 的 URL 等多种格式下发的方式，后期可以无缝切换到 CDN 的 URL 来进 行配置下发。
目前优酷的移动三端、PC、Web 的播放业务已全面接入云控平台，已覆盖优酷的点播、直 播、下载等主要业务场景，云控平台服务峰值 QPS 达 10 万+。同时 OTT、APP 的上层业务也 正在接入中。云控平台经历了 2019 年七十周年国庆大阅兵、2019 年猫晚等大型项目的历练， 保障了流控、点播直播智能档、限速、P2P、H264/265 转码、HDR 等功能的顺利有效地进行。

三、AB 分桶

AB 分 6876 在互联网行业是一种测试新功能的有效手段。AB 分桶一般将设备请求的参数 做 HASH 分布，通过 HASH 结果做分桶分布，并在不同分桶上使用不同的配置，来测试新功能 对业务的影响。例如下图根据设备 ID 进行 10%的分桶匹配算法。

云控平台 AB 分桶也是依据将设备 ID 做 HASH 算法，根据 HASH 结果应用不同的配置来 进行。为了适应更复杂的业务需求，云控平台实现了一套多层多分桶的计算框架。

1. 多层多分桶计算框架

云控平台将配置项分为多个 namespace，每个 namespace 在逻辑上对应一个功能点，每个 namespace 内，又分为多个具体配置项 config。收到每次请求时，云控平台根据以下原则通过规 则引擎服务进行匹配：
1）单个 namespace 内，根据配置项的优先级进行匹配，最多命中一个配置项。
2）Namespace 可命中多个。
用户可以在不同的 namespace 上的 config 使用不同或相同的分桶算法，也就是说下图的分 桶 HASH 算法 1、2、3 既可以是一样的算法也可以是不同算法；这种方式的好处在于可以提供 给用户提供类似笛卡尔乘积的配置组合，如果选择了分桶 HASH 算法一致，则说明用户想让不 同 namespace 之间的配置带有某种关联性，否则就不想让不同 namespace 之间的配置带有关联性。

下面给出几个例子来说明：
例 1：namespace1 是控制 buffer 的，namespace2 是播放限速的，选择相同的分桶算法 10%， 则可以让 10%的用户一直命中 namespace1/config1+ namespace2/config1 的组合，可以用来验证 某一buffer 情况下播放限速的线上效果。
例 2：namespace1 是控制 buffer 的，namespace2 是播放限速的，选择不同的分桶算法 10%，可以用来验证不同的 buffer 配置与不同的起播档位两个配置的线上效果，因为使用了不同的分 桶算法，两个配置并没有关联性。
例 3：namespace1 是控制智能档的策略，namespace1 内有 config1 积极智能档和 config2 保 守智能档两个配置项，如果 config1 配置前 50%的分桶，config2 配置了后 50%的分桶，可以用 来验证不同智能档策略下的线上效果。
为了区分不同分桶的配置，云控平台提供了分桶区间热力图，可以直观的展现线上已配置的不同 namespace 的分桶前后关系，多层多分桶计算框架对于优酷线上验证复杂配置提供了有效的手段。

四、数据联动

数据联动功能是云控平台比较贴近播放场景的一项特色功能，云控平台通过将原始数据层 的数据经过离线ODPS 多维聚合和 BLINK 实时计算后，可以作为数据联动的供给源。在云控 平台的数据展示中，可以实时和离线地展示配置的命中情况（vv/生效率），配置对应的所有关 联播放核心指标的变化情况，并可实时和离线对比各个配置项的各维度指标的数据。

同时，在数据联动中，可以实现实时上报反馈和实时圈人的功能，可以将实时反馈上报的 数据加入到配置条件中。反馈机制通过实时数据处理与缓存来实现。
实时上报反馈的数据包括客户端的主动或被动行为。主动行为包括：用户切换清晰度、seek、 倍速播放、拖动等；被动行为包括：卡顿上报、耗时上报、起播上报等。
例如：某一配置与卡顿项相关联，在配置的条件中添加卡顿率大于多少则此配置就不生效，可以保证该配置不对卡顿率指标有负面影响。

圈人是指根据给定的条件从所有用户中圈出想要执行配置的人或设备。圈人分为离线圈人和实时圈人两块，离线圈人通过 ODPS 的离线任务实现圈人的功能，实时圈人通过 BLINK 的 实时计算实现，实时计算可以将多维的上报数据进行全链路关联后，作为配置的条件自动加入 到引擎的匹配过程中，可以更动态地控制匹配的执行，达到端、云闭环联动的效果，目前我们的实时数据联动的时效可以达到分钟级别，对于提升用户的播放体验起到了很好效果。