作为爱奇艺倾力打造的青年励志综艺，《青春有你2》公布定档3月12日，并在每周四、周六晚8点播出的消息一出，瞬间就引发了众多关注，不少网友表示：“终于有节目要播出的实感了”。但是，毕竟这是一挡选秀类节目，那么大家知道《青春有你2》怎么进行投票吗？
从资料中可以看到，《青春有你2》的合作伙伴是蒙牛旗下的一款牛奶，为了给自己打广告，他们在产品的包装上，印出了该综艺的播出时间为3月12号，并且在这个包装纸上就可以通过扫码的形式，对训练生进行投票。很多粉丝在看到了这个播出时间后，都在吐槽道：这也太赶了吧，毕竟距离播出的时候也没有几天了，好歹给我们这些真爱粉一个准备的时间，不然的话突然之间播出，自己也没有票去投给喜欢的人，那岂不是麻烦了。
而且。星期四当天学生们都要上课，上完课后肯定是有很多作业或者安排，这样的话就没法第一时间看到节目了， 漏掉一期的话，后面的也就连接不上，很多学生党都觉得这样看来还不如一周一播呢，然后规定在星期六播出。不过大家也别太担心了，节目还没有正式官宣，说不定到时并不是这样安排的，大家还是谨慎吃瓜吧。
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都刷新了历史峰值，线上服务及票数统计都一切顺利，在预期时间内完成了票数统计和审计。重构后的投票系统，第一次面临并发量巨大的直播投票，经历住了考验，证明了重构后架构的合理性。