挑战“零事故”，苏宁易购O2O购物节大促保障之道！

本文从前端保障、APP 运维、网络支撑和服务监控四个方面全面回顾苏宁易购的大促保障之道。

前端保障

为了保证更好的用户体验，苏宁前端一直都力求了解用户端打开前端 Web 页面的准确性能，获得网站的访问速度和渲染性能，来调整页面的元素和网络配置，并通过引入 WEEX 等技术手段来提高 Wap 页面的打开体验。

01.浏览器端测实时监控用户页面状态

在今年的 O2O 购物节中，苏宁启用了浏览器端测，来获得用户的真正性能数据。与机房的访问相比较，它通过放置于 Web 页面上的 JS来收集性能数据，更能反映用户端的真实情况。

在大促过程中，用户的访问量激增，CDN 节点也会面临更大的压力，通过浏览器端测，可以获取实时的用户速度，并通过关键页面的报警设置，使我们可以在用户端问题爆发之前，快速行动，解决网络问题。

同样的，访问量的增加，也会加剧后端的接口压力，同时浏览器的脚本兼容问题也会影响更多的用户。

借助浏览器端测，系统可以实时的捕捉到浏览器端的 JavaScript 错误，更快的定位问题，保证用户体验。

今年双十一大促中，浏览器端测还会在用户问题的定位排查，慢页面追踪，地域问题分布等各方面，发挥更大的作用。

02.WEEX 加速 APP 端 Wap 页展现

这次大促我们在客户端内大范围使用了 WEEX 方案，目的是为了更好的提升用户体验，提升页面的性能。

在使用 WEEX 之前，系统每次打开 H5 页面都需要有一个 webview 的加载过程，这个过程对用户不是那么友好，使用 WEEX 之后会直接调用原生的加载方式，整个加载场景会变得很流畅，用户不会被一些突兀的加载降低使用体验。

大促期间曝光量需求最高的就是主会场，最终我们采用了主会场 WEEX 定制开发的方案，这样更好的保证了主会场的独立性和稳定性，使主会场能更好的承载大量用户的访问。

同时还有大量的促销页需要开发，针对每天都变的促销页我们开发了大量的 WEEX 模块，使运营有动态搭建 WEEX 模板的能力，在后台可以轻松搭建出丰富多彩的页面。

针对各种模块的动态组装，我们定义了一些特殊场景，减少了一些不必要的模块冲突，减少运营操作出错的概率。

针对一些公司特有的业务，我们把之前 H5 的逻辑重新用 WEEX 的方式重构了一次，使其满足两端业务，大大提高了开发效率和维护成本，真正做到 write once，run any where。

同时和客户端一起重新封装了 JSBridge，使其更加的通用，共享同一套 api，减少学习成本，易用性更强。

使用 WEEX 对前端来说可以更好的开发一些原生的需求，给一些因为版本审核而无法及时上线的需求提供了解决思路；对于用户来说获得了更好的用户体验。

技术本来就是为用户服务，如果能使用户在使用过程中拥有良好的用户体验就是一个成功的技术方案。

APP 运维

在 O2O 购物节期间，苏宁易购移动 APP 面对巨大的流量，单一的技术方案必然不能解决用户环境复杂多样所产生的问题。

所以我们不仅使用全面精准的 APP 实时数据监控，同时还通过灵活的配置配合多样的、针对性的技术方案，实时调整目标用户 APP 的技术运行方案，从而保障用户在 O2O 购物节期间的购物体验。

01.全方位数据监控，促成整体“零事故”

在 O2O 购物节期间，错综复杂的用户环境必然会大大增加 APP 发生错误甚至崩溃的概率，全面、精准的 APP 实时数据监控是我们即时发现问题、解决问题的重要手段。

全面数据监控，保证 APP“零事故”

我们拥有一套完善数据分析系统——云迹。通过云迹系统提供的快捷操作，可以即时的分析出 APP 不同版本、系统、运营商、区域、设备下的 HTTP 访问质量、网络劫持率、ANR 率、崩溃率等通用信息。

这样既可以通过云迹系统提供的 APP 基本信息概览图进行全面综合监控，也可以根据多维度的条件进行筛选。

在 O2O 购物节期间，通过云迹后台发现问题的时候，我们可以使用客户端现有的热修复、插件升级、Wap 页替换等多套技术方案，对问题进行即时修复。

与此同时，我们额外添加了核心业务的自定义数据采集，实时监控核心流程处理的运行状况，实时预防问题的发生，保证 APP 的“零事故”。

精准数据采集，协助服务端“零事故”

本次 O2O 购物节期间，我们在现有全面数据监控的基础上增加了另外一项核心功能——精准数据采集。

当通过云迹后台、用户反馈、电话反馈等渠道收集到用户的报错信息时，我们可以即时通过后台多维度的配置，收集目标用户指定模块、指定场景下的接口请求、本地操作等详细信息，如接口的链接时间、报文大小、数据解析时间、可用内存大小、网络环境等。

采集到在 APP 端发生错误的用户详细信息后，我们可以通过这些信息联合服务端开发，模拟错误发生的场景，一旦发现是服务端也存在业务数据处理逻辑的问题，第一时间进行修复，从而做到协助服务端的“零事故”。

02.精准 DNS 解析，用户访问更稳定

在 O2O 购物节期间，复杂多样的用户网络环境必然会带来各种 DNS 解析失败、DNS 劫持的问题。

为了预防并解决该类问题的出现，在本次 O2O 购物节版本中，APP 端引入的 HTTPDNS 技术。

使用 HTTP 替代 UDP 的方式，提高 DNS 的解析精确率，同时配合云迹的监控，结合不同区域的 DNS 解析情况实时配置 DNS 解析方案，最大程度的提升客户端 DNS 的精准解析。

另一方面通过 HTTPDNS，针对客户端访问量较大的接口，配置灵活的调度方案，缓解大量接口请求引起的局部服务器处理压力，保证用户访问更稳定。

03.网络连接加速，用户体验极致快

当我们通过云迹后台，发现接口网络连接较长，或者是无法连接的情况时（特别是边远地区的用户），APP 在本次的 O2O 购物版本中额外提供的专有链路加速技术——可以对指定的域名、路径进行加速。

同时从 HTTP 升级到 HTTP2.0，通过链路复用、数据压缩等手段，进一步提升客户端网络数据的传输效率，全面加快本次 O2O 购物节期间所有用户的数据访问，页面显示更流畅，体验更极致。

网络支撑

双 11 大促的网络保障包括公网和内网两方面：

• 公网保障，主要是指监控并规避运营商的网络波动、CDN 节点宕机自切等互联网问题的解决。
• 内网保障，主要是机房网络基础设施的保障，包括出口带宽、负载均衡压力、交换机性能等的监控，出现问题及时定位并解决。

整个网络保障的体系如下图所示，包括数据收集、故障发现、故障定位和故障处理四个方面。

01.网络数据收集

网络数据的收集需要覆盖全面，任何一点的疏忽都会形成木桶短板效应，成为大促时的风险点：

• 网络设备的性能数据，包括出口带宽、防火墙连接数和 CPU、负载均衡连接数和 CPU、交换机设备性能等。
• 服务器间延时和丢包数据，通过 Zabbix 实时探测服务器间的延时和丢包数据。
• 专线质量，苏宁 O2O 购物节时线下线上相融合，线下门店走专线回源站，专线的服务质量数据需要收集并实时分析。
• 运营商质量，各运营商的质量通过主动拨测的方式来收集，并实时展示在监控大盘上。

负载均衡设备连接数和 CPU 监控

运营商质量监控

02.故障发现和定位

系统采集的性能数据落入 Kafka，通过规则引擎的分析，判断是否已经触发了配置的告警，并通过短信和邮件的方式通知值班运维。

运维人员收到告警后，会针对不同情况进行故障定位：

对于网络设备异常、服务器之间丢包和延时的异常，需要探测设备状态、检查是否有设备自切情况。

对于出口带宽告警，需要判断是否有大量异常流量攻击。

对于运营商质量告警，需要探测运营商节点质量。比如告警发现南京联通地区有大量 TCP 连接超时异常，则运维人员会通过手动拨测的方式去检测当地运营商节点状态，定位超时是在哪一级路由造成的。

03.故障处理

以上面所说的运营商节点故障为例，因为这也是最难处理的。如果是内网网络设备的问题，自动主备切换就能解决问题。

而运营商路由节点的故障并不是我们所能控制的，当遇到这种情况，我们会通过自建 CDN 机房的全网调度系统对问题网段的用户进行调度，避开受到影响的运营商链路。

另外，对于双 11 零点的瞬时流量峰值，网络支撑层面也有成熟的应对方案。

根据业务优先级，我们会在零点到来前，加长次要业务的缓存时间，提前减少源站带宽和负载连接数。同时，设置了负载连接数阈值，超过阈值会直接限流，不会产生雪崩的情况。

服务监控

每次大促保障的重点基本都落实到服务，因为每个接口的性能，承载的业务，以及瞬间流量的冲击都是对系统的极大考验。

尤其在零点的瞬间，承接着浏览，订单，支付的具体压力，流量瞬间会增加到成百上千倍，这就要求我们在面对这样高流量的压力下，提前准备好应对的预案，在流量承接的过程中如何去发现，解决类似的问题。

所以我们就从系统如何进行容量规划来准备，通过实时监控系统来发现问题，通过调用链监控来定位解决问题。下面就从这三个方面简单的阐述我们所做的工作。

01.如何规划容量

容量规划，是一个产品满足用户目标需求而决定生产能力的过程。

当产品发展到一个较为稳定成熟的阶段，对产品的整体处理能力的把控将不可或缺，尽管我们在线下做性能测试能够获得一些数据，通过这些数据来验证我们系统所能经受的压力。

一般我们通过四个步骤来进行容量规划：

明确目标

目标的确认首先要根据历史的数据，业务发展的速度，进行一个比较准确的预估。再评估我们未来三至五年的性能与数据的增量。根据这些我们会定一个合理的目标预期值。

目标如何达成

确定好目标以后，根据系统的特点评估系统的特性，比如我们的商品详情系统就是 IO 密集性的系统。

所以在扩容的时候，我们会重点关注如何增加这方面的能力，在硬件条件受到限制的时候，优先考虑通过系统的架构进行水平扩容。

架构调整完成以后，我们也会在平时的检查中优化系统性能。

线上压测验证

通过一系列的优化工作，我们会在线上进行压测验证：

• 线上引流，将线上其他节点的请求复制到被测服务器上，推荐使用 Tcpcopy 工具。　　
• 测试数据，线上请求直接复制引流，无需准备数据。

实施步骤如下：

• 将线上一台节点 off-line，按照 Tcpcopy 部署的方法部署 client 和 server，为了便于指标的统计，通常将 Tcpcopy 部署在 nginx 所在服务器，被压测服务器前需要增加一层 nginx 服务器。
• 将集群的其他节点流量复制到 off-line 节点上，可以通过 Tcpcopy –r 参数逐步增加复制系数，不断增加 -r 参数直至超过设定的服务指标。
• 如果全部的线上流量都不能压测到 off-line 节点的瓶颈，那么就逐步放大引流系数。

监控异常

线上监控不仅用于集群历史数据的收集，计算集群的实际负荷的监控，还用于压测过程中监控约束条件中的各种指标是否超限并停止压测。

根据集群的特点和之前的性能测试经验，关注容量指标和约束条件的业务和资源指标。而这里的历史数据，是需要长期的采集和整理，进而验证与监控系统的健康状况。

02.实时的线上监控预警

准备的再多也不能百分之百保障系统不出问题，所以在应对可能出现的问题时，我们必须要在第一时间发现问题，并且制定一系列的相关措施。

以下就是我们应对日常的突发情况建立的完善流程：

• 机制，目前我们各个研发中心不仅仅有短信、微信、邮件报警，24小时值班团队在第一时间发现问题还要电话给系统负责人，进行及时反馈。
• 工具，我们会通过云际监控系统，定制我们想看到的数据，如下图。

这样不仅仅能够给我们的历史数据进行大数据对比分析，也能通过流量的监控，进行实时的预警，进而在大促期间，我们能够及时准确的预估所有潜在的风险，及时进行预案的操作。

03.调用链定位

因为有了完善的预警机制，所以我们在发现问题的时候比平时更加迅速的进入状态。

为了对线上的情况及时进行处理并且让系统快速的恢复到监控状态，我们快速的定位问题就需要了解当时发生了什么，什么地方出现了错误。

所以我们引用了调用链，因为它把用户的一次请求完整的录像下来，我们可以跟进每个画面进行判断具体在什么地方出现问题。

下面简单的介绍下调用链监控：

• 代码级定位，轻量级 Agent，采集JVM、线程、SQL，调用链路等性能指标，可分析表示层、业务层、数据层代码执行性能，给以最科学的代码优化参考。
• 侵入性低，安全稳定，对代码无侵入，对服务运行无影响，有效保障代码和数据的安全性。

因为以上的特点我们在定位问题的时候非常的省时省力，通过下图，我们可以很容易的发现系统产生的错误，而且能定位到具体那段代码产生的错误。

结束语

为了准备双十一，我们其实还有很多的工作，在这里面就不一一列举了。

短期内我们还有很多的提升空间，未来我们会更加深入的运用我们的大数据，AR 为用户提供更加个性的购物体验，结合我们的线下实体店，让用户能够深刻的了解到什么是 O2O 融合。

黄小虎

苏宁云商 IT 总部购物流程架构负责人