Herring Cove

移动端接入关键技术解析


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

背景

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

  • 互动

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

  • 媒体化

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

  • 实时性

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

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

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

通信方式细分

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

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

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

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

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

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

layer

关键技术

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

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）都是采用类似的实现方式，也从侧面进一步印证了该设计的合理性

application-architecture

总结

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


参考链接

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