进来抄作业丨扩容可以解决流量激增问题？你想的太简单了！

第一波在线教育的流量高峰是在1月底，这时，很多企业把紧急扩容作为应急措施，但是后来会发现扩容也没用！这是为什么呢？又该怎么做呢？

上周五，听云联合网宿科技进行了《听你听我在线赋能团——在线教育专场》的直播，分享了这个问题的解决方案。很多小伙伴没能按时进入到直播间，或者错过直播。今天给大家整理了本场直播干货，值得收藏！以下是直播干货分享：大家好，我是听云高级客户成功经理王彬冰，今天想和大家分享一下《在线教育高可用架构建设重要环节》。现在疫情已经成为一个全球性的问题，高流量高并发可能成为一种常态。这个时候，我们必须开始重新审视现在的基础设施是否能支撑未来业务发展。下面主要分享我在高可用架构建设过程中的一些实践，主要分为以下四个部分：

架构设计
容量规划
一体化监控
常态化演练

01架构设计实现架构的可视化

要对架构进行设计，第一步一定是要对架构做可视化。一张好的架构图，应该明确系统所包含的各个组件，以及各个组件之间的调用关系。这些组件的集合，就是我们系统处理的边界，同时在一定程度上也表明了我们业务的边界。另外在故障发生的时候，我们开发人员可以根据架构图去确定问题来源，极大地缩短我们的修复时间，这些都是架构可视化的优点。有以下三种可视化方法：

手工绘制
埋点式绘制
自动化架构可视化

可视化的下一步，就是对我们的强弱依赖去进行梳理和应对。梳理强弱关系，就是对拓扑图分层，来看这个图例。

第一行用颜色标记了应用性能的好坏和告警的标识。第二行，从左到右依次是不同的层级。最左边是一个业务系统，用蜂窝的形式表示，由一个服务组构成的。服务组下面是具体的应用，应用可能会调用组件，或者是被组件调用。网络的数据、APP的数据以及页面的数据等，都可以被绘制在这张图中，同时用线条的粗细来表示吞吐率的高低。

当我们以这种层级的方式梳理后，展现在眼前的，不再是一张庞大的图形调用网络，而是3-5个业务系统。当我们发现其中一个业务系统出问题的时候，再去做下钻，从而定位具体的问题，就比较高效。

02容量规划外网仿真压测+全链路压测

做完架构可视化之后，我们就需要对具体容量做规划了，规划主要通过压测来制定。常见压测有两种类型：

外网仿真压测
全链路压测

两种压测的类型虽然不一样，但是流程其实是一样的。首先第一步就是准备架构的可视化，也就是上一章讲的内容；第二步是压测环境的准备，我们需要去复用真实的线上环境，这样测出来的问题才真实；第三步是数据的准备。我们把线上真实数据作为数据源，但是要经过采样、过滤和脱敏，并且保持同量级作为压测的数据。比如，在线教育行业，核心数据一般会有学生、教师、和课程。准备数据之后，就可以进行压测了。压测完之后，要对瓶颈进行定位，对容量进行微调。之后，一般还会进行几次压测，进一步验证容量是否可以满足预期。活动结束之后，还要对整个压测进行分析和总结，对容量做闭环，这样才是一次完整的容量规划。以上是针对直播形式的在线教育的压测流程。其实针对非直播的在线教育，还会有一个小步骤，那就是在压测之前，可以进行一次小规模的、全量的压测，也称为“预热”。

03一体化监控实现端到端数据的“监、管、控”

在大流量的冲击下，以往的小问题就会放大，监测重要性在这里就不多说了。如果没有好的监控手段，排查问题就比较麻烦。而在排查问题的时间里，你的客户很可能被其他人抢走了。在这里我列举了几个应用如果突然发生报警，可能出现的原因：

程序Bug：如代码问题导致空指针、频繁Fu‖GC等。
上游依赖出问题：上游某个接口出了问题导致本应用出现接口超时、调用失败等。
单机故障：某个容器受宿主机应用导致Load、CPU突然升高，最终导致超时、线程池满等情况发生。
中间件故障：常见的如 Cache、DB抖动导致一段时间内RT增长、超时增多。不过这里需要注意的是，单机Load高同样会引发单机读写 Cache、DB出现问题。

我们这里讲的一体化监控，包括业务监控、应用监控和系统监控。监控重要的不是“监”，而是“控”，严格来说是监、管、控三大部分。下面是听云的一个应用性能的架构图。

我们通过打探针、非嵌入的方式可以采集到用户数据，但是这样直接采集到的大量的数据是没有意义的，数据只有在被分析后才有意义。那如何做到管理数据呢？方式就是告警➕大屏，两者作用都是对数据聚焦，如图所示。

告警平台主要分为两种：

自研告警平台
第三方告警平台

不管哪种方式的告警，告警阈值才是关键。如果设置过高，会有漏报的现象，但是如果设置过低，就会产生大量无效告警。而且告警阈值应该是一个动态的，因为应用性能不是一成不变的。而AI告警可以解决这个问题，它可以基于数据的变化，自动计算阈值，能极大的提升准确率并减少工作量。

借助大屏，可以展示整体的业务数据和性能数据，帮助工作人员宏观地掌握应用性能。这里再分享一个监控直播卡顿的方法，这个方法来自一个用户，非常简单粗暴，但是很有效。在直播的时候，这个用户会提取弹幕或者留言区里面的关键字，比如说：“卡”、“卡了”、“看不见”、“听不见”等，当这些关键词到一定数量的时候，他就去调整直播的线路，结果很有效果，几乎不需要外部的报警了。但是很多人都知道，即使是用了智能告警，告警的数量还是会比较多，这时候就需要用到告警收敛。告警收敛首先需要两个能力，一个是数据采集能力，一个是告警收敛能力。如图所示：

告警收敛听起来很简单，但是要达到高收敛比和准确性，还是很困难的，而且即使做了收敛，可能还是达不到理想的效果。比如一周有5000个告警，我们的收敛比为90%（已经很高了），那还剩下500个告警。500个告警还是很多的。我们理想状态为，5000个告警收敛为1-2个告警。那告警收敛就需要具备第三个能力：根因分析。根因分析可以帮助归类剔除有关联性的一系列告警。

“控”就是通过各种手段解决问题。

04常态化演练

传统测试无法覆盖客户端负载均衡、微服务容错保护、API服务网关、分布式链路跟踪等特性，同时也无法模拟例如网络延迟、CPU满载、请求异常、依赖故障、硬件故障等场景。如果想要构建一个高可用性架构，仅仅用常规测试是不够的。而混沌工程以实验的方式，尽早揭露系统的弱点。它更像是一种探索性的测试，试验本身没有明确的输入和结果，而是通过一种混乱的方式对系统进行干预，去发现能力的边界。以上就是所有直播内容重点干货，经过以上四个步骤，相信我们的系统性能会得到很大提升。下图是听云智能业务感知平台，一站式具备以上提到的架构设计、容量规划、一体化监控能力，帮助提升用户体验。