亿级长连接，淘宝接入层网关的架构设计
说在前面
在40岁老架构师 尼恩的读者交流群(50+)中，很多小伙伴拿到一线互联网企业如阿里、网易、有赞、希音、百度、滴滴的面试资格。
最近，尼恩指导一个小伙伴简历，写了一个《高并发网关项目》，此项目帮这个小伙拿到 字节/阿里/微博/汽车之家 面邀， 所以说，这是一个牛逼的项目。
为了帮助大家拿到更多面试机会，拿到更多大厂offer，
尼恩决定：9月份给大家出一章视频介绍这个项目的架构和实操，《33章：10Wqps 高并发 Netty网关架构与实操》，预计月底发布。然后，提供一对一的简历指导，这里简历金光闪闪、脱胎换骨。
《33章：10Wqps 高并发 Netty网关架构与实操》 海报如下：
配合《33章：10Wqps 高并发 Netty网关架构与实操》， 尼恩会梳理几个工业级、生产级网关案例，作为架构素材、设计的素材。
前面梳理了
- 《日流量200亿，携程网关的架构设计》
- 《千万级连接，知乎如何架构长连接网关？》
- 《日200亿次调用，喜马拉雅网关的架构设计》
- 《100万级连接，爱奇艺WebSocket网关如何架构》
除了以上的4个案例，在梳理学习案例的过程中，尼恩又找到一个漂亮的生产级案例：《亿级连接，淘宝接入层网关的架构设计》，
注意，这又一个非常 牛逼、非常顶级的工业级、生产级网关案例。
这些案例，并不是尼恩的原创。
这些案例，仅仅是尼恩在《33章：10Wqps 高并发 Netty网关架构与实操》视频备课的过程中，在互联网查找资料的时候，收集起来的，供大家学习和交流使用。
《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请到公号【技术自由圈】获取
文章目录
-
- 说在前面
- 亿级连接，淘宝接入层网关的架构设计
- 1、技术背景
- 2、移动网络环境的挑战性一直都存在
- 3、整体技术架构
- 4、稳定性与容灾
-
- 4.1 网关架构的优化
- 4.2 异地多活
-
- 4.2.1 无线接入层单元化的协商机制：
- 4.2.2 无线接入层单元化的旁路调度：
- 4.2.3 应用层网关不可用：
- 5、端到端网络优化
-
- 5.1 统一网络库
- 5.2 就近就快接入
- 5.3 弱网优化和抗抖动
- 5.4 加密传输1秒钟法则
- 说在最后：有问题可以找老架构取经
- 推荐阅读
亿级连接，淘宝接入层网关的架构设计
原文作者：手淘团队
架构之路，充满了坎坷。
架构之路，是迭代式，演进式的。
以手机淘宝为例，从早期的 HTTP API 网关，到后来在双十一活动中承担主要流量的自研高性能、全双工、安全的 阿里云通道服务ACCS，在基础架构进化、网络优化、协议改进、异地多活、网络调度等方面，都积累了丰富的经验，本文借此机会总结了整个技术演进过程。
1、技术背景
回顾移动电商在双十一业务启动之初，当时双十一当天的移动成交额达到 243 亿，占总成交额 571 亿的 42.6%。
业务的快速发展，需要更多的主动推送以触达用户，
一些新的互动形式和玩法需要连接买家与买家、买家与卖家、买家与达人。
和其他的著名系统一样，早期的推送，是轮询模式的。
由于缺乏有效的通道能力，早期业务采取的是不断轮询服务器。
轮询方式，不仅给服务器带来不必要的压力，也对用户手机的电量和流量造成了巨大的浪费。
在双十一等大型促销活动期间，过多的不必要请求，可能会导致后端集群限流，从而影响用户体验。
2、移动网络环境的挑战性一直都存在
随着 3G、4G、5G 移动网络的广泛应用，网速得到了显著提升。
然而，网络环境的多样性和差异性使得移动网络环境变得更加复杂，双十一等高峰期常常出现移动网络劫持等问题。
解决这类问题的效率很低，需要追踪用户、再现现场，甚至联系网络工程师和运营商进行排查，耗时较长。
在我们的舆情反馈中，用户经常反映“某个页面加载缓慢、页面无法打开、请求速度慢、某个功能打开速度慢”等问题。
过去我们应对这些问题的办法不多，只能逐一排查，非常被动。很多网络问题偶发性较强，一旦错过就难以追踪。
诸如此类的问题，背后的原因很多：
- 1）运营商问题；
- 2）机房部署原因；
- 3）客户端SDK Bug；
- 4）弱网和网络抖动；
- 5）DNS劫持和数据篡改。
在 PC 时代，我们访问网站的网络条件相对稳定，因此在开发过程中很少考虑网络对用户体验的影响。
然而，移动 APP 的情况就不同了，尤其在我国，基础移动网络环境尚不完善，很多用户在地铁、公交车等移动环境下访问，移动基站的频繁切换进一步加剧了网络不稳定性。
从手机淘宝的数据来看，我们每天活跃用户中有很大一部分来自网络环境较差的地区。如果端到云的连接不稳定、延迟高，那么用户体验就无从谈起。
基础网络效率就像一辆火车，时延是火车的速度（启动时间），带宽是火车的车厢容量，整个传输物理链路就像是火车的铁轨。
在当前复杂的移动网络环境下，我们的目标是让所有用户都能在手机淘宝享受到流畅的体验。
下面这张图能帮助大家更直观地了解我国移动网络环境。
它描述了从用户到 IDC 的端到端路由情况，数据传输耗时长、丢包率高，同时安全性也较差，DNS 劫持、内容劫持等问题在我国相当普遍。
因此，在网络通道优化方面，我们有很多工作可以去做，去探索如何突破运营商基础网络的局限，为用户打造完美的购物体验。
3、整体技术架构
为了满足移动电商业务迅速发展的需求，我们决定构建一个世界一流的网络接入服务，打造一个无线网络下的“水、电、煤”基础设施。
这样一个基础设施需要做到的四个目标：
- 1）全双工；
- 2）低延时；
- 3）高安全；
- 4）开放。
在这四个目标之上，是围绕这个接入服务配套的运维体系，旨在帮助最终用户获得良好的终端体验，同时协助开发者快速构建自己的业务。
如上图所示，在整个接入服务上我们划分为两层：
- 1）接入网关：负责保持连接、解析和分发消息；
- 2）应用网关：实现各种应用层协议，如 API、SYNC、RPC、PUSH 等，应用网关背后是具体的业务系统。
同时，我们采用了统一调度服务而非传统的 DNS，调度服务作为我们的控制中心，可以有效地指挥客户端，并避免受到 DNS 污染的影响。
与服务端的分层架构相对应的是客户端的 SDK，最底层的统一网络库 SDK 汇集了我们的网络优化策略，并为各个应用网关技术的 SDK 提供 API。
基于这种开放架构，业务方可以选择直接开放具体的后端服务，对接不同的应用网关，无需了解网络背后的细节，并通过应用网关（如 API 网关）提供的开发工具快速生成客户端代码。
业务方也可以基于这个接入层设计自己的协议。
统一接入层集中管理了用户的设备和在线状态，并提供信息双向传递能力。
如下图所示：
网关将致力于解决中间网络的通讯问题，为上层服务提供高品质的双向通信能力。
4、稳定性与容灾
稳定性与容灾是服务端中间件始终关注的问题，统一接入层汇聚了网关的利益与风险，
一旦入口出现问题，受影响的用户范围将无法想象，如何实现更高稳定性，是一项巨大的挑战。
4.1 网关架构的优化
对于一个统一网关而言，不同业务网关的信息传递特性各异。
大部分业务全天较为平稳，但某些营销类业务会在短时间内发布大量信息，这种信息发布会占用网关大量资源，对用户正常访问产生影响。
举个例子：push 服务需要通过网关推送 2 亿条消息，这些消息需在短时间内全部发送完毕。同时，网关还在为正常用户交互提供服务，大量信息推送与正常用户交互争夺资源，最终可能导致正常用户交互失败，对业务而言，这是不能接受的。
基于上面的情况，整个网关在布署上分为两个集群：
- 1）一个集群处理常态的在线用户访问；
- 2）一个集群处理海量信息的推送。
如下图所示，通过这种部署方式，避免了不同业务形态对统一网关的冲击，实现了不同业务形态的隔离。
4.2 异地多活
在异地多活的整体方案中，统一网关承担了快速引导流量的职责，这是确保该方案成功执行的重要环节。
异地多活是一个多机房的整体方案，
异地多活架构，主要是在多个地区同时存在对等的多个机房，以用户维度划分，多机房共同承担全量用户的流量；
在单个机房发生故障时，故障机房的流量可以快速的被迁引到可用机房，从而缩短故障恢复的时间。
4.2.1 无线接入层单元化的协商机制：
先看一下web端在这异地多活中的实现方式：
从上图中我们可以看出，浏览器的业务请求会被发送至 CDN，然后根据 CDN 上保存的分发规则，将流量分发至后续的站点。
无线端也这样做吗？
- 1）客户端具有强大的能力，能够更加灵活地处理；
- 2）CDN 的分发节点会增加更多的硬件成本；
- 3）对于需要双向通信能力的客户端，信息传递会更加复杂。
这些都是我们在考虑与 web 不同的地方，我们是否能做出一些不同的选择呢？
如上图所示，我们借助了客户端的强大能力，利用协商的机制来完成用户的请求正确被分配到不同的单元。
含以下几点：
- 1）客户端的请求需包含当前用户所属单元的信息；
- 2）当请求抵达服务端时，服务端会判断用户所属单元是否正确，若不正确则将用户重新定向至正确单元；
- 3）当前请求在服务端上通过网关进行跨单元调用，以确保业务正确性；
- 4）当客户端所属单元发生更新后，后续请求将发送至正确单元。
4.2.2 无线接入层单元化的旁路调度：
协商机制看起来很不错，这里一个重磅炸弹丢过来了，机房的入口网络断了！
如上图，当外网不可用时，协商的机会都没有，故障单元的用户无法恢复，此时，旁路调度服务登场。
如上图，我们设计的调度中心这时又承担了单元化的旁路调度职责，
当app访问的单元无法访问的时候，app会访问不同单元的调度中心，询问用户的归属单元。
通过这种方式取得可用的单元节点，将用户切到正确的单元。
此方案同样适用于单机房接入层网关无法使用的情况。
4.2.3 应用层网关不可用：
某个单元机房的应用层网关不可用，这时等待应用网关排查问题需要的时间比较久，为了达到最快的故障恢复，我们通过开关把修改接入层的转发规则，将流量切到可用的单元。
如下图所示：
5、端到端网络优化
5.1 统一网络库
在网络优化的初期，我们的目标是创建一个通用的网络库，该库包含策略、httpDNS、SPDY 协议等所有系统网络优化所需的各个方面。
上层api网关请求逻辑、推送逻辑、上传下载逻辑对于这样一个通用网络库来说都是业务。
在分层上将通用网络库和上层应用逻辑区分开、完全解耦，对于长期持续优化网络是非常必要的。
如下图所示架构：
这样架构上分离，可以让我们更专注更系统化去做无线网络优化。
统一网络接入库的几个重要特性：
- 1）灵活控制客户端网络行为策略（建连、超时处理、请求协议、是否加密）；
- 2）包含HTTPDNS；
- 3）支持异地多活；
- 4）更细粒度控制和调度(域名级和域名下参数级)。
1、2、3、4均由网络调度中心的集群控制，我们希望这个可以做到与业务无关，去掉一些阿里的业务属性后，这个模块大家可以理解为HTTPDNS，可以理解我们在HTTPDNS之外做了大量网络优化的端到端的工作。
5.2 就近就快接入
基于网络库，我们实现了一套智能学习的网络策略。
这个策略可以根据客户端在不同网络环境下的连接策略进行智能学习，当用户重新回到这个网络环境时，会给出最优的策略进行快速连接，并定期更新或淘汰本地缓存的历史最优网络策略。
为了实现更快速的穿透各自网络并提供更好的接入性能，接入服务器支持了多种协议和端口，客户端在建立连接时可以实现高速接入网络。
我们关注的一个重要指标是在客户端打开 30 秒内的网络请求成功率，这是为了提供更快的连接速度，以提高用户体验。
基于调度中心，我们构建了一个智能大数据分析平台，
智能大数据分析平台收集客户端在网络请求过程中的重要数据，如：
- 连接时间、
- 首包接收时间、
- 整包接收时间、
- SSL 握手时间等。
通过分析这些数据，我们可以确定网络异常区域，调整我们的近距离高速接入规则，甚至推动 IDC 建设和 CDN 布局的优化。
5.3 弱网优化和抗抖动
在弱网优化上，我们尝试了 QUIC 协议，发现在网络延迟较高和丢包严重的情况下，其表现优于 TCP。
经过线上手机淘宝灰度版本的实测，切换到 QUIC 后，平均 RT 收益提高了近 20%。
但考虑到 QUIC 在移动网络可能存在穿透性问题，未来我们计划采取 SPDY 为主，QUIC 为辅的方式来完善我们的网络连接策略。
“SPDY”(发音同 “speedy”)是谷歌正在开发一种新的网络协议，以最小化网络延迟，提升网络速度，优化用户的网络使用体验。
SPDY 并不是一种用于替代 HTTP 的协议，而是对 HTTP 协议的增强。新协议的功能包括数据流的多路复用、请求优先级，以及 HTTP 包头压缩。谷歌已经开发一个网络服务器原型机，以及支持 SPDY 协议的 Chrome 浏览器版本。
谷歌表示，引入 SPDY 协议后，在实验室测试中页面加载速度比原先快 64%。这一数据基于对全球 25 大网站的下载测试。目前 SPDY 团队已经开发了一个可使用的原型产品，谷歌决定开放这一项目，希望 “网络社区能积极参与、提供反馈及帮助”。
在网络环境较差的情况下，我们采用了长短链接结合的策略。
当长链接遇到请求超时或穿透性较差的情况时，我们利用短链接 HTTP 去请求数据（在移动网络环境下，HTTP 协议尤其是 HTTP1.0 的穿透性较好），从而在极端情况下最大限度地保证用户体验。
数据如下图：
网络切换和网络抖动情况下的技术优化也是一个很重要的方面，我们经常遇到移动设备网络切换和信号不稳定的情况，在这种情况我们怎么保证用户的体验？
针对这种情况我们的思路是有策略合理增加重试。
我们对一个网络请求以是否发送到socket缓冲区作为分割，将网络请求生命周期划分为“请求开始到发送到 socket缓冲区”和“已经发送到socket缓冲区到请求结束”两个阶段。
在阶段一内请求失败了，会根据业务需求帮助业务请求去做重试。阶段二请求失败只针对读操作提供重试能力。
设想一个场景：
用户在进入电梯时发起一个刷新数据请求，由于网络抖动，电梯内的网络连接断开。
在这种情况下，我们可以采取合理的策略进行重试。
这样，当用户离开电梯时，网络请求很可能已经重试成功，帮助用户获取所需的数据，从而提升用户体验和客户端的网络抗抖动能力。
5.4 加密传输1秒钟法则
众所周知，传统的 HTTPS 握手流程较为繁琐，在网络质量较差的情况下，可能导致连接速度缓慢，用户体验较差，甚至无法完成安全握手。
然而，从安全的角度考虑，我们需要一个安全的传输通道来保护用户的隐私数据。
面对安全与网络体验的冲突，我们需要在技术上取得突破。
因此，我们开发了一套 slight-ssl 技术，参考了 TLS1.3 协议，通过合并请求、优化加密算法、使用 session-ticket 等策略，最终在安全和体验之间找到了平衡点。
在基本不牺牲用户体验的前提下，实现了安全传输的目标，同时还显著提升了服务端的性能。
通过技术创新，我们实现了无线网络加密传输下的 1 秒钟法则。
说在最后：有问题可以找老架构取经
架构之路，充满了坎坷。架构和高级开发不一样：
- 架构问题是open/开放式的，
- 架构问题是没有标准答案的。
正由于这样，很多小伙伴在转型之路上 耗费很多精力，耗费很多金钱，但遗憾的是，一生都没有完成架构升级。
所以，在架构升级/转型过程中，确实找不到有效的方案，可以来找40岁老架构尼恩求助.
前段时间一个17年经验小伙伴，跨专业来做Java，也是面临转架构的难题，几个月没有offer，焦虑不以。
但是经过尼恩几轮指导，顺利拿到了Java架构师+大数据架构师offer 。
所以，如果遇到职业不顺，自己又一个人搞不定的情况下，可以找尼恩帮忙一下，就顺利多了。
推荐阅读
《百亿级访问量，如何做缓存架构设计》
《多级缓存 架构设计》
《消息推送 架构设计》
《阿里2面：你们部署多少节点？1000W并发，当如何部署？》
《美团2面：5个9高可用99.999%，如何实现？》
《网易一面：单节点2000Wtps，Kafka怎么做的？》
《字节一面：事务补偿和事务重试，关系是什么？》
《网易一面：25Wqps高吞吐写Mysql，100W数据4秒写完，如何实现？》
《亿级短视频，如何架构？》
《炸裂，靠“吹牛”过京东一面，月薪40K》
《太猛了，靠“吹牛”过顺丰一面，月薪30K》
《炸裂了…京东一面索命40问，过了就50W+》
《问麻了…阿里一面索命27问，过了就60W+》
《百度狂问3小时，大厂offer到手，小伙真狠！》
《饿了么太狠：面个高级Java，抖这多硬活、狠活》
《字节狂问一小时，小伙offer到手，太狠了！》
《收个滴滴Offer：从小伙三面经历，看看需要学点啥？》
《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》PDF，请到下面公号【技术自由圈】取↓↓↓