【100亿次的挑战】之如何在服务有损的情况下保证用户体验

简介: 讲师:Boas   分享主题:如何在服务有损情况下保证用户体验   羊年春晚因着微信摇一摇的介入,变得十分的不一样。而从项目参与者本身出发,100亿次摇一摇、10亿个红包等惊人数据,都是让我们很兴奋的,当然之所以撑起这么大的数量,服务器的多项优化起到了非常关键的作用。

讲师:Boas

 

分享主题:如何在服务有损情况下保证用户体验

 

羊年春晚因着微信摇一摇的介入,变得十分的不一样。而从项目参与者本身出发,100亿次摇一摇、10亿个红包等惊人数据,都是让我们很兴奋的,当然之所以撑起这么大的数量,服务器的多项优化起到了非常关键的作用。作为参与其中的客户端开发来说,我们能做什么?我们扮演的是什么样的角色?而面对春晚这个巨大的项目,我们从哪些方面入手设计?在这里跟大家做一点分享。

 

对于客户端同学来说,常常直面用户的体验问题,而从春晚这个项目本身出发,可预见的是,当时的服务将会有损,在这样的情况下如何保证用户体验,成了我们设计的一个核心。

 

 

一春晚项目简介

 

春晚是一个什么样的项目?它与我们平时遇到的项目有什么不同之处?

 

1. 并发量大

 

春晚是在春节起见发生,而同在春节期间发生的还有“春运”。这两者之间虽然完全不同,但也有其相同之处——需求多、资源少。

 

春晚本身有着很高的收视率,再加上红包的引导,摇一摇的请求量必然会达到这个空前的高峰,服务器也面临着从未有过的压力。除了摇一摇协议本身,还有每个活动背后所需的资源。

 

2. 项目复杂

 

春晚项目不是只有抢红包的10分钟,它的整个过程包括电视互动、好友互动、企业红包、人文艺术等多方面的产品,而其中的细节涵盖到每个节目之间的切换等等。不论是项目参与人数还是产品需求,都是一个复杂的项目。

 

3. 用户预期不可控

 

绝大多数互联网产品都是希望有着越多越好的用户数。但是对于春晚这个项目,却不尽然。由于资源有限,我们希望“见者有份”,尽可能使所有参与者都有满意的收获。因此我们需要对用户预期尽可能地做一些控制。

 

二高并发我们怎么做?

 

1.尽可能少请求资源

 

春晚期间除了摇一摇协议本身的高并发之外,还需要极多的资源请求,如明星拜年的资源、企业红包资源、节目单等等。面对这些资源压力,我们设计了资源预下载的方案。

 

 

客户端通过服务器的通知机制,获取资源信息,并启动下载,得到资源包。由于这些资源都有着保密性需求,所以我们下载得到的资源包都是加密了的。在活动临近时,客户端再获取资源加密的控制信息,并进行解密。

 

另外很重要的一点,我们在整个启动下载、下载成功、重试下载、解密成功等各个环节处都做了上报,监控每个资源的准备情况。

 

 

通过上面的数据展示可以看出,我们很好地平滑了资源下载的压力。

 

2.优化404,提高用户体验

 

纵然我们有了资源预下载的方案,但也不能保证每个客户端都完全地做好了资源的准备,所以,在异常时,我们依旧紧紧关注着用户的体验。

 

首先,我们设计了彩蛋。在用户可预期的活动之外,加入一些搞笑的彩蛋,不仅缓解服务器的压力,同样能够给到用户趣味感。

 

 

另外,我们美化了404。在除夕夜这样合家欢聚的时刻,我们避免数字和科技用语。你看不见“服务器繁忙”“请稍后再试”等冷冰冰的话语,我们给你的是体贴温暖的“陪家人说话”。

 

结 合节日的气氛,我们还设计了一个404页面,鞭炮+服务器。一个作为技术人员不愿见到的界面,但又是一个精巧的设计。这个界面表示服务器这时候压力真的巨 大了,但是这个界面给用户带去的感受是新奇,是无限的想象。“鞭炮下面挂的是礼盒吗?”“我是中奖了吗?”最终一声哈哈大笑,在春晚这个项目中,完美地体 现了有损服务下保证用户体验这个价值观。

 

三项目复杂我们怎样来稳定?

 

1.方案要简单

 

精细的方案设计的确可以带给我们非常细致的体验。但是也意味着有着极多的技术细节要处理,这样带给大家的就是系统更加复杂,稳定性的降低。所以,我们不得不弱化一些灵活性,来得到我们需要的稳定。

 

为了保护服务器,可以支持服务器告知限流时间,限流期间不做请求,减少服务器压力。然后限流时间的设定就是一个需要考虑灵活和稳定双重标准的设计。

 

简单地由服务器传参数作秒数,充分具备灵活性,但若出问题,也有可能出现几百甚至更到的限流时间,将会导致不可用。

 

若是有客户端写死,就充分稳定,但也完全不灵活。

 

两者兼顾,最终协定共用一份枚举,服务器传参表示限流level,客户端查得相关时长,如此,一来保证限流时长都在可接受范围内,二来限流时长可由服务器控制。

 

2. 异常要简单

 

程序运行中,有很多异常会出现,如:企业资源未下载时,去下载?明星拜年没资源时,跳网页?节目ID不匹配时,保留匹配的部分?面对这些问题,我们依旧从稳定性出发,简单处理,直接进入美化过的404。

 

3.系统要可扩展

 

这个项目中,有着很多我们不可预知的变化。系统的稳定,除了很多逻辑要简单之外,必要的扩展性,也是保证可稳定运行的重要因素。在设计中,我们加入通用H5的设计,而这个设计,也是在两次预热和“一年又一年”的需求中,起到了至关重要的作用。

 

四用户预期我们怎么控制?

 

  1. 运营位的引导

 

在红包详情页,设计加入运营位,可引导至春晚摇一摇。这是一种相对较弱的引导方式。

 

2. 红点提示引导

 

红点提示是目前常用的提示能力。在春晚项目中,我们对红点进行控制,可以分平台下发、红点加入有效期控制、一次下发中带有多个红点等。然而,数据标明,红点的能力有限,只能带来一次性的点击量,不能够持久引流。

 

3. 倒计时Banner

用户看到红点,进入活动后,一次的摇一摇后没有结果便会离开。而倒计时的设计,给用户持久的能量,使用户持久参与活动。

 

五我们还做了什么?

 

上述的阐述都在描绘我们如何设计,如何从设计上尽力地匹配海量服务的特点,但是并不能够真正100%地解决一切问题。我们在实践过程中,还意识到一些项目进行中要注意的问题

 

 

  1. 关键问题要追根究底

  2. 把握每次预热的机会

 

由于没有发布前的灰度过程,我们只能依靠预热的机会,发现问题、解决问题。也只有在预热过程中,我们尽力去发现问题,才能真正明确自己的能力,更好地优化,已达到目的。

 

六小结

 

面对像春晚这样海量服务的项目,我们认为“一定会挂,只是怎样更优雅?”我们可以用这样一张图来理解

 

 

原文here

目录
相关文章
|
5月前
|
弹性计算 负载均衡 网络协议
在缓解DDoS攻击方面,如何优化业务架构?
**缓解DDoS攻击的策略:** 1. 缩小暴露面,隔离业务并隐藏非必需服务端口。 2. 使用VPC以增强内网安全。 3. 优化业务架构,进行压力测试,部署弹性伸缩和负载均衡。 4. 优化DNS解析,智能解析并屏蔽异常DNS响应。 5. 提供充足带宽以防攻击时影响正常流量。 6. 服务器安全加固,更新补丁,限制服务和端口,使用防火墙。 7. 建立应急响应预案,定期演练。 8. 考虑采用Web应用防火墙和专业DDoS防护服务。
191 17
|
5月前
|
机器学习/深度学习 图形学 UED
优化用户体验与广告收入平衡的策略:提升IAA游戏变现效率
【7月更文第30天】随着移动游戏市场的竞争日益激烈,开发者必须确保他们的应用既能吸引并保留用户,又能从中获得足够的收入来维持运营和发展。IAA是一种有效的收入来源,但如果处理不当,可能会损害用户体验。因此,了解如何平衡IAA与用户体验至关重要。
286 0
|
存储 缓存 容灾
带你读《多媒体行业质量成本优化及容灾方案白皮书》3. 回源成本优化(1)
带你读《多媒体行业质量成本优化及容灾方案白皮书》3. 回源成本优化(1)
454 0
|
缓存 容灾 调度
带你读《多媒体行业质量成本优化及容灾方案白皮书》3. 回源成本优化(2)
带你读《多媒体行业质量成本优化及容灾方案白皮书》3. 回源成本优化(2)
475 0
|
容灾 CDN
带你读《多媒体行业质量成本优化及容灾方案白皮书》2. 直播质量优化(1)
带你读《多媒体行业质量成本优化及容灾方案白皮书》2. 直播质量优化(1)
431 0
|
缓存 运维 监控
带你读《多媒体行业质量成本优化及容灾方案白皮书》2. 直播质量优化(5)
带你读《多媒体行业质量成本优化及容灾方案白皮书》2. 直播质量优化(5)
433 0
|
编解码 容灾 算法
带你读《多媒体行业质量成本优化及容灾方案白皮书》2. 直播质量优化(3)
带你读《多媒体行业质量成本优化及容灾方案白皮书》2. 直播质量优化(3)
569 0
|
域名解析 缓存 监控
带你读《多媒体行业质量成本优化及容灾方案白皮书》2. 直播质量优化(4)
带你读《多媒体行业质量成本优化及容灾方案白皮书》2. 直播质量优化(4)
521 0
|
边缘计算 监控 容灾
带你读《多媒体行业质量成本优化及容灾方案白皮书》2. 直播质量优化(2)
带你读《多媒体行业质量成本优化及容灾方案白皮书》2. 直播质量优化(2)
426 0
|
编解码 缓存 容灾
带你读《多媒体行业质量成本优化及容灾方案白皮书》3. 点播质量优化(2)
带你读《多媒体行业质量成本优化及容灾方案白皮书》3. 点播质量优化(2)
336 0