【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/