腾讯新闻如何以技术支撑海量服务

标签: 腾讯 新闻 技术 | 发表时间:2014-04-17 18:14 | 作者:腾讯大讲堂
出处:http://www.geekpark.net/

作者头像
作者: 腾讯大讲堂 / 产品观察家
腾讯大讲堂:给成长加点料。
[核心提示]腾讯新闻海量用户访问的背后有着怎样的技术支持?新闻客户端的未来将走向哪里?

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


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

  1. 跟产品、运营的合作的一些技术原则;
  2. 移动端海量服务的特点。

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

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

  • 新闻是基础需求之一,使用频率属于次高级别,比通讯类服务低,比电商类服务高。有些很重要的新闻,虽然用户不一定要看细节,但必须要知道这件事,所以要 push 给所有的用户;
  • 覆盖面广,不同的人群、地域、运营商都要覆盖到;
  • 突发性强,尤其是重大新闻爆发时,瞬间 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 新闻的规模呢?在很快的将来,这些就会到来。

极客观察均为极客公园原创报道,转载请注明原文链接。

原文地址: http://www.geekpark.net/read/view/203266

关注极客公园,即时获得最新内容: Twitter | 微信:极客公园 | 新浪微博 | 花瓣网 | 人人小站 | Google+ | 点点

相关 [腾讯 新闻 技术] 推荐:

腾讯新闻如何以技术支撑海量服务

- - 极客公园-GeekPark
[核心提示]腾讯新闻海量用户访问的背后有着怎样的技术支持. 编者注:本文转自  InfoQ. 在 2014 年 4 月 11 日的腾讯分享日活动上,腾讯 OMG 移动媒体产品部助总郑坚分享了有关腾讯新闻海量服务的一些技术技术原则. 腾讯很多海量服务的意识和规则都是从 QQ 演化出来的,即使从移动互联网的角度来看,当时的很多规则也很贴切.

温州动车劫——媒体封面_腾讯新闻_腾讯网

- Robert Mao - 牛博山寨 编辑推荐

腾讯陈军:腾讯云平台与技术实践分享

- Sepher - 服务器运维与网站架构|Linux运维|互联网研究
[第三届中国云计算大会]2011年最受瞩目的IT业界盛会——第三届中国云计算大会于2011年5月18-20日在北京国家会议中心隆重举行. 本次大会由中国电子学会主办,中国电子学会云计算专家委员会、中国云计算技术与产业联盟承办,CSDN网站、《程序员》杂志和电子工业出版社协办. 5月20日,在第三节云计算大会分论坛二“云计算平台与应用实践”中,腾讯网络平台部技术总监陈军带来了主题为《腾讯云平台与技术实践》精彩演讲.

近期的一些技术新闻

- zffl - 我的宝贝孙秀楠 ﹣C++, Lua, 大连,程序员
我在《敏捷之旅2011大连站暨QClub大连站2011年第三期》上跟着凑热闹,也有一个关于GAE的session,大连的朋友欢迎捧场. IronPython2.7.1发布了,写了一个关于IronPython的PPT,大家可以看看,蜻蜓点水介绍一下DotNet下使用IronPython. IronPython使用Sqlite.net.

新闻技术创新的新框架

- - 36氪
受纽约市立大学的新闻创业中心(Tow-Knight Center for Entrepreneurial Journalism)的委托,该大学的Nick Diakopolous博士发表了一份白皮书,称新闻业跟计算机科学有很多共同点,因为大家对信息的关心程度都是根本性的:即需要考虑信息如何进行获取、存储、修改/编辑,然后展现.

走出腾讯:一个80后技术人的信仰

- - IT瘾-tuicool
栏目简介:激荡六十年,人工智能已经起航. 然而在未来面前,我们都还是孩子. 为了解惑,《AI名人堂》将汇聚领航者智慧,和你一起探索前行的方向. 出品 | AI科技大本营(ID:rgznai100). 18 年前,如果没有 Foxmail 卖给博大,博大后又被腾讯收购,或许也就没有李明强如今的模样. 从 2005 年到 2012 年期间,偏居广州的张小龙团队四处突围,QQ 邮箱由死向生,微信从零至一.

腾讯万亿级 Elasticsearch 内存效率提升技术解密

- - IT瘾-dev
作者:morningchen,腾讯 TEG 后台开发工程师. Elasticsearch( ES )是一款功能强大的开源分布式实时搜索引擎,在日志分析(主要应用场景)、企业级搜索、时序分析等领域有广泛应用,几乎是各大公司搜索分析引擎的开源首选方案. Tencent ES 是内核级深度优化的 ES 分支,持续地进行高可用、高性能、低成本等全方位优化,已支撑的单集群规模达到千级节点、万亿级吞吐.

腾讯信息流热点挖掘技术实践

- - IT瘾-dev
分享嘉宾:罗锦文 腾讯 研究员. 编辑整理:Jane Zhang. 出品平台:DataFunTalk. 导读:当前各大资讯社交类APP都在显著的版面展示或者推荐热点相关内容,信息流应用能否快速发现热点、引导用户阅读热点,是影响用户体验的重要因素. 本次分享主要介绍腾讯在热点挖掘方面的工作. 基于搜索数据和自媒体文章,通过时序分析方法和内容聚类相结合的方法挖掘热点,并将热点聚类成事件和话题.

腾讯微博技术总监张松:响应速度是第一体验

- - 微博之博
腾讯科技讯 8月12日消息,从2010年4月上线,到2012年,短短两年时间, 腾讯微博已经拥有超过4亿用户,不少用户的听众都已经突破千万,面对快速的增长,腾讯 微博在架构方面有哪些变化呢. 8月10日下午,在全球架构师峰会上,腾讯微博事业部技术总监张松国对腾讯微博的架构成长做了详细的阐述. 腾讯微博事业部技术总监张松国分享腾讯微博架构变化(腾讯科技配图).

腾讯在信息流内容理解技术上的解决方案

- - IT瘾-tuicool
作者:weidongguo,腾讯 PCG 应用研究员. 目前信息流推荐中使用的内容理解技术,主要有两部分构成:1、门户时代和搜索时代遗留的技术积累:分类、关键词以及知识图谱相关技术;2、深度学习带来的技术福利:embedding. 但是分类对于兴趣点刻画太粗,实体又容易引起推荐多样性问题,而 embedding 技术又面临难以解释的问题.