写点什么

一年只用一天的系统如何做技术沉淀?

  • 2019-12-05
  • 本文字数:3759 字

    阅读完需:约 12 分钟

一年只用一天的系统如何做技术沉淀?

今年是双 11 的第 11 年,猫晚的第五年。


今年的天猫双 11 狂欢夜(简称“猫晚”):有超 200 个国家和地区通过优酷 APP 观看猫晚直播;共有 5144 万人通过猫晚公益直播间观看明星卖农货,网友在淘宝直播间点赞 1 亿次。今年猫晚海外艺人参与的节目超过了四成,晚会版权输出到 106 个国家和地区,实现了除南极洲外的全覆盖。



2019“猫晚”现场,图为腾格尔唱《High 歌》


2019 猫晚不仅在优酷,还打通手淘、天猫等 APP,实现了多屏、多端、双向的互动,将互联网晚会的互动形态推进到 3.0 时代。如晚会上跑男队和街舞队在一个 4×8 米的巨型触摸屏上玩起了“好礼对对碰”游戏。优酷和淘宝的网友在 APP 端也可以选择加入某一战队,游戏比分实时计入明星嘉宾的成绩中,影响节目进程。观众还可以通过互动打赏给喜爱的节目“打 call”,优酷直播间 63%观看晚会的用户参与了互动,较去年增长 7%。


很荣幸,我能有机会参与到双 11 猫晚项目,借这个机会给大家分享技术在猫晚落地的过程和思考。

技术目标如何定

猫晚 KO 时,总负责人说猫晚是给天猫双 11 消费者办的晚会及回馈,所以我们目标不仅要给消费者提供视觉盛宴,还要给消费者带来实惠,要给商家带货;虽然自古忠义不能两全,鱼与熊掌不可兼得,但是项目组同学即使执手相看泪眼竟无语凝噎也要咬牙接下有挑战的目标。基于这几个方向团队开始做分解,猫晚产品技术运营设计团队核心要承载晚会的传播影响力、丰富有趣的互动形式、以及进店的引导和让消费者实惠的权益发放。


明确定位后猫晚的核心业务目标相对就清晰了,基于业务目标技术同学进一步分解首要是业务目标支撑,稳定是底线、体验要保证、权益全发放、不能有资损(还有团队有成长、系统有沉淀)。



业务技术大图


所以猫晚技术目标制定的思考路径是,首先是看行业、看大盘、看业务、看团队;然后分解目标,找到关键指标和抓手及相关团队;最后去量化,定有挑战的指标和倒计时的里程碑



制定技术目标图


技术如何保障公平一致的体验

体验一致是因为晚会公域互动主打手淘、优酷、天猫 APP,为即将到来的双 11 预热,让用户在看晚会时候就能边看边玩、边玩边买,所以主持人口播时候每次都会提醒打开手机摇一摇可以在手淘、天猫和优酷 APP 参与互动,这就要求多端需要同时弹起和关闭互动、展示内容一致、玩法一致、抽奖时间一致。


基于以上几个需求,猫晚今年的解法是第一次完全一套代码,运行到手淘、天猫和优酷,在优酷侧部署的代理服务只承载转发和适配不做其他任何业务、核心服务部署到集团机房承载所有的互动玩法和权益发放,技术架构图如下:



技术架构图


提到公平,为什么存在公平性的问题?


核心原因在于因为不可抗力的用户网络延迟、现场信号延迟以及内容生产制作过程中的延迟,如果技术上不处理可能存在的问题大家互动弹起的时间分布完全不同,那么很可能你还没开始游戏或者正在玩游戏,有的人已经把那些一元购以及终极大奖替你还 49999 花呗的权益抽取完了,这个带来的挫败感和不公平感实在叔可忍婶婶不可忍,所以猫晚引入了以下四个机制来保障:


  1. 客户端和服务端通过 CSN 及无线 RPC 网关轮询对表,保障客户端维护的时钟和服务端一致;

  2. 现场布置延迟机,反复实测现场延迟以及内容制作过程中的延迟时间;

  3. 运营操作节目单事件点击和主持人话口与导演组反复沟通及演练对齐;

  4. 最后根据 2 和 3 的时间 delay 在直播流中插入 SEI,内容消费端再解析 SEI 信息,根据节目开始时间弹起互动。

高并发脉冲流量如何抗

猫晚比较典型的是打底常驻流量一直有,然后每轮互动带来脉冲流量,针对这些场景猫晚这面的核心思路是以下三板斧:多轮全链路压测、应用预热、防刷限流兜底;以上三点可能大家都比较熟悉每次大型活动的默认项,除了以上点还可以聊一聊比较有晚会特色的优化比如削峰、路由、下游保护。

1 路由

猫晚比较典型的打底流量节目单 polling,所有同时在线用户每 45S 都会轮询一次,技术同学准备了路由方案,默认所有请求 100%走无线 RPC 网关,但是可以动态下发路由比例给前端,当无线 RPC 网关压力较大或者即将超过目标限流值时或者流量评估模型有问题时可以走预案切换比例到轮询 CSN,以保障系统稳定性。


总结:根据流量情况动态路由分发是兜底和保证体验的利器。

2 削峰 &错峰

错峰:


a、公私域互动在节目进程中叉开投放时间,避免并发同时来临;


b、20 点及 21 点集团有红包雨,和导演组沟通及演练互动错开整点的前后几分钟,防止给权益平台带来集中压力;


c、在私域像红包雨、入场红包、密令红包等互动通过中间件消息下行通道投放,降低私域服务端压力。


削峰:


a、客户端向后台提交数据有压力的点都采用在一定时间范围内随机打散算法;


b、红包雨控制中奖率,同一个用户的多次点击可以配置有效请求数;


c、终极宝箱个数查询提前打散异步 15S 预查询,避免集中冲击;


d、获得终极宝箱后客户端维护有无标志,挡掉开奖时一部分的集中查询。


总结:削峰和错峰需要体验+业务+技术手段相结合,避免技术上过度设计和优化,ROI 低。

3 下游保护

猫晚发放核心依赖权益平台,每轮互动结束后都会有抽奖环节,抽奖就要调用权益平台,比如终极大奖开奖时有两个要求:


a. 所有用户都可以参与抽取,如果用户没抽中大奖还可以抽打底奖池;


b. 要保证大奖全部发出,否则算资损。


这里如果让所有用户先走全部抽大奖然后不中的再来抽打底,就会两次调用权益平台,对下游的调用直接 double 而且权益平台大奖奖池口也无法承载这么高的流量(大奖权益平台会直接同步操作 DB),无论从性能上还是从价值及成本上来看必要性都不大,基于此判断项目组定了以下三个优化 action:


a. 从业务规则上告诉用户宝箱越多概率越高;


b. 从应用上直接分流宝箱较多用户抽大奖奖池,宝箱较少用户直接抽打底奖池;


c. 从技术上实时监控统计宝箱分布情况,在前面轮次一旦发现宝箱分布和预期业务规则不一致,启动提前预案,保证大奖必然全部发放。


总结:下游稳定全链路才能稳定,系统设计时要充分考虑对下游的保护。

现场大屏和小屏联动花絮

这里想给大家分享一个猫晚关于预案的小花絮,提醒每个同学预案一定不能只留在预案平台上,需要可应急、可执行、已演练、甚至需要准备备胎的备胎。


为了让内容和互动更精彩,结合更紧密,项目组同学提出要做双向互动,让用户有更强的参与感,去支持自己喜爱的明星并同步参与一样的游戏,数据实时回流现场影响最终 PK 结果。


做双向互动以前没有先例,因为有以下问题要解决:


  1. 现场环境复杂,对设备及通讯等都会有干扰;

  2. 链路长,可控性差,除猫晚内部团队协同外还涉及导演组、主持人、明星等外部配合;

  3. 直播现场突发情况多,对应急能力要求高。


果不其然从需求反复调整对齐,CodeReview 以及全链路压测,手淘天猫集成,集团技术汇报,直播演练及和导演组对话口一路解决各种风险;等项目组同学进入现场后才发现以前的问题只是毛毛雨,先看下时间轴和现场大屏和直播画面示意图:


  1. 9 月份就开始提前启动在广州、东莞、虎门等地多次实测现场大屏效果,进场前确认完全没问题;

  2. 11.6 进入现场第一次排练就发现现场信号嘈杂,触摸屏触摸会失灵,现场每次可以给的检修时间非常有限;

  3. 11.8 号依然未能修好,和导演组沟通希望尝试预案演练;

  4. 11.9 号晚明星彩排吊威亚看台同步配合操作,看台给的机位切换,导致看不清大屏操作,演练效果依然不好;

  5. 11.10 上午导演组一度考虑拿掉该环节;

  6. 11.10 晚上现场同学顶住压力,完美呈现首次双向联动。





现场和线上双向互动图



大屏交互示意图


回到现场大屏操作异常时准备的预案,重点说明进场前技术准备的只有一级预案,后面的全是随机应变根据现场情况和产品同学一起讨论临时制定的预案。


  • 一级预案晚会前演练触摸使用,异常检修;

  • 二级预案是无法检修换大屏机器;

  • 三级预案是大屏机器无法更换,需要看台固定 1 机位,导播车有 1 人保证机位不会切换,看台口令员和操作员配合键盘同步明星现场操作;

  • 四级预案是操作员 1 的电脑或键盘异常,热备 2 机器和热备 2 同学操作。


总结:


  1. 预案一定要可应急、可执行、已演练、甚至需要准备备胎的备胎;

  2. 技术要有追求,多想可能的办法,时间越紧张越要把预案做细,做简单。

总结:一年只用一天的系统如何做技术沉淀

像天猫双 11 晚会类似的项目,平时不承载流量,没有专门的维护团队,随着猫晚启动抽调各个团队来共同承担,参与到项目的技术同学该如何让自己成长和收获呢?我自己总结有以下几点:


  1. 学会思考和制定技术目标;

  2. 锻炼技术 PM 能力,不设边界,有技术预判,识别解决风险,保障目标坚决落地;

  3. 有匠心:对性能和体验及技术方案上需要极致、细致;

  4. 为后人栽树:工具、组件、产品、组织能力沉淀;

  5. 复盘能力:复盘从参与项目的第一天开始,思考突破与沉淀;

  6. 拓宽视野:偶尔跳出专业领域,发现技术外的视角,看其他领域及合作团队的思考,学习周边优秀的小伙伴。

感谢

因为人员太多,无法一一感谢,感谢阿里文娱猫晚的所有同学,因为有我们 2019 双 11 猫晚更精彩。



入驻现场的我们



猫晚开始前现场作战室的我们



现场没时间看易烊千玺、看泰勒、看马老师的我们


2019-12-05 13:346128

评论

发布
暂无评论
发现更多内容

快速开发那点事儿 | 选择最合适的轮子,量产跑车

Java_若依框架教程

敏捷开发 JAVA开发 RouYI 快速开发

MyBatis 3 解析Mapper映射配置

杨家昌

mybatis 配置 Mapper XMLMapperBuilder

关于架构的几件小事:架构是什么

北风

架构 企业架构

iTerm2使用小技巧-密码管理器

小菜与老鸟

iTerm

MyBatis 3 解析mybatis-config.xml配置

杨家昌

深度解析 mybatis 初始化 XMLConfigBuilder Configuration

Flink 作为现代数据仓库的统一引擎:Hive 集成生产就绪!

Apache Flink

大数据 flink 流计算 实时计算

专题:快速开发那点事儿 | 轮子怎么选

Java_若依框架教程

Java 敏捷开发 Ruoyi 快速开发

开源一个自研的基于Netty的高性能网络通信框架

Geek_373e87

TCP dubbo Netty

Flutter 中SharedPreferences 的初始化?

三爻

flutter android

源码分析shared_ptr实现

泰伦卢

c c++ C#

小米手机广告在日本「炸」了,背后的教训是什么?

葛仲君

产品 本地化 小米 日本 文化

央行:取消境外机构投资者额度限制,推动金融市场进一步开放

kimmking

IT人的职业提升只靠技术精进行的通吗?

MavenTalker

程序员 程序人生 职业规划 技术人

spring boot 集成 elasticsearch 7.x (一)

wd

elasticsearch high level client

中年危机,我们如何面对?

石云升

算法篇之数组右移

月夜

算法 数组右移

基于大疆无人机SDK二次开发

sydMobile

android 无人机

游戏夜读 | 有哪几种游戏玩家?

game1night

没有业务规则的技术实现

wd

吐槽

第一篇InfoQ的博客

程序员小岑

写作 体验

为什么很多技术都觉得前端很简单?

极客时间

大前端

讨论:应不应该用存储过程?

kimmking

地址收录

gogogo

言简意赅,聊聊RPC的123事

一叶而不知秋

RPC

MyBatis 3 XML配置

杨家昌

mybatis mybatis-config.xml XML配置 配置

自助设备系列——自助设备的春天

孙苏勇

产品

hive 建表语句迁移

飞哥

new[]和delete[]为何要配对使用?

泰伦卢

c c++ C#

【预告】千亿数据的潘多拉魔盒:从分库分表到分布式数据库

kimmking

分布式数据库 分库分表 分布式系统 中间件

一种消息消费失败的处理方案

redis kafka

这样理解Java中的函数式编程就对了

jerry

java8 函数编程

一年只用一天的系统如何做技术沉淀?_文化 & 方法_郭超_InfoQ精选文章