阿里无线 11.11：手机淘宝移动端接入网关基础架构演进之路

移动网络优化是超级 App 永恒的话题，对于无线电商来说更为重要，网络请求体验跟用户的购买行为息息相关，手机淘宝从过去的 HTTP API 网关，到 2014 年升级支持 SPDY，2015 年双十一自研高性能、全双工、安全的 ACCS（阿里云通道服务) 扛住双十一战场主要流量，无论是基础架构的演进、网络调优、协议的优化、异地多活、网络调度上都有不少宝贵的经验与大家分享。

ACCS 基于无线场景精心设计的双工 、安全、低时延、开放的移动统一接入层服务，在双十一当天稳定高效地服务了近 2 亿的在线用户，支持了峰值 4500 万的在线长连接，这个背后的故事以及我们的思考是什么呢？

1. 业务高速发展下诉求

回到一年前，移动电商在 2014 年双十一业务开始兴起，2014 年双十一当天移动成交 243 亿占整体 571 亿的 42.6%，业务高速发展希望更多主动推送去触达用户，一些新的玩法和互动形式，需要连接买家与买家、买家与卖家、买家与达人，因为没有有效的通道能力，业务采取的是不停去轮询服务器，一来对服务器造成不必要的压力，二来对于用户手机的电量流量也是极大的浪费，关键在大促当天不必要的请求过大甚至会导致后端集群限流，从而影响到用户体验。

信息传播形态的变化的背后是移动化带来新的技术特征导致的结果。在过去的几年，移动电商从无到有，手机淘宝一直是这个领域的先行者。移动电商从最初的复制 WEB 的业务形态到移动特性不断涌现，更多的互动形式的出现，向社交化、娱乐化不断迈进的今天，一个单纯的商品的陈列架形式已经不能满足业务的需求。业务上需要实时的触达用户，充分发挥移动的特性，将消费时间的碎片利用起来，事实也证明了用户的消费时间随着移动化的进程不断发生变化，逐步分布到全天的碎片时间中。同时货架形态也在向社区化、娱乐化的方向发展，这些都对网络层连接用户有了更高的要求。更多的媒体形态和展示方式，对网络层提出了更多元的要求。大家可以关注到手机淘宝内的消息盒子、微淘、淘友这些产品都是业务求变的体现，业务的变化倒逼技术的前进。

2. 移动网络环境依然严峻

移动网络的速度在过去几年有很大提升，但网络环境的多样性和差异性使移动网络的环境更加复杂，在去年双十一之前我们还常遇到一些移动网络劫持的事情。网络劫持这块问题的排查效率很低，需要找到用户、复现现场，甚至找网工、运营商配合排查，一查就是几天过去。同时在我们的舆情反馈上总是看到用户在说－“某个页面加载中、页面打不开、请求很慢、打开某个功能很慢”，面对这些问题过去我们是没有太好的办法，只能猫抓耗子一桩桩去排雷很被动。很多网络的问题是偶现的，一旦错过现在就无从查起，背后的原因很多：

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

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

基础网络的效率就像一辆列车，时延是火车的速度 (启动时间)，而带宽就像火车的车厢装载量，整个传输的物理链路就像火车的铁轨。目前现实条件下的移动网络条件非常复杂，既有高铁这样先进的传输渠道，也有不少老旧缓慢的绿皮车还在服务很多用户。我们的目标很简单，就是想让所有用户都能在手机淘宝获得流畅的体验，不论你坐的是“高铁”还是“绿皮车”。

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

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

3.ACCS 整体架构

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

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

如图 -1 所示，在整个接入服务上我们划分为两层，接入网关层和应用网关层。接入网关负责连接的保持、消息的解析、消息的分发。应用网关实现各种应用层协议：API、SYNC、RPC、PUSH 等，在应用网关的背后是具体的业务系统。同时我们建立了一个统一调度服务，而不是采用传统的 DNS，调度服务是我们的控制中心，通过它我们可以强有力的指挥我们的客户端，并且不会受到 DNS 污染的影响。

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

(图 -1)

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

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

(点击放大图像)

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

4. 稳定性与容灾

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

4.1 网关架构的优化

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

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

基于上面的情况考虑整个网关在布署上分为两个集群，一个集群处理常态的在线用户访问，另一个集群处理海量信息的推送。如下图 -2 所示，通过这样的方式，避免了业务形态不同，对统一网关的冲击，将不同的业务形态进行了隔离。

(点击放大图像)

(图 -2)

4.2 异地多活

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

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

4.2.1 无线接入层单元化的协商机制

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

(图 -3)

从图 -3 可以看到，浏览器的业务器求会发给 CDN，由 CDN 上保存的分发规则，向后续的单元机房分发。无线端也这样做吗？客户端拥有强大的能力，可以做的更灵活；CDN 的分发节点带来更多的机器成本；对于需要双工通讯能力的客户端，消息投递更为复杂。这些是我们思考与 WEB 不同的地方，是不是能做些不一样的选择？

(图 -4)

如图 -4, 我们借助了客户端的强大能力，利用协商的机制来完成用户的请求正确被分配到不同的单元，含以下几点:

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

4.2.2 无线接入层单元化的旁路调度

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

(图 -5)

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

(图 -6)

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

4.2.3 应用层网关不可用

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

(图 -7)

5. 端到端网络优化

5.1 统一网络库

在做网络优化一开始，我们想做一个通用的网络库，这个网络库包含策略、httpDNS、SPDY协议等一切系统网络优化需要的方方面面。上层 api 网关请求逻辑、推送逻辑、上传下载逻辑对于这样一个通用网络库来说都是业务。在分层上将通用网络库和上层应用逻辑分开、彻底解耦，对长期持续优化网络是很有必要。如下图 -8 所示架构。

(图 -8)

这样架构上分离，可以让我们更专注更系统化去做无线网络优化。统一网络库的几个重要特性:

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

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

5.2 就近就快接入

基于网络库我们实现了一套智能学习的网络策略，智能学习客户端在不同网络环境下建连策略，用户重新回到这个网络环境会给出最优的策略进行快速连接，并定期去更新或淘汰本地 cache 的历史最优网络策略。为了建连更加迅速在各自网络下穿透性更好，接入服务器支持了多种协议和端口，客户端建连时可以极速接入网络。我们有一个重要指标是打开客户端30S**** 内网络请求成功率，就是关注连的快给用户体验带来的价值。

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

5.3 弱网优化和抗抖动

在弱网优化上我们尝试了 QUIC, 在网络延时较高、丢包严重情况下比 TCP 有更好表现。线上手机淘宝灰度版本实测切换到 QUIC 后，平均 RT 收益有接近 20%。考虑 QUIC 在移动网络可能存在穿透性问题, 未来我们将采取 SPDY 为主，QUIC 为辅助的模式来完善我们的网络链接策略。同样在一些网络环境较差情况下，我们采取长短链接结合方式，在长链接遇到请求超时或穿透性较差情况，利用短链接 HTTP 短链接去请求数据 (在移动网络环境下 HTTP 协议尤其 HTTP1.0 的穿透性是最好的)，这样可以在一些极端情况下最大程度保证用户体验。数据如下图 -9

(点击放大图像)

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

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

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

5.4 加密传输 1S 钟法则

众所周知的传统 https 的整个握手流程是非常重的，在网络质量不高的情况下，造成建连过慢，用户体验惨不能睹，甚至都无法完成安全握手；然而从安全的角度我们是需要一个安全的传输通道保护用户的隐私数据。安全与网络这一对冲突放在我们的面前，需要在技术上有所突破，因此我们自建了一套 slight-ssl 的技术，参考了 tls1.3 的协议，通过合并请求，优化加密算法，运用 session-ticket 等策略，最终在安全和体验之间找到了一个平衡点，在基本不牺牲用户体验的基础上，达到了安全传输的目地, 同时还大幅度提升了服务端的性能。通过技术的创新，我们实现了无线网络加密传输下 1S 钟法则。

6. 总结和感悟

手机淘宝 2015 年双十一网络接入工作关键字总结:

ACCS**、网关架构优化、异地多活、弱网优化和抗抖动、加密传输1S钟法则 **

几点感悟：

1. 网络接入任重道远，对于手机淘宝这样一个亿级 UV 无线电商平台, 稳定性是立足之本。
2. 接入层架构调整要么基于业务需求（能够适应业务的变化的架构才是最合适的)，要么能够极大节省成本和提升稳定性。架构的演进一定是迭代式不能一蹴而就，重视积累和反思。
3. 移动接入层解决方案上可以更多利用客户端能力，这个是无线对比 PC Web 的优势所在。
4. 无线网络这两年网速是提升了但网络环境更加复杂，万物互联、设备随时随地在线、运营商的复杂性会对移动网络优化带来更多的挑战，端到端的网络优化以及推进运营商合作任重而道远。

最后打个广告，基于 ACCS 的云推送服务 Agoo 已经在公测中，未来我们的移动基础设施将逐步上云提供给业界开发者朋友们。

手机淘宝技术团队吴志华（天施）、洪海（孤星）、陈虓将（仲升）等专家参与本文创作。

感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群（已满），InfoQ 读者交流群（#2））。