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

编者注：本文转自 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 新闻的规模呢？在很快的将来，这些就会到来。