chanong 建筑之路是迭代和进化的。
以手机淘宝为例，从早期的HTTP API网关，到承担双十一期间流量主力的自研高性能、全双工、安全的阿里云通道服务ACCS，经历了基础设施的演进、网络优化，我们在协议改进、远程多活、网络调度等方面积累了丰富的经验，本文借此机会总结一下整个技术演进过程。
1. 技术背景
回顾双十一期间移动电商业务的初步开展，双十一当天移动端交易额达到243亿，占总交易额571亿的42.6%。
业务的快速发展需要更加主动的推送来触达用户。
一些新的互动和游戏形式需要将买家与买家、买家与卖家、买家与专家联系起来。
与其他知名系统一样，早期推送采用轮询模式。
由于缺乏有效的通道能力，早期的业务采用了不断轮询服务器的方式。
轮询的方式不仅给服务器带来了不必要的压力，而且对用户手机造成了电量和流量的巨大浪费。
双十一等大型促销期间，过多不必要的请求可能会导致后端集群限流，影响用户体验。
2、移动网络环境的挑战一直存在
随着3G、4G、5G移动网络的广泛应用，网络速度得到显着提升。
然而网络环境的多样性和差异性使得移动网络环境更加复杂，双十一等高峰时段经常出现移动网络劫持等问题。
解决此类问题的效率是很低的。 需要跟踪用户、重现场景，甚至联系网络工程师和运营商进行故障排除，耗时较长。
在我们的舆情反馈中，经常有用户反映“某页面加载慢、页面打不开、请求速度慢、某功能打开慢”等问题。
过去，我们没有很多办法来处理这些问题。 我们只能一一调查，非常被动。 许多网络问题都是偶发的，一旦错过就很难追查。
出现此类问题的原因有很多：
在PC时代，我们访问网站的网络条件相对稳定，因此在开发过程中很少考虑网络对用户体验的影响。
然而，移动应用程序的情况则不同。 尤其是在我国，基础移动网络环境尚不完善。 许多用户在地铁、公交车等移动环境中访问它。 移动基站的频繁切换进一步加剧了网络的不稳定。
从手机淘宝的数据来看，我们的日常活跃用户有很大一部分来自于网络环境较差的地区。 如果端到云的连接不稳定、时延较高，那么用户体验就无从谈起。
基本网络效率就像火车，时延就是火车的速度（发车时间），带宽就是火车的运载能力，整个传输物理链路就像火车的铁轨。
在当前复杂的移动网络环境下，我们的目标是让所有用户在手机淘宝上享受流畅的体验。
下图可以帮助大家更直观的了解我国的移动网络环境。
它描述了从用户到IDC的端到端路由。 数据传输时间长、丢包率高、安全性差。 DNS劫持、内容劫持等问题在我国相当普遍。
注：请点击图片查看清晰！
因此，在网络渠道优化方面，我们还有很多工作要做，探索如何突破运营商基础网络的限制，为用户打造完美的购物体验。
3、整体技术架构
为了满足移动电子商务业务快速发展的需求，我们决定打造世界一流的网络接入服务，打造无线网络下的“水、电、煤”基础设施。
这样的基础设施需要实现四个目标：
在这四个目标之上，就是围绕这个接入服务的运维体系，旨在帮助最终用户获得良好的终端体验，协助开发者快速建立自己的业务。
注：请点击图片查看清晰！
如上图所示，我们将整个接入服务分为两层：
同时，我们使用统一的调度服务来代替传统的DNS。 调度服务作为我们的控制中心，可以有效指挥客户端，避免受到DNS污染的影响。
与服务端的分层架构相对应的是客户端的SDK。 最底层的统一网络库SDK汇集了我们的网络优化策略，并为每个应用网关技术的SDK提供了API。
基于这种开放架构，业务方可以选择直接开放特定后端服务，连接不同的应用网关，无需了解网络背后的细节，通过应用网关提供的开发工具（如API）快速生成客户端代码网关）。
业务方也可以基于这个接入层设计自己的协议。
统一接入层集中管理用户设备和在线状态，提供双向信息传输能力。
如下所示：
注：请点击图片查看清晰！
该网关将致力于解决中间网络的通信问题，为上层服务提供高质量的双向通信能力。
4. 稳定性和容灾
稳定性和容灾是服务器端中间件始终关注的问题。 统一接入层汇集了网关的好处和风险。
一旦入口出现问题，受影响的用户范围将难以想象。 如何实现更高的稳定性是一个巨大的挑战。
4.1 网关架构优化
对于统一网关来说，不同的业务网关具有不同的信息传输特性。
大部分商家全天相对稳定，但部分营销商家会在短时间内发布大量信息。 这种信息发布会占用网关大量资源，影响用户正常访问。
例如：推送服务需要通过网关推送2亿条消息，并且这些消息需要在短时间内发送完毕。 同时，网关仍然为正常的用户交互提供服务。 大量的信息推送与正常的用户交互争夺资源，最终可能导致正常的用户交互失败。 这对企业来说是不可接受的。
基于以上情况，整个网关在部署上分为两个集群：
如下图所示，这种部署方式避免了不同业务形态对统一网关的影响，实现了不同业务形态的隔离。
注：请点击图片查看清晰！
4.2 多去异地生活
在异地多活整体解决方案中，统一网关承担着快速引导流量的职责，是保证方案成功实施的重要环节。
异地多活是多机房的整体解决方案。
异地多活架构主要是指多个区域同时存在多个等效机房，按用户维度划分，多个机房共同承担所有用户的流量；
当单个机房发生故障时，可以将故障机房的流量快速重定向到可用机房，从而缩短故障恢复时间。
4.2.1 无线接入层单元化的协商机制：
我们先来看看这个远程多活环境下Web端是如何实现的：
注：请点击图片查看清晰！
从上图我们可以看到，浏览器的业务请求会发送到CDN，然后根据CDN上保存的分发规则将流量分发到后续站点。
无线端也这样做吗？
这些是我们正在考虑的与网络不同的事情。 我们可以做出一些不同的选择吗？
注：请点击图片查看清晰！
如上图所示，我们依靠客户端强大的能力，利用协商机制将用户请求正确分配到不同的单元。
包含以下几点：
4.2.2 无线接入层单元化旁路调度：
协商机制看上去很美好，但这里却抛出了一个重磅炸弹：机房入口网络断线！
注：请点击图片查看清晰！
如上图所示，当外部网络不可用时，就没有协商的机会，故障单元的用户也无法恢复。 这时，旁路调度服务就登场了。
注：请点击图片查看清晰！
如上图所示，我们设计的调度中心现在承担了单元化旁路调度职责。
当应用访问的单位无法访问时，应用会访问不同单位的调度中心，询问用户的家庭单位。
这样就获得了可用的单元节点，并将用户切换到正确的单元。
该方案同样适用于单个机房接入层网关无法使用的情况。
4.2.3 应用层网关不可用：
某单位机房应用层网关不可用。 此时需要等待应用网关排查问题的时间较长。 为了实现最快的故障恢复，我们通过交换机修改接入层的转发规则，将流量切到可用的流量上。 单元。
如下所示：
注：请点击图片查看清晰！
5. 端到端网络优化 5.1 统一网络库
在网络优化的早期，我们的目标是创建一个通用的网络库，其中包含所有系统所需的网络优化的各个方面，包括策略、SPDY协议等。
上层API网关请求逻辑、推送逻辑、上传下载逻辑都是这样一个通用网络库的业务。
在层层面将通用网络库与上层应用逻辑分离、完全解耦，对于网络的长期持续优化是非常有必要的。
架构如下图所示：
注：请点击图片查看清晰！
这种架构分离使我们能够更加专注和系统地优化无线网络。
统一网络接入库的几个重要特性：
1、2、3、4均由网络调度中心集群控制。 我们希望这可以独立于业务。 去掉阿里巴巴的一些业务属性之后，大家就可以理解这个模块了。 你可以理解为我们在网络优化之外做了很多端到端的工作。
5.2 尽快获得访问权限
基于网络库，我们实现了一套智能学习网络策略。
该策略可以根据客户端在不同网络环境下的连接策略进行智能学习。 当用户返回到这个网络环境时，会给出快速连接的最优策略，并且本地缓存的历史最优会定期更新或淘汰。 网络战略。
为了实现更快地穿透各个网络并提供更好的访问性能，接入服务器支持多种协议和端口，客户端在建立连接时可以实现对网络的高速访问。
我们关注的一个重要指标是客户端打开后30秒内网络请求的成功率。 这是为了提供更快的连接速度以改善用户体验。
以调度中心为基础，搭建智能大数据分析平台。
智能大数据分析平台在网络请求过程中收集客户端的重要数据，例如：
通过分析这些数据，我们可以识别网络异常区域，调整我们的短距离高速访问规则，甚至促进IDC建设和CDN布局的优化。
5.3 弱网优化及抗抖动
在弱网络优化方面，我们尝试了QUIC协议，发现在网络延迟较高、丢包严重的情况下，其性能优于TCP。
经在线移动淘宝灰度版实际测试，改用QUIC后，平均RT收入提升近20%。
但考虑到QUIC在移动网络中可能存在渗透问题，未来我们计划以SPDY为主、QUIC为补充来完善我们的网络连接策略。
“SPDY”（发音与“”相同）是正在开发的一种新的网络协议，旨在最大限度地减少网络延迟，提高网络速度，优化用户的网络体验。
SPDY并不是用来替代HTTP的协议，而是对HTTP协议的增强。 新协议的功能包括流复用、请求优先级和 HTTP 标头压缩。 开发了原型网络服务器和支持 SPDY 协议的浏览器版本。
谷歌表示，引入SPDY协议后，在实验室测试中页面加载速度比之前快了64%。 该数据基于全球排名前25的网站的下载测试。 目前，SPDY团队已经开发出了可用的原型产品。 谷歌决定开放这个项目，并希望“在线社区能够积极参与、提供反馈和帮助”。
在网络环境较差的情况下，我们采取了长短链接结合的策略。
当长链接遇到请求超时或穿透性差时，我们使用短链接HTTP来请求数据（在移动网络环境下，HTTP协议尤其是HTTP1.0具有更好的穿透性），这样在极端情况下，最大程度保证用户体验。
数据如下图：
网络切换和网络抖动情况下的技术优化也是非常重要的一个方面。 我们经常会遇到移动设备网络切换、信号不稳定的情况。 在这种情况下如何保证用户体验呢？
针对这种情况，我们的想法是有策略地、合理地增加重试。
我们根据是否发送到缓冲区来划分网络请求，并将网络请求生命周期分为两个阶段：“从请求开始到发送到缓冲区的时间”和“从请求发送到缓冲区的时间”发送到缓冲区到请求结束”。
如果第一阶段请求失败，将根据业务需求重试业务请求。 第 2 阶段请求失败仅提供读操作的重试能力。
想象一个场景：
用户进入电梯时发起刷新数据请求。 由于网络抖动，电梯内网络连接断开。
这种情况下，我们可以采取合理的策略再试一次。
这样，当用户离开电梯时，网络请求很可能已经重试成功，帮助用户获取所需的数据，从而提高用户体验和客户端的网络抗抖动能力。
5.4 加密传输1秒规则
微信扫一扫打赏
支付宝扫一扫打赏
