淘宝技术分享：手淘亿级移动端接入层网关的技术演进之路

JackJiang · 3 年前

本文由手机淘宝技术团队原创分享，吴志华（天施）、洪海（孤星）、陈虓将（仲升）等专家参与了本文创作，首次发表于公众号“淘系技术”，收录整理时有修订和改动。

1、引言

移动端网络的优化是超级APP们永恒的话题，而对于无线电商来说这更为重要，因为网络请求体验跟用户的购买行为息息相关。

手机淘宝从过去的HTTP API网关，到后来扛住双十一战场主要流量的自研高性能、全双工、安全的ACCS（阿里云通道服务），无论是基础架构的演进、网络调优、协议的优化、异地多活、网络调度上，都有不少宝贵的经验与大家分享，本文借此机会总结了整个技术演进过程。

* 阅读对象：本文属于移动端网络优化的深水区总结性文章，适合有一定移动端网络应用经验的开发者阅读（尤其对移动弱网有一定了解的），初学者如果没有相关知识积累的话，可以简单了解无需深入。如果你对移动弱网很有兴趣，可以进一步阅读本文末尾“附录”部分的推荐文章。

本文已同步发布于“即时通讯技术圈”公众号，欢迎关注：
52im_qr_即时通讯技术圈_400px.png

▲ 本文在公众号上的链接是：点此进入

2、专题目录

本文是系列文章的第3篇，总目录如下：

其它相关技术文章：

《手机淘宝消息推送系统的架构与实践(音频+PPT) [附件下载]》

3、技术背景

回想移动电商在双十一业务开始兴起的时候，当时双十一当天移动成交243亿占整体571亿的42.6%。

业务高速发展希望更多主动推送去触达用户，一些新的玩法和互动形式，需要连接买家与买家、买家与卖家、买家与达人，因为没有有效的通道能力，业务采取的是不停去轮询服务器，一来对服务器造成不必要的压力，二来对于用户手机的电量流量也是极大的浪费，关键在双十五这种大促的情况下，不必要的请求过大甚至会导致后端集群限流，从而影响到用户体验。

信息传播形态的变化的背后是移动化带来新的技术特征导致的结果。移动电商领域，手机淘宝一直是先行者。移动电商从最初的复制WEB的业务形态到移动特性不断涌现，更多的互动形式的出现，向社交化、娱乐化不断迈进的今天，一个单纯的商品的陈列架形式已经不能满足业务的需求。

业务上需要实时的触达用户，充分发挥移动的特性，将消费时间的碎片利用起来，事实也证明了用户的消费时间随着移动化的进程不断发生变化，逐步分布到全天的碎片时间中。同时货架形态也在向社区化、娱乐化的方向发展，这些都对网络层连接用户有了更高的要求。更多的媒体形态和展示方式，对网络层提出了更多元的要求。

大家可以关注到手机淘宝内的消息盒子这些产品都是业务求变的体现，业务的变化倒逼技术的前进。

4、移动网络环境的挑战性一直都存在

移动网络的速度随便3g、4g、5g的普及，速度有很大提升，但网络环境的多样性和差异性使移动网络的环境更加复杂，在过去双十一前还常遇到一些移动网络劫持的事情。网络劫持这块问题的排查效率很低，需要找到用户、复现现场，甚至找网工、运营商配合排查，一查就是几天过去。

同时在我们的舆情反馈上总是看到用户在说“某个页面加载中、页面打不开、请求很慢、打开某个功能很慢”，面对这些问题过去我们是没有太好的办法，只能猫抓耗子一桩桩去排雷很被动。很多网络的问题是偶现的，一旦错过现在就无从查起。

诸如此类的问题，背后的原因很多：

1）运营商问题；
2）机房部署原因；
3）客户端SDK Bug；
4）弱网和网络抖动；
5）DNS劫持和数据篡改。

在PC时代，我们访问网站的接入条件是相对恒定的，所以在开发时很少考虑网络对用户体验的影响。但是移动APP则不然，尤其是在国内，基础的移动网络环境还不算太好，而且我们有很多用户的访问是发生在地铁、公交车这样的移动环境下，移动基站的频繁切换进一步增加了网络的不稳定。从手机淘宝的数据可以看出，我们每天活跃用户中有不少来自于弱网环境。如果端到云的连接不稳定、高延时，那么所有的用户体验都无从谈起。

基础网络的效率就像一辆列车，时延是火车的速度(启动时间)，而带宽就像火车的车厢装载量，整个传输的物理链路就像火车的铁轨。目前现实条件下的移动网络条件非常复杂，我们的目标很简单，就是想让所有用户都能在手机淘宝获得流畅的体验。

下面这张图，能够让大家更加直观的了解国内的移动网络环境。描述了从用户到IDC的端到端的路由情况，不仅数据传输耗时长且丢包率高，同时安全性也是相当糟糕的，DNS劫持、内容劫持在中国就是家常便饭。

因此，我们在改善网络通道上有很多的事情可以去做，去探索突破运营商基础网络的限制，力争为用户创造极致的购物体验。

移动端的DNS问题相当普遍，可以详读以下专题文章：

5、整体技术架构

为了满足移动电商业务高速发展的需求，我们决定打造一个世界级的网络接入服务，构建一个无线网络下”水、电、煤“ 一样的基础设施。

这样一个基础设施需要做到的四个目标：

1）全双工；
2）低延时；
3）高安全；
4）开放。

在这四个目标之上是围绕这个接入服务配套的运维体系，帮助最终用户取得良好的端上体验的同时，帮助开发者快速构建自己的业务。

如上图所示，在整个接入服务上我们划分为两层：

1）接入网关：负责连接的保持、消息的解析、消息的分发；
2）应用网关：实现各种应用层协议：API、SYNC、RPC、PUSH等，在应用网关的背后是具体的业务系统。

同时我们建立了一个统一调度服务，而不是采用传统的DNS，调度服务是我们的控制中心，通过它我们可以强有力的指挥我们的客户端，并且不会受到DNS污染的影响。

与服务端的分层架构对应的是客户端的SDK，最底层的统一网络库SDK集中了我们对网络优化的策略，并向上为各个应用网关技术的SDK提供API。

基于上面的开放架构，业务方可以选择直接开放具体的后端服务对接不同的应用网关，不需要了解网络背后的细节，并通过应用网关如API网关提供的开发工具快速生成客户端代码。业务方也可以基于这个接入层设计自己的协议。

统一接入层集中管理了用户的设备、在线状态，并提供信息的双向传递能力。

如下图所示：

网关将致力于解决中间网络的通讯，为上层的服务提供高质量的双向通讯能力。

6、稳定性与容灾

稳定性与容灾是服务端中间件永恒的主题，统一接入层这样一个汇聚网关收益和风险是并存的，一旦这个入口故障了，波及的用户范围是不可想象的，如何做的更加稳定，是一个巨大的挑战。

6.1网关架构的优化

对于一个统一网关来说，对接的业务网关的信息传递特点是不一样的，大部分的业务在全天都是比较平缓的，但是个别营销类业务会在短时间内发布海量的信息，这样的信息发布会抢占网关的大量资源，对于用户的正常访问会产生影响。

举个例子：push服务需要通过网关推送2亿条消息，而这些消息需要在短时间内全部推送完，而同时网关在为正常的用户的交互提供服务，海量信息的推送和正常的用户交互相互竞争资源，最终会造成正常用户的交互失败，对于业务来说，这是不可接受的。

基于上面的情况考虑，整个网关在布署上分为两个集群：

1）一个集群处理常态的在线用户访问；
2）一个集群处理海量信息的推送。

如下图所示，通过这样的方式，避免了业务形态不同，对统一网关的冲击，将不同的业务形态进行了隔离。

6.2异地多活

在异地多活的整体方案中，统一网关承担了快速引导流量的职责，也是这一方案顺利实施的一个重要环节。

异地多活是一个多机房的整体方案，在多个地区同时存在对等的多个机房，以用户维度划分，多机房共同承担全量用户的流量；在单个机房发生故障时，故障机房的流量可以快速的被迁引到可用机房，减少故障的恢复时间。

6.2.1）无线接入层单元化的协商机制：

先看一下web端在这异地多活中的实现方式：

从上图可以看到，浏览器的业务器求会发给CDN，由CDN上保存的分发规则，向后续的单元机房分发。

无线端也这样做吗？

1）客户端拥有强大的能力，可以做的更灵活；
2）CDN的分发节点带来更多的机器成本；
3）对于需要双工通讯能力的客户端，消息投递更为复杂。

这些是我们思考与WEB不同的地方，是不是能做些不一样的选择？

如上图所示, 我们借助了客户端的强大能力，利用协商的机制来完成用户的请求正确被分配到不同的单元。

含以下几点：

1）客户端的请求始终带上当前用户归属单元的信息；
2）当请求到达服务端时，服务端判断用户归属单元是否正确，不正确将用户重定向到正确的单元；
3）当前请求由网关在服务端上通过跨单元调用保证业务的正确性；
4）当客户端归属单元更新后，后续的请求都会发到正确的单元机房。

6.2.2）无线接入层单元化的旁路调度：

协商机制看起来很不错，这里一个重磅炸弹丢过来了，机房的入口网络断了！

如上图，外网不可用，协商的机会都没有故障单元的用户无法恢复，这时旁路的调度服务出场了。

如上图，我们设计的调度中心这时又承担了单元化的旁路调度职责，当app访问的单元无法访问的时候，app会访问不同单元的调度中心，询问用户的归属单元。通过这种方式取得可用的单元节点，将用户切到正确的单元。这个方案同样适用于单机房的接入层网关不可用的场景。

6.2.3）应用层网关不可用：

某个单元机房的应用层网关不可用，这时等待应用网关排查问题需要的时间比较久，为了达到最快的故障恢复，我们通过开关把修改接入层的转发规则，将流量切到可用的单元。

如下图所示：

7、端到端网络优化

7.1统一网络库

在做网络优化一开始，我们想做一个通用的网络库，这个网络库包含策略、httpDNS、SPDY协议等一切系统网络优化需要的方方面面。（如果你对httpDNS不甚了解，可以详读《全面了解移动端DNS域名劫持等杂症：原理、根源、HttpDNS解决方案等》）

上层api网关请求逻辑、推送逻辑、上传下载逻辑对于这样一个通用网络库来说都是业务。在分层上将通用网络库和上层应用逻辑分开、彻底解耦，对长期持续优化网络是很有必要。

如下图所示架构：

这样架构上分离，可以让我们更专注更系统化去做无线网络优化。

统一网络库的几个重要特性：

1）灵活控制客户端网络行为策略（建连、超时处理、请求协议、是否加密）；
2）包含HTTPDNS；
3）支持异地多活；
4）更细粒度控制和调度(域名级和域名下参数级)。

1、2、3、4均由网络调度中心的集群控制，我们希望这个可以做到与业务无关，去掉一些阿里的业务属性后，这个模块大家可以理解为HTTPDNS，可以理解我们在HTTPDNS之外做了大量网络优化的端到端的工作。

7.2就近就快接入

基于网络库我们实现了一套智能学习的网络策略，智能学习客户端在不同网络环境下建连策略，用户重新回到这个网络环境会给出最优的策略进行快速连接，并定期去更新或淘汰本地cache的历史最优网络策略。

为了建立更加迅速在各自网络下穿透性更好，接入服务器支持了多种协议和端口，客户端建连时可以极速接入网络。

我们有一个重要指标是打开客户端30秒内网络请求成功率，就是关注连的快给用户体验带来的价值。

基于调度中心，我们搭建了一个智能大数据分析平台，将客户端在在网络请求过程中的数据如建连时间、首包收取时间、整包收取时间、ssl握手时间等重要指标收集上来。根据这些指标分析出网络异常区域，调整我们的就近就快接入规则，甚至推动IDC建设和CDN的布点完善。

7.3弱网优化和抗抖动

在弱网优化上我们尝试了QUIC协议，在网络延时较高、丢包严重情况下比TCP有更好表现。

线上手机淘宝灰度版本实测切换到QUIC后，平均RT收益有接近20%。考虑QUIC在移动网络可能存在穿透性问题，未来我们将采取SPDY为主，QUIC为辅助的模式来完善我们的网络链接策略。

现在QUIC协议在移动端应用的越来越广泛，有兴趣的话可详细以下文章：

同样在一些网络环境较差情况下，我们采取长短链接结合方式，在长链接遇到请求超时或穿透性较差情况，利用短链接HTTP短链接去请求数据（在移动网络环境下HTTP协议尤其HTTP1.0的穿透性是最好的），这样可以在一些极端情况下最大程度保证用户体验。

数据如下图：

网络切换和网络抖动情况下的技术优化也是一个很重要的方面，我们经常遇到移动设备网络切换和信号不稳定的情况，在这种情况我们怎么保证用户的体验？

针对这种情况我们的思路是有策略合理增加重试。我们对一个网络请求以是否发送到socket缓冲区作为分割，将网络请求生命周期划分为“请求开始到发送到 socket缓冲区”和“已经发送到socket缓冲区到请求结束”两个阶段。在阶段一内请求失败了，会根据业务需求帮助业务请求去做重试。阶段二请求失败只针对读操作提供重试能力。

设想一个场景：用户在进电梯发起一个刷新数据请求，进到电梯因为网络抖动的原因网络链接断了，这个时候我们能够合理策略去做重试，这样当用户离开电梯时很可能网络请求重试成功，帮助用户拉到了想要的数据，提升了用户体验和客户端的网络抗抖动能力。

7.4加密传输1秒钟法则

众所周知的传统https的整个握手流程是非常重的，在网络质量不高的情况下，造成建连过慢，用户体验惨不能睹，甚至都无法完成安全握手。然而从安全的角度我们是需要一个安全的传输通道保护用户的隐私数据。

安全与网络这一对冲突放在我们的面前，需要在技术上有所突破，因此我们自建了一套slight-ssl的技术，参考了tls1.3的协议，通过合并请求，优化加密算法，运用session-ticket等策略，最终在安全和体验之间找到了一个平衡点，在基本不牺牲用户体验的基础上，达到了安全传输的目地, 同时还大幅度提升了服务端的性能。通过技术的创新，我们实现了无线网络加密传输下1秒钟法则。

关于TLS1.3在移动端的应用，也可以详读微信团队分享的这篇《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》。

附录：有关移动端弱网方面的资料汇总

2 楼: logikoisto · 3 年前

学到学到了感谢52IM

3 楼: 俊飞 · 2 年前

感谢分享、这方案很牛逼

4 楼: JackJiang · 2 年前

引用：俊飞发表于 2020-11-18 00:43
感谢分享、这方案很牛逼

能看懂这个的，技术都不赖，。。。

5 楼: Frank · 4 个月前

不错,其实qq有篇讲接入层也不错.

本文目录

1、引言

2、专题目录

3、技术背景

4、移动网络环境的挑战性一直都存在

5、整体技术架构