以写作调身心

文字直播:消息推送系统介绍

介绍

直播内容:主要讨论周洋在360做的消息推送系统,主要分为以下几个部分:

  • 关于push系统对比与性能指标的讨论~
  • 消息系统架构介绍
  • 哪些因素决定了推送系统的效果?
  • go语言开发问题与解决方案
  • 消息系统的运维,测试

直播开始

360消息系统更确切的说是长连接push系统,目前服务于360内部50多个产品,开发平台数千款app,也支持部分聊天业务场景,单通道多app复用,支持上行数据,提供接入方不同粒度的上行数据和用户状态回调服务。
目前整个系统按不同业务分成9个功能完整的集群,部署在10个idc上(每个集群覆盖不同的idc),实时在线2亿量级.
通常情况下,pc,手机,甚至是智能硬件上的360产品的push消息,基本上是从我们系统发出的,期望大家收到的push都是自己关心的... 如果不是,请相信,“我们不生产消息,我们只是消息的搬运工”~
很多同行比较关心go语言在实现push系统上的性能问题,单机性能究竟如何,能否和其他语言实现的类似系统做对比么?甚至问如果是创业,第三方云推送平台,推荐哪个?
其实各大厂都有类似的push系统,市场上也有类似功能的云服务。包括我们公司早期也有erlang,nodejs实现的类似系统,也一度被公司要求做类似的对比测试。
我感觉在讨论对比数据的时候,很难保证大家环境和需求的统一,我只能说下我这里的体会,数据是有的,但这个数据前面估计会有很多定语~

一些重要指标

1,单机的连接数指标。

做过长连接的同行,应该有体会,如果在稳定连接情况下,连接数这个指标,在没有网络吞吐情况下对比,其实意义往往不大,维持连接消耗cpu资源很小,每条连接tcp协议栈会占约4k的内存开销,系统参数调整后,我们单机测试数据,最高也是可以达到单实例300w长连接。
但做更高的测试,我个人感觉意义不大。因为实际网络环境下,单实例300w长连接,从理论上算压力就很大:因为实际弱网络环境下,移动客户端的断线率很高,假设每秒有1000分之一的用户断线重连。300w长连接,每秒新建连接达到3w,这同时连入的3w用户,要进行注册,加载离线存储等对内rpc调用,另外300w长连接的用户心跳需要维持,假设心跳300s一次,心跳包每秒需要1w tps。
单播和多播数据的转发,广播数据的转发,本身也要响应内部的rpc调用,300w长连接情况下,gc带来的压力,内部接口的响应延迟能否稳定保障。
这些集中在一个实例中,可用性是一个挑战。所以线上单实例不会hold很高的长连接,实际情况也要根据接入客户端网络状况来决定。

2,消息系统的内存使用量指标

这一点上,使用go语言情况下,由于协程的原因,会有一部分额外开销。但是要做两个推送系统的对比,也有些需要确定问题。
比如系统从设计上是否需要全双工(即读写是否需要同时进行)如果半双工,理论上对一个用户的连接只需要使用一个协程即可(这种情况下,对用户的断线检测可能会有延时),如果是全双工,那读/写各一个协程。两种场景内存开销是有区别的.

另外测试数据的大小往往决定我们对连接上设置的读写buffer是多大,是全局复用的,还是每个连接上独享的,还是动态申请的。另外是否全双工也决定buffer怎么开. 不同的策略,可能在不同情况的测试中表现不一样。

3,每秒消息下发量

这一点上,也要看我们对消息到达的QoS级别(回复ack策略区别),另外架构策略,每种策略有其更适用的场景,是纯粹推,还是推拉结合。甚至是否开启了消息日志,日志库的实现机制,缓冲开多大,flush策略,这些都影响整个系统的吞吐量。另外为了HA,增加了内部通信成本,为了避免一些小概率事件,提供闪断补偿策略,这些都要考虑进去。如果所有的都去掉,那就是比较基础库的性能了.

所以我只能给出大概数据,24核,64G的服务器上,在Qos为message at least,纯粹推的情况,消息体256B~1kB情况下,单个实例100w实际用户(200w+)协程,峰值可以达到2~5w的QPS...
内存可以稳定在25G左右,gc时间在200~800ms左右.(还有优化空间) 我们正常线上单实例用户控制在80w以内,单机最多两个实例~
事实上,整个系统在推送的需求上,对高峰的输出不是提速,往往是进行限速,以防push系统瞬时的高吞吐量,转化成对接入方业务服务器的ddos攻击
所以对于性能上,我感觉大家可以放心使用,至少在我们这个量级上,经受过考验,go1.5到来后,确实有之前投资又增值了的感觉~
下面是对消息系统的大概介绍,之前一些同学可能在gopher china上可以看到分享,这里简单讲解下架构和各个组件功能,额外补充一些当时遗漏的信息:
架构图如下,所有的service都 written by golang.
0b8323ed2b40742005a9a6b2010f85b

几个大概重要组件介绍如下

dispatcher service

根据客户端请求信息,将应网络和区域的长连接服务器的,一组IP传送给客户端。客户端根据返回的IP,建立长连接,连接Room service.

room Service

长连接网关,hold用户连接,并将用户注册进register service,本身也做一些接入安全策略、白名单、IP限制等

coordinator service

用来转发用户的上行数据,包括接入方订阅的用户状态信息的回调,另外做需要协调各个组件的异步操作,比如kick用户操作,需要从register拿出其他用户做异步操作.

saver service

是存储访问层,承担了对redis和mysql的操作,另外也提供部分业务逻辑相关的内存缓存,比如广播信息的加载可以在saver中进行缓存。另外一些策略,比如客户端sdk由于被恶意或者意外修改,每次加载了消息,不回复ack,那服务端就不会删除消息,消息就会被反复加载,形成死循环,可以通过在saver中做策略和判断。(客户端总是不可信的)

center service

提供给接入方的内部api服务器,比如单播或者广播接口,状态查询接口等一系列api,包括运维和管理的api.

举两个常见例子,了解工作机制:

比如发一条单播给一个用户,center先请求Register获取这个用户之前注册的连接通道标识、room实例地址,通过room service下发给长连接。
Center Service比较重的工作如全网广播,需要把所有的任务分解成一系列的子任务,分发给所有center,然后在所有的子任务里,分别获取在线和离线的所有用户,再批量推到Room Service。通常整个集群在那一瞬间压力很大。
deployd/agent service 用于部署管理各个进程,收集各组件的状态和信息,zookeeper和keeper用于整个系统的配置文件管理和简单调度

关于推送的服务端架构

常见的推送模型有长轮训拉取,服务端直接推送(360消息系统目前主要是这种),推拉结合(推送只发通知,推送后根据通知去拉取消息).
拉取的方式不说了,现在并不常用了,早期很多是nginx+lua+redis,长轮训,主要问题是开销比较大,时效性也不好, 能做的优化策略不多。
直接推送的系统,目前就是360消息系统这种,消息类型是消耗型的,并且对于同一个用户并不允许重复消耗,如果需要多终端重复消耗,需要抽象成不同用户。
推的好处是实时性好,开销小,直接将消息下发给客户端,不需要客户端走从接入层到存储层主动拉取.
但纯推送模型,有个很大问题,由于系统是异步的,他的时序性无法精确保证。这对于push需求来说是够用的,但如果复用推送系统做im类型通信,可能并不合适。

这里还有一个常见话题,哪些因素决定推送系统的效果?

首先是sdk的完善程度

sdk策略和细节完善度,往往决定了弱网络环境下最终推送质量.

1.SDK选路策略,最基本的一些策略如下:
有些开源服务可能会针对用户hash一个该接入区域的固定ip,实际上在国内环境下不可行,最好分配器(dispatcher)是返回散列的一组,而且端口也要参开,必要时候,客户端告知是retry多组都连不上,返回不同idc的服务器。因为我们会经常检测到一些case,同一地区的不同用户,可能对同一idc内的不同ip连通性都不一样,也出现过同一ip不同端口连通性不同,所以用户的选路策略一定要灵活,策略要足够完善.
另外在选路过程中,客户端要对不同网络情况下的长连接ip做缓存,当网络环境切换时候(wifi 2G,3G),重新请求分配器,缓存不同网络环境的长连接ip.

2.客户端对于数据心跳和读写超时设置,完善断线检测重连机制
针对不同网络环境,或者客户端本身消息的活跃程度,心跳要自适应的进行调整并与服务端协商,来保证链路的连通性。并且在弱网络环境下,除了网络切换(wifi切3G)或者读写出错情况,什么时候重新建立链路也是一个问题。客户端发出的ping包,不同网络下,多久没有得到响应,认为网络出现问题,重新建立链路需要有个权衡。另外对于不同网络环境下,读取不同的消息长度,也要有不同的容忍时间,不能一刀切。好的心跳和读写超时设置,可以让客户端最快的检测到网络问题,重新建立链路,同时在网络抖动情况下也能完成大数据传输。

3.结合服务端做策略
另外系统可能结合服务端做一些特殊的策略,比如我们在选路时候,我们会将同一个用户尽量映射到同一个room service实例上。断线时,客户端尽量对上次连接成功的地址进行重试。主要是方便服务端做闪断情况下策略,会暂存用户闪断时实例上的信息,重新连入的时候,做单实例内的迁移,减少延时与加载开销.

4.客户端保活策略
很多创业公司愿意重新搭建一套push系统,确实不难实现,其实在协议完备情况下(最简单就是客户端不回ack不清数据),服务端会保证消息是不丢的。但问题是为什么在消息有效期内,到达率上不去?
往往因为自己app的push service存活能力不高。选用云平台或者大厂的,往往sdk会做一些保活策略,比如和其他app共生,互相唤醒,这也是云平台的push service更有保障原因~ 我相信很多云平台旗下的sdk,多个使用同样sdk的app,为了实现服务存活,是可以互相唤醒和保证活跃的~ 另外现在push sdk本身是单连接,多app复用的,这为sdk实现,增加了新的挑战~

综上,对我来说,选择推送平台,优先会考虑客户端sdk的完善程度~ 对于服务端,选择条件稍微简单,要求部署接入点(IDC)越要多,配合精细的选路策略,效果越有保证,至于想知道哪些云服务有多少点,这个群里来自各地的小伙伴们,可以合伙测测~

这个系统在开发过程中遇到挑战和优化策略,给大家看下当年的一张图,在第一版优化方案上线前一天截图~

可以看到,内存最高占用69G,GC时间单实例最高时候高达3~6s.这种情况下,试想一次悲剧的请求,经过了几个正在执行gc的组件,后果必然是超时... gc照成的接入方重试,又加重了系统的负担。遇到这种情况当时整个系统最差情况每隔2,3天就需要重启一次~

2b01512149c092fa9edf1e4023d7ed0

当时出现问题,现在总结起来,大概以下几点

1.散落在协程里的I/O,Buffer和对象不复用。
当时由于对go的gc效率理解有限,比较奔放,程序里大量short live的协程,对内通信的很多io操作,由于不想阻塞主循环逻辑或者需要及时响应的逻辑,通过单独go协程来实现异步。这回会gc带来很多负担。

针对这个问题,应尽量控制协程创建,对于长连接这种应用,本身已经有几百万并发协程情况下,很多情况没必要在各个并发协程内部做异步io,因为程序的并行度是有限,理论上做协程内做阻塞操作是没问题。
如果有些需要异步执行,比如如果不异步执行,影响对用户心跳或者等待response无法响应,最好通过一个任务池,和一组常驻协程,来消耗,处理结果,通过channel再传回调用方. 使用任务池还有额外的好处,可以对请求进行打包处理,提高吞吐量,并且可以加入控量策略.

2.网络环境不好引起激增
go协程相比较以往高并发程序,如果做不好流控,会引起协程数量激增。早期的时候也会发现,时不时有部分主机内存会远远大于其他服务器,但发现时候,所有主要profiling参数都正常了。
后来发现,通信较多系统中,网络抖动阻塞是不可免的(即使是内网),对外不停accept接受新请求,但执行过程中,由于对内通信阻塞,大量协程被创建,业务协程等待通信结果没有释放,往往瞬时会迎来协程暴涨. 但这些内存在系统稳定后,virt和res都并没能彻底释放,下降后,维持高位。
处理这种情况,需要增加一些流控策略,流控策略可以选择在rpc库来做,或者上面说的任务池来做,其实我感觉放在任务池里做更合理些,毕竟rpc通信库可以做读写数据的限流,但它并不清楚具体的限流策略,到底是重试还是日志还是缓存到指定队列。任务池本身就是业务逻辑相关的,它清楚针对不同的接口需要的流控限制策略。

3.低效和开销大的rpc框架
早期rpc通信框架比较简单,对内通信时候使用的也是短连接。这本来短连接开销和性能瓶颈超出我们预期,短连接io效率是低一些,但端口资源够,本身吞吐可以满足需要,用是没问题的,很多分层的系统,也有http短连接对内进行请求的。但早期go版本,这样写程序,在一定量级情况,是支撑不住的。短连接大量临时对象和临时buffer创建,在本已经百万协程的程序中,是无法承受的。所以后续我们对我们的rpc框架作了两次调整。

第二版的rpc框架,使用了连接池,通过长连接对内进行通信(复用的资源包括client和server的:编解码Buffer、Request/response),大大改善了性能。

但这种在一次request和response还是占用连接的,如果网络状况ok情况下,这不是问题,足够满足需要了,但试想一个room实例要与后面的数百个的register,coordinator,saver,center,keeper实例进行通信,需要建立大量的常驻连接,每个目标机几十个连接,也有数千个连接被占用。

非持续抖动时候(持续逗开多少无解),或者有延迟较高的请求时候,如果针对目标ip连接开少了,会有瞬时大量请求阻塞,连接无法得到充分利用。第三版增加了Pipeline操作,Pipeline会带来一些额外的开销,利用tcp的全双特性,以尽量少的连接完成对各个服务集群的rpc调用。

4.GC时间过长
Go的Gc仍旧在持续改善中,大量对象和buffer创建,仍旧会给gc带来很大负担,尤其一个占用了25G左右的程序。之前go team的大咖邮件也告知我们,未来会让使用协程的成本更低,理论上不需要在应用层做更多的策略来缓解gc. (目前最新版本,Go 的 GC 已经有了很大的改进)

改善方式,一种是多实例的拆分,如果公司没有端口限制,可以很快部署大量实例,减少gc时长,最直接方法。不过对于360来说,外网通常只能使用80和433。因此常规上只能开启两个实例。当然很多人给我建议能否使用SO_REUSEPORT,不过我们内核版本确实比较低,并没有实践过。另外能否模仿nginx,fork多个进程监控同样端口,至少我们目前没有这样做,主要对于我们目前进程管理上,还是独立的运行的,对外监听不同端口程序,还有配套的内部通信和管理端口,实例管理和升级上要做调整。

解决gc的另两个手段,是内存池和对象池,不过最好做仔细评估和测试,内存池、对象池使用,也需要对于代码可读性与整体效率进行权衡。
这种程序一定情况下会降低并行度,因为用池内资源一定要加互斥锁或者原子操作做CAS,通常原子操作实测要更快一些。CAS可以理解为可操作的更细行为粒度的锁(可以做更多CAS策略,放弃运行,防止忙等)。这种方式带来的问题是,程序的可读性会越来越像C语言,每次要malloc,各地方用完后要free,对于对象池free之前要reset,我曾经在应用层尝试做了一个分层次结构的“无锁队列”

上图左边的数组实际上是一个列表,这个列表按大小将内存分块,然后使用atomic操作进行CAS。但实际要看测试数据了,池技术可以明显减少临时对象和内存的申请和释放,gc时间会减少,但加锁带来的并行度的降低,是否能给一段时间内的整体吞吐量带来提升,要做测试和权衡…

d5fb44dcbb01cb30d4820ece2db74fb

在我们消息系统,实际上后续去除了部分这种黑科技,试想在百万个协程里面做自旋操作申请复用的buffer和对象,开销会很大,尤其在协程对线程多对多模型情况下,更依赖于golang本身调度策略,除非我对池增加更多的策略处理,减少忙等,感觉是在把runtime做的事情,在应用层非常不优雅的实现。普遍使用开销理论就大于收益。
但对于rpc库或者codec库,任务池内部,这些开定量协程,集中处理数据的区域,可以尝试改造~
对于有些固定对象复用,比如固定的心跳包什么的,可以考虑使用全局一些对象,进行复用,针对应用层数据,具体设计对象池,在部分环节去复用,可能比这种无差别的设计一个通用池更能进行效果评估.

架构迭代和迭代经验

下面介绍消息系统的架构迭代和一些迭代经验,由于之前在其他地方有过分享,后面的会给出相关链接,下面实际做个简单介绍,感兴趣可以去链接里面看

架构迭代

根据业务和集群的拆分,能解决部分灰度部署上线测试,减少点对点通信和广播通信不同产品的相互影响,针对特定的功能做独立的优化.
消息系统架构和集群拆分,最基本的是拆分多实例,其次是按照业务类型对资源占用情况分类,按用户接入网络和对idc布点要求分类(目前没有条件,所有的产品都部署到全部idc)

3bd38ef89d953b4a38ee82d3883845a

简要介绍下我们的运维系统

我们利用Go原生的profiling工具,做了些可视化工作。可以对比多次上线出现的问题,通过压测程序复现部分瓶颈。定位cpu或者内存消耗的瓶颈。

9d20e7fc447c0934ede155cd7a1ca5f

d582183dc3ccbbc15ae6203fcb08762

另外,我们也可以对基础库代码做内嵌,将RPC库,Redis库,内存池命中数据等,做可视化的展示,统计它的QPS、网络带宽占用、idle与working,各种出错情况。然后再通过各种压测手段,观察优化性能点,上线前后是否有影响。如果一个系统不可评估就无法优化,利用压测评估就会发现一些潜在的问题。

fd90a02582647647c1631b71a570164

系统的测试

go语言在并发测试上有独特优势。
在功能测试上,系统分成两套,一套是我们针对自己的功能,自己设计并测试,但这样难免会有问题。另一套是公司的自动化测试部门(python实现的~)根据我们的功能来测试。双保险~
c1e3523ce678de3c2a5e0d763b6927a

对于压力测试,目前主要针对指定的服务器,选定线上空闲的服务器做长连接压测。然后结合可视化,分析压测过程中的系统状态。但压测早期用的比较多,但实现的统计报表功能和我理想有一定差距。理论上压测完后,可以根据协议版本,汇总每一次压测进程详细数据,业务的QPS数量、每秒钟建立连接数量,极限状态下的cpu和内存消耗,等每一个考核细节。现在只是能看一个大概趋势.对于细微的性能提升,没法评估,我们后续准备结合自己写的中央管理组件keeper,做这个数据收集和展示~

对于go语言适用的场景。之前在gopher china上,有过我个人的理解和概括:适用于重逻辑的io密集型应用.

我觉得最近出的golang开源产品都符合这种场景, go写网络并发程序给大家带来的便利,让大家把以往为了降低复杂度,拆解或者分层协作的组件,又组合在了一起。

比如go的web框架是在做负责并发的webserver和负责业务处理cgi程序,放在了webserver中。新近的一些go写的“智能”代理或者中间件,把很多原先分层控制或者不同功能但类似的子系统,以各种形式组装起来,reborn一个新的中间件或者新产品~包括之前百度放出的go-bfe也是把重逻辑和io密集型很好结合的产物~(群里有bfe的同学么,求更多资料)

个人感觉在国内互联网创业公司爆发环境下,大厂的复杂设备,很多将被golang重新打包成适用在一定量级下的“全能”工具箱~
以上就是今天的go分享~ 谢谢大家,欢迎提问~

相关文章

架构设计和概要( 1小时的分享 文字总结)
http://blog.qiniu.com/archives/3720
关于基础库实现和性能参数对比表格:
http://blog.golang.org/qihoo

提问环节

提问:对比kafaka这些消息系统 有什么优点?
回答:我们是消息推送系统 指的对客户端的高并发推送的 面对场景不一样

提问:hadoop生态圈的大数据,算重逻辑和IO密集型应用不?
回答:不算 Hadoop主要是计算

提问:这种推送的方式如何保证消息是有序到达的?
回答:如果要保证有序 需要重新设计协议 对消息编号 先存储 后拉取 可以按人存储也可以按订阅关系 目前花椒的im系统 属于这种场景 有机会大家感兴趣可以分享升级版本聊天架构

提问:golang适不适合写web应用
回答:这个可以单独一讲回答 我的建议新的应用 大并发的场景可以考虑 老项目酌情改写替换

提问:推送的消息会有多级转发吗?还是说客户端直接跟一个server保持长链接就完事了?
回答:当流量大到一定程度 可以多级转发 类似cdn架构 目前花椒直播的推送系统支持这种场景 为idc流量做分级转发 普通场景不需要

提问:极光推送跟这种推送的应用场景就是差不多吧?
回答:方案都类似 协议复杂度会不同 比如为了保证一致性采取编号 先存储后发送

提问:多级之间也是长链接吧
回答:多级别只是rpc调用 rpc通常keepalive

提问:推送系统目前支持什么协议呢? mqtt?web socket?
回答:分传输层和协议层 传输层web socket 没问题 mqtt是一个具体交互协议了 不具备通用可比性

提问:推送系统里面有用到epoll吗?有没有开源地址?
回答:用的golang; go原生就是对epoll封装…目前不开源 安全公司理解下

评论