移动端接入关键技术解析


  1. 背景
  2. 通信方式细分
  3. 关键技术
    1. SYNC 机制
    2. 长连接
    3. 心跳
  4. 应用层架构
  5. 总结

背景

随着移动互联网成长成熟,移动端逐渐涌现出与WEB不一样的产品形态。

  • 互动

    越来越多的互动形式的出现,各种产品向社交化、娱乐化不断迈进

  • 媒体化

    从文字+图片为主的生态,逐渐向以视频为主的内容生态进化

  • 实时性

    内容生产逐渐由推荐式替代陈列式的形态;内容促达充分利用移动特性,实时触达用户,抢占用户的碎片时间

以上变化也推动了移动端接入技术演化发展,不再局限于常见的“请求-响应”的通信模式。

如果把移动端接入服务分为两层:流量接入层和应用接入层,本篇文章更多侧重于应用接入层,对于流量接入层如何实现,已经在《高可用的接入层架构细节实现》覆盖。

通信方式细分

如果WEB时代接入层支持单工即可,客户端主动获取(PULL)数据;那么移动时代接入层需要支持双工,服务端也可以主动推送(PUSH)数据给客户端。如果客户端也像服务端一样可以24小时在线,那么只需要支持如此两种形式的通信方式即可,然而现实情况更为复杂。

  1. 频繁打开关闭,如何进行离线数据同步

  2. 数据同步面临 网络状况复杂、同步速度、客户端耗电量等要求

  3. 多终端离线数据同步,如何做到数据不遗漏、不重复

基于以上几点,可以降PUSH模式进行细分,拆解成两种模式:推送数据 + 数据同步(SYNC)。总结一下,在应用接入层需要支持以下三种形式的通信模式:

  • RPC 负责“客户端向服务端请求数据(请求 - 响应)”的通信模式;
  • SYNC 负责“客户端从服务端同步数据”的通信模式;
  • PUSH 负责“服务端向在线客户端 PUSH 数据”的通信模式。

关键技术

以下的部分重点讲述实现以上通信方式所需要的关键技术

SYNC 机制

本质上 SYNC 是基于 SyncKey 的一种同步协议。微信在聊天界面拉取所有的未读消息,很卡很耗费流量。SYNC 机制是同步差量数据,以达到了提高通信效率、节省流量的效果。

在消息投递时选择合适的 ID生成方案,为消息绑定递增的序号。推送消息时,不是把消息直接推送下去,而是发一个通知到客户端,客户端收到通知,根据用户上翻或者下翻的行为,带上一个最近收到消息的最大的序列号,按需、分页拉取消息。此机制保障了消息不重不漏,并且可以有效支持多终端数据同步。

客户端无需实时在线,对于用户不在线的情况,SYNC Server 会将差量数据保存在数据库中。当客户端下次连接到服务器时,再同步差量数据给用户。

长连接

服务端要做到主动把消息推送给客户端,就需要长连接的支持。那么长连接是不是就是 HTTP Keep Alive 呢?

HTTP Keep Alive 又被称为持久连接,允许 HTTP 请求结束之后将 TCP 连接保持在打开状态,以便为未来的 HTTP 请求重用现存的连接。持久连接侧重于 HTTP 应用层。

所以常说的长连接是指 TCP 长连接。在移动网络下,网络状态复杂多变,长连接会因为以下因素断开:

  • 长连接进程退出

    客户端被系统 Kill 掉

  • 用户切换网络

    手机网络断开、Wi-Fi和蜂窝数据切换

  • NAT超时

    设备休眠,NAT超时,导致公网IP回收

  • DHCP 过期

    DHCP 租期过期,如果没有及时续约,同样会导致IP地址失效

如果发生长连接断开,那么就需要尽快发现并重连,此时就需要引入心跳机制.

心跳

在应用层做心跳检测连接断开,不熟悉的人不太能理解这一点。为什么使用应用层心跳,TCP 不是有 KeepAlive 机制么,通过这个机制来实现不就可以了吗?

keepalive_probes  探测次数(9次)
keepalive_time    探测的超时(2小时)
keepalive_intvl   探测间隔(75s)

事实上,TCP KeepAlive 的机制其实并不适用于此。Keep Alive 机制开启后,,如果2小时内在此套接口的任一方向都没有数据交换,TCP就自动给对方发一个保持存活探测分节(keepalive probe),会导致一下三种情况

  • 对方接收一切正常:以期望的ACK响应。2小时后,TCP将发出另一个探测分节
  • 对方已崩溃且已重新启动:以RST响应。套接口的待处理错误被置为ECONNRESET,套接 口本身则被关闭。
  • 对方无任何响应:TCP发送另外8个探测分节,相隔75秒一个,试图得到一个响应。一共尝试9次,即在发出第一个探测分节11分钟 15秒后若仍无响应就放弃。

显然默认值无法满足我们的需求,而修改过设置后就可以满足了吗?答案仍旧是否定的。因为 TCP KeepAlive 是用于检测连接的死活,而心跳机制则附带一个额外的功能:检测通讯双方的存活状态。两者听起来似乎是一个意思,但实际上并非如此。例如,某台服务器无法响应任何业务请求,使用 TCP 探针则仍旧能够确定连接状态。对客户端而言,此时的最好选择就是断线后重新连接其他服务器,而不是持续向当前服务器发送请求。

应用层架构

理清楚以上关键点,再去设计架构,就比较清晰容易了。因为几大国民应用(淘宝、支付宝、微信、QQ)都是采用类似的实现方式,也从侧面进一步印证了该设计的合理性

总结

其实无论是 “单直播间百万CCU的弹幕服务” ,还是“单用户千万粉丝的红点服务”,在整体上都脱不开这个模型。只是要根据业务特性,在实现上做一定的修改变化以适应业务的需要


参考链接

本文作者:cyningsun
本文地址https://www.cyningsun.com/05-03-2020/mobile-application-access-tech.html
版权声明:本博客所有文章除特别声明外,均采用 CC BY-NC-ND 3.0 CN 许可协议。转载请注明出处!