腾讯信鸽海量移动推送服务是如何构建的

InfoQ：各位观众大家好，我们现在正在 2018 QCon 全球软件开发大会上海站的现场，InfoQ 很荣幸地邀请到了腾讯数据平台部高级工程师郭生求老师接受我们的采访，首先请郭老师简单介绍一下自己吧。

郭生求：好，谢谢主持人，大家好。我叫郭生求，来自腾讯公司数据平台部，最近一直在做的是一个实时的推送系统，叫腾讯信鸽，本人目前的工作主要集中在后台系统的开发，包括系统优化工作。

InfoQ：好的，谢谢郭老师。郭老师，想问一下，你们是通过哪些技术来保证信鸽系统的稳定性的呢？

郭生求：说到这个问题，我们可以从三方面来看：

第一个是后台系统，因为后台系统是一个很重要的一个环节，然后我们通过分布式部署，分布式部署有一个很大的一个好处，单点故障不会影响其他的，我们现在的后台一些治理服务都是通过多个方案选项，快速部署，能快速检测，如果出现单点故障之后，它会自动重新拉起一个新节点来提供服务，同时节点之间是无状态、无差异化的一个服务，这样就能够保证，我的系统一直能够对外提供可靠的服务。

第二点，我们从数据存储方面来说，我们数据是多节点多备份的，能够异地容灾，这种存储方式来保证数据的稳定性，包括可用性。

第三点，在可靠性方面，除了刚才提到的这两点，我们在网络节点这一块，为了让用户能够享受到网络带来的最小影响，我们在多地，包括海外部署了网络节点，这样能够提供更稳定性的网络，来提供稳定的服务。

InfoQ：那目前服务端 SDK，REST API 支持哪些语言？

郭生求：我们现在这个 SDK 支持 Java，还有 PHP，然后还有包括用户自己贡献的 Golong 语言，这个要特别感谢一下这些开发者无私的奉献精神。

InfoQ：那相对来说哪一种语言调用 API 更便捷？

郭生求：相对来说，现在应该是 Java，因为 Java 开发者多，用的人应该是最多的。

InfoQ：信鸽推送系统是如何做用户画像的？底层数据是基于 QQ 和微信用户的行为数据吗？

郭生求：首先回答你第一个问题，就是说信鸽怎么做所谓的用户画像，用户的画像分几种，对我们信鸽来说：第一点，信鸽自定义的一个标签数据，就是自定义的一个画像数据，就是说用户可以自己来定义自己的一个画像，举个例子来说，特别是在业务里，比如以一个游戏 APP 来举例，如果是说那个用户他系统能检测到他用户打游戏打的比较好，或者他级别比较高，你自己定义一个用户标签给他比如大侠，高手什么的，我们提供了一个接口，让用户自己能够打上自己的一个用户画像，用户标签，这是一类数据。

还有一类是我们信鸽系统自己能够识别到的一些标签，一些自己独有的用户的一些数据，举个例子来说，比如说用户他通过什么手机来进行 APP 的业务操作，那我们能够识别它的手机终端，比如它是华为手机，小米手机，或者是怎么样，甚至它的操作系统是安卓什么版本，这些我们也能够采到它的用户画像数据，当然这些数据也是一些公开的数据，不涉及说个人的隐私数据。

所以说，刚才提到的一个是自定义的画像数据，一个是预设的，我们信鸽自己能够采到的一些数据，这两点是我们现在构成的基本的用户标签数据。但这也只是说信鸽自己能够提供的一些标签数据，用户画像数据，其实我们还可以说，跟我们腾讯公司其他的一些业务的一些用户画像数据来进行合作，或者说进行一个对接，可以拿到其他部门的一些用户数据、画像数据来补充我们信鸽的一些画像数据。刚刚提到的说是不是基于微信和 QQ 来的呢？只能说现在不是基于 QQ 跟微信的一个用户画像数据，但是我们跟他们是有一些关联合作，这样子。

InfoQ：那在分布式实时推送环境下，如何保证长连接服务的稳定性和安全性？

郭生求：其实对于我们实时推送系统来说是一个很大的并发量，有亿级的用户，维持亿级的一个长连接是个巨大的挑战，对我们来说，我们是想说第一步是尽量减少那种长连接，比如说一个手机上面，它有多个 APP，它都集成了信鸽的一个 SDK，不可能每个 APP 都维持一个长连接，这种情况下，我们是通过共享服务来共享一个链路的措施来减少长连接的数。减少只是一方面，再减少它也会存在，还是需要一些长连接，那在这一块，我们是通过定制一些饱和、拉活的机制来保证这种长连接的可靠性、可用性。

InfoQ：在移动网络环境下，DNS 服务做了哪些技术优化，保证服务的安全性（不被黑客劫持）和稳定性（运营商 DNS 服务宕机、延迟）？

郭生求：现在很多黑客会利用一些劫持技术，把 DNS 给劫持了，信鸽现在用的是腾讯内部自建的一个 DNS 服务，来保证它的可靠性、安全性。

InfoQ：那在手机端的流量消耗、电量消耗，在选择协议和长连接方面做了哪些优化呢？

郭生求：对 APP 端来说，手机的电量能耗、损耗是比较受关注的一个问题，现在提倡绿色环保，这种情况下，我们刚才也提到了一点，就是我们在 APP SDK 尽量说减少它的连接数，然后通过共享保活 Service 这样的机制来减少连接，也就是说，减少它的能耗，电量的损失。然后同时在 APP 端做一个拉活，那种机制的话，我们还是利用了我们腾讯内部大盘的数据，就是 APP 抱团的方式，抱团的一个方式，举个例子来说，比如说你手机上面安装了王者荣耀，另外再安装一个其他的 APP，这样子，如果你这个 APP 没有启动也没关系，因为王者荣耀相对来说，它的启动时间肯定更长，我们通过王者荣耀来推送到另外一个 APP，这样来减少一个手机的用电量。

InfoQ：在分布式环境下，信鸽推送系统是如何保证信息能够成功的送达用户，就是怎么能保证这个信息发送出去了？

郭生求：现在的安卓系统生态五花八门，比如说华为、小米、魅族，甚至 OPPO、vivo 这些手机，它都会改造自己的所谓的安卓系统，都会做一些调整，每个手机系统都有它的差异性，特别是手机它会限制一些消息，通知栏的展示，这种情况下怎么去保证那个消息能够触达用户，能够让用户看到这个消息？这个方面我们是通过几个方面来做：

第一个是信鸽自建通道，通过其他的 APP，其他的存量比较大的 APP，比如刚才提到的王者荣耀和其他游戏，这种拉活其他的 APP，其他 APP 推送的时候能及时接收到消息，这是我们信鸽自建的通道；

第二，我们现在也是通过集成厂商的一个推送通道，跟厂商合作，我们现在已经集成了华为、魅族、小米，还包括海外的，我们有 Google 的一个 TCM、FCM，他们的厂商通道是所谓的系统级的保活、拉活的机制，这样能够保证你 APP 不在线的时候，消息也能够及时地推送到你手机端去。

InfoQ：如果移动网络不稳定会重复推送一个消息，你们怎么做优化？

郭生求：是这样子的，如果是从终端来看，因为每条推送消息都有个消息 ID，这个消息 ID 是唯一的，那这样子的话，也就是说如果短时间内，两条消息一样的话，我们是会做一些去重的机制，就是尽量不到达客户展示这一块，尽量是不会去重复展示，这是在 APP 端做得一个事情，在 APP SDK 端，在我们后台，我们也有那种去重的机制，比如说你短时间内误操作，连续推送了几条一模一样的消息，那我们后台的推送任务这一块，就会做一个检测，这种的话，我们认为是这个要暂停，或者是说让客户确认这种消息是不是重复推送了，这种机制来保证。

InfoQ：我们知道信鸽推送系统它属于亿级别的并发连接，它在负载均衡上做了哪些技术优化的点？

郭生求：现在那个实时推送系统已经到了一个亿级的连接，怎么保证连接一直可用？在负载均衡这方面，我们是利用腾讯内部的 I5 的一个负载均衡的组件，这种组件最大的好处是，能够实时动态地检测各个节点的状态，如果某一个节点它处于不可用的状态，它会及时上报一些故障的信息，动态地去调整，做一些状态的切换。

InfoQ：最后还想问一个问题，就是信鸽推送系统在服务监控、报警方面有什么经验跟大家分享吗？

郭生求：在我们内部是一个立体化的监控，什么叫立体化呢？首先我们内部系统有自己的运维，或者是测试，或者是我们开发人员能够看到的一些内部的接口，调用成功率、失败率我们会实时监控，并实时地展示出来，并设置一些阈值，如果超过了某个界限，我们就会有实时地告警，来提醒我们去关注这方面的指标，这是我们内部的工作，在客户层面，我们也能够动态把每一个客户做的推送效果实时地展示出来，比如说推送下去之后有多少消息是推出去了，有多少消息是抵达了客户，并且展示出来了，或者是说有多少客户是点击了，这些数据我们也能够实时做一些监控。

嘉宾简介

郭生求，腾讯移动推送，高级工程师。

2006-2016 年华为近 10 年通信后台、IoT 平台开发经验，2016 年加入腾讯公司 TEG 数据平台部，主要负责腾讯移动推送平台—信鸽的后台研发和优化工作，对分布式计算有深入的了解，有丰富的后台架构优化的实战经验，对构造实时性、高可用、高性能的分布式大数据处理和推送系统有丰富的实战经验。近期主要工作是优化信鸽精准推送后台系统，包括精准用户分群、实时推送、实时推送效果跟踪、多厂商通道推送等，更好的满足公司内外部 APP 用户的需求。

活动推荐

12 月 7 日北京 ArchSummit 全球架构师峰会上，来自 Google、Netflix、BAT、滴滴、美团 等公司技术讲师齐聚一堂，共同分享“微服务、金融技术、前端黑科技、智能运维等相关经验与实践。详情点击 https://bj2018.archsummit.com/schedule