腾讯分享日干货之腾讯新闻的海量服务

在2014年4月11日的腾讯分享日活动上,腾讯OMG移动媒体产品部助总郑坚分享了有关腾讯新闻海量服务的一些技术原则。本文根据这次分享内容整理而成。

腾讯很多海量服务的意识和规则都是从QQ演化出来的,即使从移动互联网的角度来看,当时的很多规则也很贴切。我下面的分享主要从两点展开:

1. 跟产品、运营的合作的一些技术原则

2. 移动端海量服务的特点

我负责的移动新闻客户端,在两年半前接手的时候还是比较小的,到现在安装量早已过亿,日活跃用户量在千万级,很多用户从微信和手机QQ进来。从比较小的规模成长到现在这么大的规模,遇到很多问题。

移动新闻类服务有几个特点:

1. 新闻是基础需求之一,使用频率属于次高级别,比通讯类服务低,比电商类服务高。有些很重要的新闻,虽然用户不一定要看细节,但必须要知道这件事,所以要push给所有的用户。

2. 覆盖面广,不同的人群、地域、运营商都要覆盖到。

3. 突发性强,尤其是重大新闻爆发时,瞬间push的流量是日常流量的好几倍,对服务质量的要求也很高。

下面从产品、技术、运营这三个层面分享一下我们的感受。

产品

聚焦核心需求,少即是多:我们从非常小的产品长起来,最初要做的比较小,功能少,现在的专题、直播、图文、离线都是后来加的。一开始是因为人和资源有限,必须逼迫自己要去聚焦最核心的需求;随着发展慢慢就会觉得很多东西可以做,但像是新闻这种基础性的服务,用户对产品是有预期的,他会预期一个新闻类客户端能够满足他的什么需求,所以,一定要把基础需求做到极致,之后才能考虑做别的,否则做了效果也不好。

不要过度设计,考虑普适性:海量产品是要接受所有用户群的。App客户端跟HTML网页有一个不同在于,HTML对于各种交互应该如何处理都有约定俗成的规则,用户对一个网页会如何响应自己是有预期的;而App则可以想怎么做就怎么做,比如Flipboard就做出很好的体验来,但是有这种自由度,反而会陷入怪圈。比如,新闻有一个基础需求是要切换频道,一开始所有的客户端都是把导航栏平铺的。后来有段时间有个趋势,很多App把导航系统改成了左划的方式。比较新颖的设计方式有一个问题,就是会导致用户要去想。对于比较新的设计,我们有一个简单的衡量方式:看看家里的老人能不能用这个App,只需要观察一阵就知道适不适合上了。测试之后,我们觉得还是很土的设计比较没有障碍,就没有改。

要90%不要80%:一个功能至少要做到90%,最好是接近100%。千万不要做很多功能,每个都是80分,找不到特别好的点。其实我们的App做了这么多东西,90分的东西非常少。一共四个tab页面,图片跟视频占了两个,但是用户点进去之前预期是什么?点进去之后预期能不能达到?第二天用户会不会回来?这些问题现在都没有很好的解答,事实上现在我们90%的任务是在第一个新闻页卡完成的,后面的tab都没有做到90分。产品、技术都要想清楚,一个是因为只有这么多资源,哪个能做好就专注做好哪个;另外也因为用户的注意力有限,不要用不好的东西转移他的注意力。海量产品的每一个位置都要想清楚它能不能达到要求。

功能多闭环,多问now what:相对垂直小众的产品,用户使用的比较深入,可以一直往下做;但是通用产品很难这样做。如果你有很多想法和设计思路,做完了原型之后要问一句:now what?举个最简单的例子,社交化、个性化的演化。腾讯有qq关系链,所以就有人提议新闻客户端做好友阅读圈,看别人阅读过、评论过的东西。于是原型做出来,用了几天之后,有一个问题:读了之后干什么?这是新闻,不像小说,新闻的特点是短、时效性强,用户进来好友阅读圈,看几天前看过的东西有什么用?另一个例子,就是个人中心,做个性化,比如点击别人的头像可以打开这个人发表过评论。做了之后发现也有问题:进去一看,质量也不高,内容也是老的,而且是流水账居多。用户下一步做什么?这样的个人中心设计就很不好。所以,如果没想清楚一个东西做出来能干什么,就不要放出去,否则收不回来。一旦放出去就会有很多挑战和压力,团队难以控制。

开发

快速迭代,小步快跑(动态运营的开发模式):非常多子系统和功能都是这么做的,这是非移动互联网就已经认同的原则。

快和稳定超过精巧性。这个和干干净净做系统也是符合的,这样做出来的东西,下一步演化、debug问题都很轻松。

快、允许出错。这一点可能跟上面说不要随便加东西有些矛盾,说到底还是一个度的问题。大方向是一定要把握的,不能乱放;但是细节调整是可以更快的放出去。运行一个版本要可以很快的纠正,这就是说你心里要有纠正的预期,放出去之前就要把功能开关都做进去。

边重构边生活。新闻客户端的后台从是腾讯网延续过来的,有很多基础服务,比如评论是5、6年前构建的,很老,后来的一些新功能,比如聚合回复、带上地理位置、支持上传图片和短视频,都是升级迭代上去的。这些功能的加入过程可以说是客户端和后台团队互相牵拉着走,有些时候我们客户端送到苹果应用商店审核的时候后台都还没做好,可能审核通过的时候是后台刚出来的时候,而且刚开始上线的时候机器、容量都没有放到最大,都是在运行中提高的。

运营

快速灰度。我们的新闻客户端做比较快速的灰度,比如常规灰度是按周,这边则是按天甚至小时来做灰度。为什么这样做呢,第一,我们产品客户端本身的迭代速度比较快,一般4~6周就有一个东西出去;第二,一个功能放出去如果不能很快灰度到一定数量级,就看不出表现,因为我们的技术功能跟运营商分布、网络稳定性有关,灰度太小,即使放到20%,这20%里面又有20%的波动,误差太大,真实的效果就看不出来。所以我们的策略就是快速推出去,实在出问题就回滚,责任我这边担着。

有损服务。要分清哪些业务可以有损,哪些必须无损,另外无损也有严格的和非严格的。有损服务这块下面我会详细介绍。

扛住再优化。这个不需要多说。

立体监控。很早以前我们是按网站的监控级别,可能是5分钟抓一次数据,这样到移动端就不行了,可能监控出来有问题的时候就早已经崩溃了,回头看监控数据也不知道什么时间来的峰值、峰值到了多少。现在我们是按5秒的监控级别。

下面介绍一个有损服务实例,就是我们突发新闻push的一次经验。

突发新闻的特点是瞬间峰值极高,这点跟其他亿级产品有一些不同。比如马航失联的新闻,我们推送iOS客户端在千万级,Android客户端千万级,发送时长2分钟,点击率大约在25%。我们还配了头图专题和图文直播。实际上这里面还有个情况,就是我们北方节点的部分用户没有push到,因为北方节点有三分之一的机器配置比其他机器低一些,但我们push的时候没有调整分配规则,就导致这三分之一的机器死掉了,流量跑到剩下的三分之二的机器上,又把这三分之二也搞崩溃了。中间我们导流北方用户到深圳节点,后来深圳节点无法承担全国流量,又导回了北方。总之都这样下来,最终我们的访问量是7倍于日常的访问流量,以及3倍于日常的接口调用数。

对于本次新闻,我们制定了如下的有损服务规则:

重点接口重点保障,次要接口有损保障:28原则,用60-70%的资源保证20%的重要接口。另外就是紧急降级,把图文直播自动刷新、下拉自动刷新等造成不必要的资源请求的功能取消。

缓存前移,分布化,用大量memcache。前端proxy缓存,后面是mc集群,解决超热key问题和大key(>200K)的问题。另外设置了5秒的timeout,相当于是有损服务。

优化TCP协议,提高TCP初始化拥塞窗口大小(从3改到10),减少RTT,提高数据传输速度。

容量模型,接口设置最大连接数,通过预知及早拒绝,防止雪崩。现在已经有一些预知能力。

APC缓存,高并发时底层页静态化以降低后台请求。另外就是分区域保障,一线城市做为重点,二线城市提供有损服务。

对于新闻客户端未来的挑战,我觉得有两点:

一个是视频时代的挑战。越来越多的内容带有视频,而视频带来的流量跟图片的数量级完全不同。这是关于突发、大流量支持方面,新闻客户端未来的挑战。

第二个是直播互动化的挑战。传统媒体可能是电视或者广播直播,一对多的模式,顶多加上热线电话拨入做为互动方式。而现在的直播是可以让用户直接接入并呈现他们的接入,这种模式会更加复杂。手机随时随地让用户可以跟踪,参与一场多媒体的互动直播。如果这个scale推广到微信新闻,手Q新闻的规模呢?在很快的将来,就会到来。

原文发布于微信公众号 - 腾讯高校合作(Tencent_UR)

原文发表时间:2014-04-15

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏云计算D1net

虚拟化应用需要IT融合基础架构

提起服务器,大家都知道过去经典的分类法是根据服务器形态来区分,包括塔式、机架和刀片服务器,这似乎已经成为了官方教科书。但是,随着虚拟化应用和云计算的发展,虚拟化...

3638
来自专栏腾讯云技术沙龙

大咖说:如何借助腾讯云简单、高效移动开发

一直以来,如何能够更快速地构建高性能,高扩展的移动应用一直是移动行业的热点。在传统模式下,开发者通过手动集成所需的各种移动服务,和后台紧密配合去打造精品移动应用...

94216
来自专栏EAWorld

企业级应用的高可靠运维实践与DevOps(一)

? 很高兴今天有机会在这里与大家交流,也要感谢普元提供的交流平台和普元CTO焦总的邀请。我今天与大家分享的主题是关于企业级应用的可靠运维实践的这个话题。 ? ...

4169
来自专栏腾讯大讲堂的专栏

浅谈用户体验的可视化

记得初学设计时就常常听到这么句话,设计不单单是做出一个极具美感的躯壳,更重要的是它背后的实用价值——所谓设计的实用性。而在互联网里,这种实用性更多的体现在用户体...

1976
来自专栏云计算D1net

存储虚拟化想法好!但改造传统系统能力仍受质疑

传统存储解决方案的弊病很多,这些弊病多由异构存储和SAN孤岛造成。异构存储是说在企业IT系统中,存储设备往往来自不同供应商。不同的供应商意味着不同的底层架构、不...

34412
来自专栏猿天地

开发十年,只剩下这套Java开发体系了

蓦然回首自己做开发已经十年了,这十年中我获得了很多,技术能力、培训、出国、大公司的经历,还有很多很好的朋友。

1083
来自专栏程序你好

DevSecOps的三种解读

1151
来自专栏Java架构

阿里十年,只剩下这套Java开发体系了

蓦然回首自己做开发已经十年了,这十年中我获得了很多,技术能力、培训、出国、大公司的经历,还有很多很好的朋友。但再仔细一想,这十年中我至少浪费了五年时间,这五年可...

1624
来自专栏何俊林

开发十年,只剩下这套Java开发体系了

蓦然回首自己做开发已经十年了,这十年中我获得了很多,技术能力、培训、出国、大公司的经历,还有很多很好的朋友。

1223
来自专栏云计算D1net

想开发云应用程序?先选择合适的PaaS!

从一个方面来分析,开发云应用程序的平台即服务模式有两种:一种是专用模式,托管在本地或私有云中;另一种是公共模式,由第三方提供商来托管,并采用订阅支付模式。那只是...

4246

扫码关注云+社区

领取腾讯云代金券