云计算 频道

滴滴黄欣:长连接服务在滴滴的应用

  【IT168 现场直击】2016年10月27日-29日,2016中国系统架构师大会(SACC 2016)在北京万达索菲特大饭店举行。作为中国规模最大的架构师豪门盛会,本届大会以“架构创新之路”为主题,站在创新的风口上,与大家共同打造一场通过架构创新及各种IT新技术来带动企业转型增效,助力架构师们腾飞的技术盛会。

  在最后一天的分会场16中,滴滴出行数据库消息中间件负责人黄欣就《长连接服务在滴滴的应用》做了精彩分享,现场超级火爆,座无虚席,即使站着也要听完!

滴滴黄欣:长连接服务在滴滴的应用

  在移动场景下消息交互对于滴滴来说是一个绝对核心的需求,但是由于网络质量不好、用户使用习惯以及操作系统的限制问题,会给交互带来很多困难,比如说到达率会不稳定、单次在线时长不高、频繁上下线等问题,那么在交互场景下的解决方案是什么?滴滴又如何做的?黄欣告诉你。

  移动时代消息交互的挑战?怎么处理?

  黄欣表示通常的解决方法会有4种,包括自建通道(应用内)、第三方推送(应用外)、手机厂商推送平台(操作系统)以及通过短信(网络)。

  方法1,自建通道:由于是自研的,所以安全,可控,扩展性更好,支持双向可达。但是存在两个弊端,第一是实现起来比较复杂特别是长连接,而且成本比较高,小体量公司不建议使用,另一个是App一旦”死掉”就没办法进行交互了。

  方法2,第三方推送:调用起来比较简单好用(集成sdk),即使自己App死掉后,依然可以接受推送消息,并触发唤醒自己的App,但是使用会受限,由于数据都走第三方,所以也会存在安全隐患,另外只能推送,不能实时上行。

  方法3,手机厂商推送平台:好处就是调用简单,本平台推送到达率高,但是只适用于本手机,换个手机平台推送系统就无法使用了;只能下行不能上行,并且存在不安全因素。

  方法4,短信(网络):采用短信来讲相对比较稳定,但只适用于一些可读类的通知消息,并且费用比较高。

  总之,各有利弊,需要结合使用。那么滴滴是怎么应用这些方法解决问题的?

  黄欣告诉我们,滴滴就是把所有通道整合到一个大通道 ,给APP做了SDK,底层的网络层进行封装,后端服务做了统一的消息网关msggate的服务 ,屏蔽掉通道的差异,以统一的接口方式进行推送。

滴滴黄欣:长连接服务在滴滴的应用

  sdk主要用于和连接服务器进行交互,屏蔽框架层面交互细节,让用户只用关心用户态数据的收发,并提供良好的异常处理能力。SDK主要是为了完成2个任务,通讯层:建立维持与服务端长连接,包括认证登陆、心跳、数据收发。业务层:提供基于队列,带有保存功能的send、read API,支持注册timeout回调,并提供统一的error回调函数。

  统一后端的消息推送入口,msggate(golang):通过三个通道——应用内推送:长连接通道;应用外推送:第三方推送 + 手机厂商推送;以及通过短信推送。这个服务还支持多通道推送策略,可以同时推送或者降级推送,优先级如下:长连接通道、应用外推送、短信推送。

  通道:短信通道、第三方通道、自研通道(核心介绍自研长连接)

  自研长连接服务架构分享

  长连接—使用状况:每天服务于千万级别的司机,数亿的用户;实时在线量为百万级别;每天平均70亿次的推送量。

  长连接—开发语言(golang):开发效率高 ,是异步模型,提供同步原语,性能不能说特别卓越但是绝对够用 ,工具配套非常齐全,社区活跃发展也比较迅猛。

  长连接整体架构:据黄欣介绍,架构外层是分布式连接层,用来做连接的建立、认证、数据的收发等。右边层是路由,方便后续推送时进行查找,认证层用来存储用户的账号密码,上行走的是连接服务器到dispatch,下行走的是push。

滴滴黄欣:长连接服务在滴滴的应用

  架构—接口设计:原则是要有扩展性和稳定性,黄欣表示扩展性是对于业务而言的,稳定性是对于系统内部来讲的(最好不要升级),解决方法采用Protobuf,接口设计分为框架层(模块间通信协议,类似tcp/udp)和业务层(bytes类似应用层)。

  架构—集群扩展: 这套系统大部分模块都是Proxy,proxy本身无状态,可以处于无限扩展;另外一个依赖的存储也要做到无限扩容,采用redis集群(codis集群方案)和mysql集群(中间件方案)。

  架构—灾备:这里的灾备主要指的是依赖的存储降级方案,涉及到存储的主要是两个模块。

  Auth svr:cache(redis) + db(mysql)

  Route svr:cache + cache(standy)

滴滴黄欣:长连接服务在滴滴的应用

  对于认证服务器来说,数据量很大,所以底层要有DB,为了提高读取速度,上面加了Cache,这是一个比较通用的方案,另外一层是路由层,路由信息变化快,总量不会太大,擦写的频率特别高,做的是Standy by的模式。

  架构—异地双活:要求在正常情况下任何一个机房可推送到所有机房app,在异常情况下本机房内推送亦可送达。

  “简单总结就是要有异步通信接口、协议包业务态隔离,所有模块尽量简单无状态,有状态的服务(涉及到存储)做到可降级,要有预案备案,核心业务据有自愈逻辑,一句话概括就是:整个架构要崇尚简单实用的原则,避免过度设计黄欣最后说道。

滴滴黄欣:长连接服务在滴滴的应用

  ▲更多信息尽在IT168现场报道专题

  http://www.it168.com/redian/sacc2016/


2
相关文章