嘉宾介绍
于小波，系统架构师，2011年加入魅族，主要从事服务端后台开发工作，专注于系统高并发，分布式等解决方案。文章源自运维生存时间-https://www.ttlsa.com/news/meizu-about-real-time-push/
duke217（Q1）：于老师，您好，很高兴有机会采访到您！您能否先和大家介绍一下自己？文章源自运维生存时间-https://www.ttlsa.com/news/meizu-about-real-time-push/
于小波（A1）：各位网友，大家好，我是于小波，来自魅族移动互联网部门，2011年加入魅族，目前主要从事服务端后台架构设计和开发工作。文章源自运维生存时间-https://www.ttlsa.com/news/meizu-about-real-time-push/
duke217（Q2）：我们了解到，您在魅族已经工作四年多了，一直专注于探索分布式系统和消息的高并发，能给我们分享下您的研究经验和心得么？文章源自运维生存时间-https://www.ttlsa.com/news/meizu-about-real-time-push/
于小波（A2）：我觉得并发和分布是两个不同的概念，并发反应的是量(请求量、用户量), 单台机器也可以有很高的并发量。但是单台机器的性能毕竟是有限的，同时存在单点问题，这种情况下我们引入多台机器来共同协作，提高性能的同时也解决了单点问题，这就是分布式。文章源自运维生存时间-https://www.ttlsa.com/news/meizu-about-real-time-push/
在高并发的分布式系统中，个人认为比较重要的几个点：文章源自运维生存时间-https://www.ttlsa.com/news/meizu-about-real-time-push/
1）大系统小做，把一个大的系统拆分成很多小的独立的服务，降低系统的复杂性文章源自运维生存时间-https://www.ttlsa.com/news/meizu-about-real-time-push/
2）需要一套成熟的通信框架，来提高开发效率。文章源自运维生存时间-https://www.ttlsa.com/news/meizu-about-real-time-push/
3）尽量避免使用多线程，最好是多进程、无锁设计。文章源自运维生存时间-https://www.ttlsa.com/news/meizu-about-real-time-push/
4） 做好过载保护、监控和灰度。（这个很重要）文章源自运维生存时间-https://www.ttlsa.com/news/meizu-about-real-time-push/
duke217（Q3）：近几年，魅族正处于移动互联网的转型期，这个过程中，有没有遇到令您印象深刻的技术难题？文章源自运维生存时间-https://www.ttlsa.com/news/meizu-about-real-time-push/
于小波（A3）：碰到的问题很多，有些是技术上的问题有些不是技术上的。比如说在开发语言的选择上纠结了挺久。最后我们选择了c++语言，基于以下原因：文章源自运维生存时间-https://www.ttlsa.com/news/meizu-about-real-time-push/
1） 性能。文章源自运维生存时间-https://www.ttlsa.com/news/meizu-about-real-time-push/
2） 人员招聘， c++是比较大众的语言，相对来说人员比较好招文章源自运维生存时间-https://www.ttlsa.com/news/meizu-about-real-time-push/
3） 内存可控，这是我们选择c++的一个很重要的原因，内存的使用尽量掌控在自己的手上。因为千万级的用户，如果出现一点内存不可控，最后累积下来是很可怕的。文章源自运维生存时间-https://www.ttlsa.com/news/meizu-about-real-time-push/
技术问题我这里就分享一个我印象比较深刻的。文章源自运维生存时间-https://www.ttlsa.com/news/meizu-about-real-time-push/
我们是长连接服务，手机端和服务端要维持这个长连接，需要定期的发送心跳消息，我们为了节约电量和流量，手机端采用的是智能心跳模式。那么对服务端来说，它是不知道手机端下次是几分钟之后会发送心跳上来的，那么这个连接在服务端的超时时间应该设置多久就是一个问题了。文章源自运维生存时间-https://www.ttlsa.com/news/meizu-about-real-time-push/
客户端在每一次的心跳消息中携带下一次的心跳时间。服务端就根据这个时间来设置连接的超时时间。文章源自运维生存时间-https://www.ttlsa.com/news/meizu-about-real-time-push/
duke217（Q4）：随着用户量从百万级快速增长到千万级，魅族的实时消息推送系统压力也肯定大增，那是用什么办法解决的呢？文章源自运维生存时间-https://www.ttlsa.com/news/meizu-about-real-time-push/
于小波（A4）：其 实魅族的推送系统并不是一开始就按照千万级的用户量来设计的，我们的架构也是根据实际情况一步一步演化来的。最初，我们做这个推送系统只是为了推送手机固 件升级。而且用户量也没有那么多，估计也就是几十万，我们使用很多开源的组件快速把系统搭建出来。这套系统可以满足我们的要求。文章源自运维生存时间-https://www.ttlsa.com/news/meizu-about-real-time-push/
随着魅族用户量的快速增长，我们的系统就暴露出了很多问题，只能一个一个坑去填。
1） 接入层性能问题
原 来的接入层单台服务器最多接入30W长连接，而且很多业务逻辑也放在了接入层处理，导致接入层性能低下，而且代码很臃肿，维护成本很高，特别是新员工进来 之后拿到这么一大堆代码，都不知道如何下手。所以我们对接入层做重构，把业务逻辑拆分出来，接入层只做简单的用户接入。所有的业务逻辑都在后端处理。也就 是现在比较流行的微服务的架构。
2） 带宽问题
最初我们的系统使用的是文本协议，每次做全网推送都占用了IDC大量的带宽，导致用户访问其他业务非常慢，我们就自定义了一套二进制协议，降低了50%-70%的带宽。
3） 服务化的基础组件
第 一点里面提到 我们的一些业务逻辑是和接入层搅在一起的，我们需要把业务逻辑拆分成单独的服务。服务之间的互相调用就需要一套成熟的网络通讯框架。我们就做了一套RPC 的框架，来提高开发的效率。最初这套框架用的多线程+同步调用，在实际的使用中发现，多线程有很多坑，各种锁，特别是新员工写代码一不小心就死锁了。而且 同步调用的性能并不理想，虽然开了多线程，但是线程又不能开的太多（大家都懂的）。针对以上情况，我们做了第二版的框架，使用了多进程+异步，服务的性能 提高了10倍，但是又面对另外一个问题，因为异步，就没有办法避免各种回调，本来很连续的一个业务逻辑流程被打散在了各种回调函数里面，看代码的人非常痛 苦，而且很容易产生内存泄露问题，比如：我申请的内存传递到回调函数中，结果忘记释放了（我们发现的内存泄露问题95%都是这样产生的）。
最后，我们参照go语言的特性使用协程来做了第三版的框架，业务开发人员再也不用考虑同步的性能和异步的回调问题。同步调用方式、异步的性能。
4） 存储
因为redis是有单点问题，我们开发了一套redis集群，一是提高redis的存储容量，二是解决单点的风险。
Mongodb的使用过程中我们也碰到了很多的坑，最主要就是集群的分片，这里我不详细讲了，主要列几个注意的地方：
根据业务形态选择合理的片键，尽量手动分片。
mongodb自带的balancer最好在业务低峰期做。
合适的索引。
duke217（Q5）：提到灰度发布，那我想跟您请教一下，灰度发布推送的消息，和其他APP推送的消息有何不同？（例如微信）
于小波（A5）：灰度发布的本质是没有区别的，都是一种平滑过渡的发布方式，只是实现方式不同而已吧。
和微信对比，我们的推送系统功能比较单一，只要做到让用户无感知的发布即可，另外重要的一点就是降低发布的风险。
duke217（Q6）：我们了解到，您主要从事服务端后台的开发工作，那有没有什么“过来人”的经验可以介绍给刚入行的朋友呢？
于小波（A6）：
1） 保持对技术的专注和热情
2） 多研究一些优秀的开源代码，比如nginx、redis等
3） 多逛一下技术论坛 比如chinaunix、csdn等
4） 多交流开阔视野 多参加一些技术沙龙的活动。
5） 最后还是自己多思考多实践，读万卷书不如行万里路。
duke217（Q7）：大家都知道，您本周四将在我们ChinaUnix的IT运维技术趋势群（微信）中进行直播活动，能稍稍给我们透露一下有哪些技术干货么？
于小波（A7）：其实我们用的一些技术点在前面都已经提到过了，如果大家对其中一个点或者几个点有兴趣的话可以一起深入探讨下。
评论