专访魅族架构师：海量长连接的实时消息推送系统的心得体会

前言

本文内容来自ChinaUnix的IT名人堂对魅族系统架构师于小波的专访，于小波分享了在构建魅族海量长连接的实时消息推送系统过程中所总结出的各种心得和体会，希望对正在或即将开发消息推送系统的开发者同行带来一些启发。请往下看正文。

关联文章

于小波在《魅族2500万长连接的实时消息推送架构的技术实践分享》一文中分享了有关魅族实时消息推送架构的一些技术实践，感兴趣的朋友可以看看。

被访者介绍

于小波，系统架构师

2011年加入魅族，主要从事服务端后台开发工作，
专注于系统高并发，分布式等解决方案。

专访内容整理

1您在魅族已经工作四年多了，一直专注于探索分布式系统和消息的高并发，能给我们分享下您的研究经验和心得么？

于小波：我觉得并发和分布是两个不同的概念，并发反应的是量(请求量、用户量), 单台机器也可以有很高的并发量。但是单台机器的性能毕竟是有限的，同时存在单点问题，这种情况下我们引入多台机器来共同协作，提高性能的同时也解决了单点问题，这就是分布式。

在高并发的分布式系统中，个人认为比较重要的几个点：

• 大系统小做，把一个大的系统拆分成很多小的独立的服务，降低系统的复杂性；
• 需要一套成熟的通信框架，来提高开发效率；
• 尽量避免使用多线程，最好是多进程、无锁设计；
• 做好过载保护、监控和灰度。（这个很重要）
  

2近几年，魅族正处于移动互联网的转型期，这个过程中，有没有遇到令您印象深刻的技术难题？

于小波：碰到的问题很多，有些是技术上的问题有些不是技术上的。比如说在开发语言的选择上纠结了挺久。

最后我们选择了c++语言，基于以下原因：

• 性能；
• 人员招聘， c++是比较大众的语言，相对来说人员比较好招；
• 内存可控，这是我们选择c++的一个很重要的原因，内存的使用尽量掌控在自己的手上。因为千万级的用户，如果出现一点内存不可控，最后累积下来是很可怕的。
  

技术问题我这里就分享一个我印象比较深刻的：

我们是长连接服务，手机端和服务端要维持这个长连接，需要定期的发送心跳消息，我们为了节约电量和流量，手机端采用的是智能心跳模式。那么对服务端来说，它是不知道手机端下次是几分钟之后会发送心跳上来的，那么这个连接在服务端的超时时间应该设置多久就是一个问题了。我们的作法是：客户端在每一次的心跳消息中携带下一次的心跳时间，服务端就根据这个时间来设置连接的超时时间（即时通讯网注：这个主意很好！）。

3随着用户量从百万级快速增长到千万级，魅族的实时消息推送系统压力也肯定大增，那是用什么办法解决的呢？

于小波：其实魅族的推送系统并不是一开始就按照千万级的用户量来设计的，我们的架构也是根据实际情况一步一步演化来的。最初，我们做这个推送系统只是为了推送手机固件升级。而且用户量也没有那么多，估计也就是几十万，我们使用很多开源的组件快速把系统搭建出来。这套系统可以满足我们的要求。

随着魅族用户量的快速增长，我们的系统就暴露出了很多问题，只能一个一个坑去填：

• 接入层性能问题：
  原来的接入层单台服务器最多接入30W长连接，而且很多业务逻辑也放在了接入层处理，导致接入层性能低下，而且代码很臃肿，维护成本很高，特别是新员工进来之后拿到这么一大堆代码，都不知道如何下手。所以我们对接入层做重构，把业务逻辑拆分出来，接入层只做简单的用户接入。所有的业务逻辑都在后端处理。也就是现在比较流行的微服务的架构。
• 带宽问题：
  最初我们的系统使用的是文本协议，每次做全网推送都占用了IDC大量的带宽，导致用户访问其他业务非常慢，我们就自定义了一套二进制协议，降低了50%-70%的带宽。
• 服务化的基础组件：
  第一点里面提到 我们的一些业务逻辑是和接入层搅在一起的，我们需要把业务逻辑拆分成单独的服务。服务之间的互相调用就需要一套成熟的网络通讯框架。我们就做了一套RPC的框架，来提高开发的效率。最初这套框架用的多线程+同步调用，在实际的使用中发现，多线程有很多坑，各种锁，特别是新员工写代码一不小心就死锁了。而且同步调用的性能并不理想，虽然开了多线程，但是线程又不能开的太多（大家都懂的）。针对以上情况，我们做了第二版的框架，使用了多进程+异步，服务的性能提高了10倍，但是又面对另外一个问题，因为异步，就没有办法避免各种回调，本来很连续的一个业务逻辑流程被打散在了各种回调函数里面，看代码的人非常痛苦，而且很容易产生内存泄露问题，比如：我申请的内存传递到回调函数中，结果忘记释放了（我们发现的内存泄露问题95%都是这样产生的）。
  
  最后，我们参照go语言的特性使用协程来做了第三版的框架，业务开发人员再也不用考虑同步的性能和异步的回调问题。同步调用方式、异步的性能。
• 存储：
  引入了redis和mongodb来做缓存和消息存储。因为redis是有单点问题，我们开发了一套redis集群，一是提高redis的存储容量，二是解决单点的风险。
  

Mongodb的使用过程中我们也碰到了很多的坑，最主要就是集群的分片，这里我不详细讲了，主要列几个注意的地方：

• 根据业务形态选择合理的片键，尽量手动分片；
• mongodb自带的balancer最好在业务低峰期做；
• 合适的索引。
  

4提到灰度发布，那我想跟您请教一下，灰度发布推送的消息，和其他APP推送的消息有何不同？（例如微信）

于小波：灰度发布的本质是没有区别的，都是一种平滑过渡的发布方式，只是实现方式不同而已吧。和微信对比，我们的推送系统功能比较单一，只要做到让用户无感知的发布即可，另外重要的一点就是降低发布的风险。

5我们了解到，您主要从事服务端后台的开发工作，那有没有什么“过来人”的经验可以介绍给刚入行的朋友呢？

于小波：

• 1）保持对技术的专注和热情；
• 2）多研究一些优秀的开源代码，比如nginx、redis等；
• 3）多逛一下技术论坛 比如chinaunix、csdn等；
• 4）多交流开阔视野 多参加一些技术沙龙的活动；
• 5）最后还是自己多思考多实践，读万卷书不如行万里路。
  

（原文链接：http://bbs.chinaunix.net/thread-4193738-1-1.html）

更多推送技术资料

[1] 更多推送技术文章：
《iOS的推送服务APNs详解：设计思路、技术原理及缺陷等》
《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》
《扫盲贴：认识MQTT通信协议》
《一个基于MQTT通信协议的完整Android推送Demo》
《IBM技术经理访谈：MQTT协议的制定历程、发展现状等》
《求教android消息推送：GCM、XMPP、MQTT三种方案的优劣》
《移动端实时消息推送技术浅析》
《扫盲贴：浅谈iOS和Android后台实时消息推送的原理和区别》
《绝对干货：基于Netty实现海量接入的推送服务技术要点》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《为何微信、QQ这样的IM工具不使用GCM服务推送消息？》
《极光推送系统大规模高并发架构的技术实践分享》
《从HTTP到MQTT：一个基于位置服务的APP数据通信实践概述》
《魅族2500万长连接的实时消息推送架构的技术实践分享》
《专访魅族架构师：海量长连接的实时消息推送系统的心得体会》
>> 更多同类文章 ……

[2] 更多即时通讯技术好文分类：
http://www.52im.net/forum.php?mod=collection&op=all

虽然内容不多，但这样的文字里总能得到些干货，谢谢群主分享过来

干货很多，谢谢分享

引用：kezhaoyuan 发表于 2017-03-21 17:00
干货很多，谢谢分享

受教了！都是干货

谢谢分享