背景
随着移动互联网成长成熟，移动端逐渐涌现出与WEB不一样的产品形态。
- 互动
越来越多的互动形式的出现，各种产品向社交化、娱乐化不断迈进
- 媒体化
从文字+图片为主的生态，逐渐向以视频为主的内容生态进化
- 实时性
内容生产逐渐由推荐式替代陈列式的形态；内容促达充分利用移动特性，实时触达用户，抢占用户的碎片时间
以上变化也推动了移动端接入技术演化发展，不再局限于常见的“请求-响应”的通信模式。
如果把移动端接入服务分为两层：流量接入层和应用接入层，本篇文章更多侧重于应用接入层，对于流量接入层如何实现，已经在《高可用的接入层架构细节实现》覆盖。
通信方式细分
如果WEB时代接入层支持单工即可，客户端主动获取（PULL）数据；那么移动时代接入层需要支持双工，服务端也可以主动推送（PUSH）数据给客户端。如果客户端也像服务端一样可以24小时在线，那么只需要支持如此两种形式的通信方式即可，然而现实情况更为复杂。
- 频繁打开关闭，如何进行离线数据同步
- 数据同步面临 网络状况复杂、同步速度、客户端耗电量等要求
- 多终端离线数据同步，如何做到数据不遗漏、不重复
基于以上几点，可以降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的弹幕服务” ，还是“单用户千万粉丝的红点服务”，在整体上都脱不开这个模型。只是要根据业务特性，在实现上做一定的修改变化以适应业务的需要
参考链接
- 蚂蚁金服亿级并发下的移动端到端网络接入架构解析
- 知乎千万级高性能长连接网关揭秘
- 微信协议简单调研笔记
- 阿里无线 11.11：手机淘宝移动端接入网关基础架构演进之路
- 移动时代——QQ后台架构的演化与启示
- 美团点评移动网络优化实践
- 魅族实时消息推送架构
- 360 如何实现支持数亿用户的长连消息系统
- 消息推送架构-BASED-GOIM
- goim 中的 data flow 数据流转及思考
- 移动IM开发指南2：心跳指令详解
- Android端消息推送总结：实现原理、心跳保活、遇到的问题等
- Android 架构之长连接技术
- TCP 进阶
本文作者 ： cyningsun
本文地址 ： https://www.cyningsun.com/05-03-2020/mobile-application-access-tech.html
版权声明 ：本博客所有文章除特别声明外，均采用 CC BY-NC-ND 3.0 CN 许可协议。转载请注明出处！
