爱奇艺全民 pick 背后的投票技术

前言

从《偶像练习生》、《中国新说唱》到《青春有你》、《潮流合伙人》，爱奇艺近年来不断深耕青年文化领域，成功推出了多部爆款内容，持续引领青年潮流文化的发展。在这之中，延续三年的“偶青”系列IP推动了偶像元年的开启、为偶像团体选拔类综艺树立起全新的标杆，在满足用户多元娱乐需求的同时，向全球用户输出勇敢追梦、坚持自我的正向精神，也为国内偶像市场注入新鲜血液，再度推动偶像市场的健康良性发展。《青春有你2》已于5月30日晚顺利收官。百位训练生历经层层考核，最终由青春制作人助力选出的THE9以团体形式正式诞生,并获得蒙牛真果粒代言资格。在历次节目顺利进行的背后，有无数的团队付出了努力和汗水。其中就包括了投票服务技术团队。下面主要介绍一下投票服务的架构优化和对《青春有你2》的支持工作。

1 投票服务简介

投票后台作为互动中台的一部分，支持爱奇艺各种 S 级大型活动和各种日常投票场景。支持过包括《国风美少年》、《中国新说唱》、《乐队的夏天》、《我是唱作⼈》《偶像练习生》等在内的耳熟能详的综艺节目投票。日常投票场景包括运营创建的各种投票 PK，如《你最期待迷雾剧场哪部作品》，以及用户发起的发帖、评论投票等。

2 投票服务的架构优化

原投票项目开发时间较早，为爱奇艺各种投票活动做出过卓越的贡献。但“服役”多年后，因其采用的一些基础技术框架较早，一些新技术的特性无法很好的进行应用，其服务的可维护性和扩展性已经大大降低。主要的问题包括：

• 直播投票和日常投票分别维护了两套代码和服务部署，带来比较高的维护成本；

• 对于需要扩容缩容等场景，运维部署复杂；

• 运营平台前后端代码有复杂的耦合，前端代码技术陈旧，难以进一步扩展运营的需求

在《青春有你 1》的活动中，虽然保障了投票活动的顺利进行，但各轮和直播的投票保障工作比较繁琐，我们相对付出的人力成本较大。所以在青你 1 结束后，开始着手进行重构投票系统的工作。主要目标是提高系统的扩展性和可维护性，能快速支持新需求的开发，提高效率，减少风险；提高对大型投票活动的服务能力，弹性扩容， 有新活动时，能配置化上线，将开发从繁琐的细节中解放出来，提高对活动质量的把控力。

重构后的整体架构如下图所示，下面从几个方面来分别介绍优化后的架构。

图 1 整体架构

2.1 部署架构优化

原投票服务在部署架构上是采用外网负载均衡→自建 Nginx 集群流量分发→服务集群的方式。优点是链路清晰、简单，缺点是作为开发需要维护分机房\分服务的的前置机、虚机 IP 列表，在上下线及扩容缩容等方面比较麻烦。新投票系统采用 QAE+Skywalker 的方式来解决这一问题。

QAE(iQIYI App Engine) 是爱奇艺内部自研的基于 Docker 的应用引擎，旨在帮助公司内部业务实现高效、可靠的自动化运维。 Skywalker 是爱奇艺内部自研的微服务平台，提供了服务注册发现、配置中心、健康检查、作为 API 网关的负载均衡、鉴权、限流等功能。

随着节目热度的不同以及活动周期变化，投票服务的高峰低谷流量差异比较明显，在大型活动、直播等场景需要大量扩容，在活动结束后又需要回收资源以免浪费。在老的服务中，为了扩容需要新申请资源和进行虚机环境的初始化设置，并调整负载均衡链路，过程繁琐容易出错。有时也会日常冗余一批服务能力之外的虚机，造成资源浪费。

使用 Docker 容器后，对服务本身，可以做到一键扩缩容。容器的创建、启动、销毁等远比虚机方式快捷、高效。应用本身的环境配置都打包在了镜像中，不用再做额外的虚机初始化，也有效避免了因为虚机硬件和配置不同导致的部署环境问题。此外基于镜像的版本控制，可以方便的进行回滚和灰度发布，减少了发布风险。

在服务调用上，基于 Skywalker 的服务注册发现能力，我们可以不用再关心具体的 IP 和负载均衡链路。客户端的流量从域名→VIP 打到 Skywalker 在多地多中心的机房内。根据请求参数分流出读写请求，路由到注册的投票服务上。对机房网络故障、物理机故障等可以通过健康检查自动的识别和跳过，保证可用性。

在流量控制上，将原基于 Nginx 的虚机限流改为基于 Skywalker 网关的限流，直接在运维页面上调整，操作更加简单便捷。

在日志处理上，因为 Docker 本身的无状态，我们使用公司的实时数据采集处理平台 Venus，将日志引流到 Kafka 和 Elasticsearch 中，并利用实时分析平台 RAP（Realtime Analysis Platform），从 Kafka 引到 Druid 中，构建端到端分钟级延时的可视化实时报表。

QAE 平台和 Skywalker 平台提供了丰富的基础指标（CPU\内存\磁盘\网络等）和业务指标（QPS、成功率、响应时间）的监控报警，可以直接使用。我们也将日志引流后构建了基于 Druid 的细粒度的业务指标监控。运维部署、业务代码与监控做到了解耦。

2.2 高可用优化

得益于 QAE 和 Skywalker 的部署架构，投票服务层本身做到了多地多中心部署。同时在重构过程中，对数据存储层也进行了改造，将项目中使用的缓存和数据库都做到了跨数据中心的高可用。投票项目中用到的数据存储主要是 MySQL、Couchbase 和 HBase，其中 MySQL 用于存储配置信息，Couchbase 作为分布式缓存，HBase 用来存储持久化数据。公司自研的 MySQL-HA 支持跨数据中心的一主多读和故障下的主备切换；Couchbase 在每个数据中心内是独立集群，使用 XDCR 进行跨数据中心集群的双向同步，通过自研的动态客户端 SDK 来支持故障下的业务透明的切换；HBase 使用跨数据中心的双向同步，通过配置中心在机房故障时切换 HBase 集群连接。

2.3 缓存分片集群弹性扩容缩容

投票的数据结构从大的方面可以分为选项维度(VOID)和用户维度（UID）。比如青你的每位训练生就是一个选项，会记录选项的票数；对每个参与投票的爱奇艺用户，会记录用户对选项的投票历史，比如是否已投，投过哪些选项，已投的票数等。从扩展性上来看，选项本身维度不多，访问 QPS 高，不过对容量没有过多要求；而 UID 维度的数量和访问 qps 与活动热度成正比。

基于此，我们垂直切分了两套集群：

图 2 缓存

其中用户维度缓存，通过对 UID 做分片来分散读写压力和扩充单缓存集群容量的限制。并且大型活动本身有生命周期，缓存中的数据不必长时间保存，多个活动之间互相独立，可以针对活动具体的量级来灵活调整分片的数量，在活动前扩容，在活动后回收（数据在底层存储中另外有持久化）。节省了资源的同时，不用再对每个活动再定制化的做代码改造和优化。

2.4 提升异步处理速度

原投票服务使用 ActiveMQ 作为消息中间件，替换成了 RocketMq 物理机集群，性能和可用性都有明显的提高。对消息体做了进一步精简，以增加更大的吞吐量。对票数计数 counter 和持久化存储拆分成了并行的 consumer group 处理。

2.5 开发框架

用 Vue.js 重写了原 js+html 实现的运营后台。重新设计了权限系统，根据活动分配运营权限，每个活动权限又可以细分读写权限，可以进行细粒度的权限管理。增加了审计日志，提高了系统安全性，更好的符合审计要求。投票服务层则重构为基于 Springboot 的开发框架。

2.6 效果

经过上述重构后，投票服务可支持的负载能力有了明显提升。从压测结果来看，在缓存集群没有进一步扩容的情况下，与老系统对比，负载能力提高了 2 倍。扩展性和可维护性也大大提高，不用再维护常规和直播两套代码，对直播等场景可以弹性扩容，对青春有你等大型活动的准备上线时间由半个月减少到 0.5 天。新系统上线后，顺利支持了《乐队的夏天》、《这样唱好美》等活动，并在《青春有你 2》活动中迎来了一次大考。

3 投票与《青春有你 2》

3.1 赛制介绍

《青春有你 2》作为偶青系列 IP 的延伸，赛制与之前一样：通过若干次舞台公演和专业考核，从 109 位训练生里全民票选出 9 人组成全新偶像团体出道。从 3 月到 5 月底的四阶段投票结果决定了每一轮的晋级名单，最终决赛直播时的投票结果则直接决定了成团的 9 人人选。这意味着投票在整个活动中具有非常重要的作用。

3.2 投票渠道

可以投票的渠道包括爱奇艺站内和站外。站内是爱奇艺 app 和爱奇艺泡泡 APP，站外是品牌合作方蒙牛。爱奇艺 VIP 用户比普通用户享有更多的助力机会，登陆爱奇艺泡泡 app 享有额外的助力机会。蒙牛作为拥有唯一官方投票权的品牌，推出了官方助力小程序“真果粒青春福粒社”，购买线上及线下指定产品，扫描活动二维码可获得投票机会。

3.3 审 计

审计的主要目的是对投票系统进行各种测试，验证投票流程和结果的公正、准确性。主要内容包括投票开始前的时钟校验、（运营后台、数据库等）操作权限是否合理，操作审计日志是否合规；投票流程是否跟公布的投票规则一致；系统可用性和数据备份等是否满足要求等。

《青春有你 2》的审计助力于由普华永道中天会计师事务所作为独立第三方专业机构执行商定程序。在节目开始之前，与普华永道工作人员对公证的流程及材料进行了深入的讨论。在节目开始后，普华永道工作人员也多次来到爱奇艺，对每项投票工作都进行了详细的审计，并通过普华永道自己的技术手段进行投票黑盒测试，做票数的独立统计，以确保投票结果的公正、准确性。

3.4 风控

在青你 2 的投票活动中，爱奇艺风控中台团队与互动投票团队紧密配合，为投票安全防刷等保驾护航。涉及到风控的技术细节这里不做展开。

3.5 决赛直播投票

在前四轮投票中，人气在不断在积累上升，在直接决定最后晋级名单的直播投票环节，整个活动的热度将达到顶点，粉丝们的热情将集中爆发，对投票的性能和票数统计等带来了比较大的压力。面对挑战，我们主要做了以下工作：

1.投票链路压测

根据往期节目热度和参数人数，预估出本活动的热度，推演出并发量，模拟线上用户投票，利用 LoadMaker 云压测平台进行真实的全链路压测。压测链路包括投票页前后端、投票后台、风控、会员、Passport、数据库、中间件等，在此过程中项目、测试、开发团队保持了紧密的配合。

2. 服务扩容

投票服务经过重构后的架构，已经能比较轻松的进行扩容，所以扩容本身只是通过申请资源后简单操作即可。除投票服务外，链路中其他可能产生性能瓶颈的点也进行了扩容或优化。

3. 应急预案

投票服务本身已支持多数据中心高可用，对整个机房或某存储、中间件集群不可用等极端情况能做到流量的快速切换；通过 Hystrix 对下游依赖的非关键服务进行熔断降级；通过微服务网关设置了请求流量上限，以保护极端压力下服务的可用性。

4. 票数统计优化

在配合普华永道对投票系统的审计中，票数统计的流程、时效性等是重中之重。在每一轮以及直播，投票结果需要普华永道审计后才能给到节目组进行公布。虽然我们在缓存和数据库中有实时累计数据，不过从审计的角度，需要基于原始数据实时离线统计。在直播时，为了能在每一轮结束后 10 分钟内能及时的统计完选手的票数信息并通过审计，我们跟大数据团队和普华永道多次沟通，最后确定通过两种方案来分别进行数据统计。

图 3 统计链路

· 方案 1

HBas → Hive 计票方案： 两个数据中心的业务 HBase 集群间进行实时双向同步，在故障时可以切换到另外一个集群。业务 HBase 集群的数据实时同步到公共集群后，通过 Hive 来进行数据统计。优化前最慢的 SQL 执行时间为 100 分钟，通过提高 MR 任务并发度、分裂 HBase 大 Region 并设置 TTL，最慢 SQL 时长缩短到 7 分钟。

· 方案 2

MySQL → Hive → Impala 计票方案： 做了异构的冗余备份。投票业务数据异步写入 MySQL，数据复制到 Hive 后通过 Impala 的方式来进行票数统计。原计划通过 MySQL 查询，但因数据量巨大 MySQL 无法跑出结果。MySQL 到 Hive 的数据复制过程耗时约 2 分钟，同步完成后 Impala 查询只需 30 秒，因此总执行时间在 3 分钟以内。

通过这两种方式，统计的实时性满足节目的要求，同时可用性也有保障，并且两条链路同时进行计算，可以对结果做交叉验证。

在活动的整个过程中，普华永道对每个统计脚本、过程和结果都进行了验证。

4 结语

在《青春有你 2》决赛当天，普华永道的工作人员分别驻扎到了节目现场和后方我们技术团队作战室。对操作过程进行了公证、录像，对数据进行了审计。经过公司内多个技术团队的共同努力，决赛直播和投票过程平稳顺利。活动的火爆给各项数据指标都创了新高，投票的读写 qps 都刷新了历史峰值，线上服务及票数统计都一切顺利，在预期时间内完成了票数统计和审计。重构后的投票系统，第一次面临并发量巨大的直播投票，经历住了考验，证明了重构后架构的合理性。

本文转载自公众号爱奇艺技术产品团队（ID：iQIYI-TP）。

原文链接：

https://mp.weixin.qq.com/s?__biz=MzI0MjczMjM2NA==&mid=2247487319&idx=2&sn=d367f9996efbe587d75ee0745179c084&chksm=e9769374de011a6247a5d94fbdfe66e2b7b0adaaa0650eeb4f32bdeb778c4e8f7e233ae2db75&scene=27#wechat_redirect