此次疫情持续时间长，范围广。为了不影响广大中小学生的学习，教育部门提出了停课不停学的口号。广大教育信息化企业、互联网公司也纷纷响应，以支持学校线上教学为实际行动，为抗击疫情出一份力。春节后，各家公司工程师均动员起来，在家远程办公，纷纷对现有系统进行优化，该扩容的扩容，该调整的调整，以应对2月10日开学第一堂的到来。
2月10日早晨，全国上下的在线学习活动，均成为了各家公司的车祸现场。学生们过五关斩六将也没能很好的完成上午的学习任务。学生们遇到的问题从登录，进入直播间到直播信号延迟卡顿。
9点之后，各家的系统均陆续出现崩溃，各公司也纷纷祭出重启大法并寻找甩锅方案（比如甩给电信运营商）。各家公司的系统均在崩溃的边缘紧张度过了一上午。教育机构在遇到这种万（yu）万（liao）没（zhi）想（zhong）到的问题后，将学习形式切换为点播方案，这才令各路公司的工程师们长出了一口气。
那么，都2020年了，国内的互联网企业早已经历了618，双11，春节红包等高并发场景的历练，为何还纷纷撞车呢？我们先分析下当前教育机构采用的在线学习的几种产品架构形态。不同的产品架构形态在这次事件的问题根源是各不相同的。
学校自建平台
这类平台一般采用校内学习平台加云直播服务的架构方案。校内部署的平台要考虑部署成本和研发成本，绝大多数都采用单应用服务器+单数据库的架构方案。比较有实力的学校还会升级为7层负载服务，多应用服务，redis缓存，数据库主从这种相对健壮的系统。
学校自建平台有好处也有弊端。好处是自己相对可控，因为用户就是自己学校的学生和教师，可以根据年级进行错峰上课，避免大流量的冲击。一般只要学校的系统能经历过选课等服务的实际使用，再通过错峰学习，基本可以扛过这次事件。弊端就是如果前期没有经过实际的大规模应用，学校平台建设完成后只是少量的应用，没有经历过全校范围的实际应用，那么在这次在线学习过程中，只能是硬挺，多半都度过不了学生登录的环节。
这类系统架构在本次事件中最大的问题就是水平扩容能力几乎为0。受限于学校的物理环境，不是短时间能马上扩容的。也就只有非常有实力的学校，才会储备一些冗余的计算资源，在此次关键时刻发挥其作用。
区县级教育云平台
区县级平台一般都部署在区县教育机构的自建数据中心内，16年后期也有在政务云上申请私有云进行部署的。此类在线学习平台的架构方案一般都是我们耳熟能详的典型互联网架构。
硬负载均衡->软负载->API网关->微服务->分布式缓存->数据库读写分离
按理这套架构应该没有问题，扩容也相对容易，但是现实情况确是很残酷的。原因我们会在后面重点讨论。
教育信息化公司的在线学习云平台
此类平台的典型运营公司如希沃等，学校购买其在线学习服务。这类平台的架构也是非常典型的互联网架构方案。
该架构方案除了：接入层负载->7层负载->API网关->微服务->分布式缓存-分布式数据库外，还会增加配置管理、日志收集、报警监控，数据查询异构等。
粗略一看，这套架构跟阿里京东等电商公司的是基本类似的，就算支撑不了像双11这样的QPS，经过扩容后也应该能撑过这次在线学习吧，毕竟全国的学生不是都在一个云平台里学习的。这个原因我们也会在后面重点讨论。
互联网公司的学习平台
此次在线学习，阿里和腾讯作为互联网界的担当，也承担起了为社会提供在线学习服务的责任。这两家公司的学习平台，均是基于中台进行搭建的。其架构有各自公司的独特背景，因此不在本文的讨论范围之内。
但在线上教学过程中，大部分直播课程都出现延迟卡顿现象。究其原因，主要是地主家也没有余粮了。当前是远程办公的高使用时期，钉钉微信是各个公司远程办公的主要工具，阿里腾讯的直播带宽受限于接入运营商，也无法短时间扩容数倍。
下面我们回归主题，重点讨论下区县云平台及教育信息化公司的在线学习平台的问题原因。
幸福的人生是相同的，不幸福的人生各有各的不同。我主要是从架构宏观角度去推测此次问题的产生原因。
问题一：盲目扩容
从春节到现在，在朋友圈中可以不断看到教育信息化公司的朋友们在发本公司的研发人员加班扩容的内容。
扩容方案不外乎对以下几个环节进行扩容：
1. 接入层扩容。对接入带宽进行扩容，增加带宽，满足更多的请求所带来的数据量激增。
2. 网关及应用层扩容。由于几乎都是微服务架构，应用层可以说是最方便的扩容点。通过对应用层扩容，系统可以同时响应更多的请求。
3. 资源层扩容。资源层包括redis缓存、数据库，hbase，ES等各类数据存储资源。本层的扩容有两个途径。一个是增加计算资源，例如增加数据库的MySQL核数，另外一个是增加分片数量。
扩容是面对激增请求的必要手段，但是如果面对增加一个数量级左右的请求时，就不能是简单的进行如上扩容就可以解决了。
接入层对一般教育信息化公司相对容易一些，毕竟总带宽不高，从几G增加到几十G对于现在的IDC运营商来讲，也不是太难的事情。
应用层扩容，也相对容易，现在的互联网基础中间件已经足够完善，扩容个几倍也是可以掌控的。
资源层出问题了。前面几层把请求都接收过来了，都在期盼资源层的服务也能抗过去，但是资源层不仅是增加计算核心，还有连接数瓶颈，IO瓶颈等一系列问题。有人说，第二种对资源层的分片增加可以缓解上面的问题呀。是的，但这是一厢情愿的。在系统设计时，如果没有经过很好的分片策略分析，热点数据侧倾到一个或几个分片上，还是会出现上述的资源层瓶颈问题。
一旦资源层的服务响应时间过长，会造成应用层对外的请求响应失败，重试请求会继续涌入，当数个应用服务因过量请求阻塞后，外部请求会落入其余应用服务上，于是乎，风卷残云一般引起雪崩效应，所有服务就都挂了。
扩容，不仅是计算资源的堆积。扩容完毕后，一定要有完备的全流程压测体系支持，否则扩容就会变成增加我们必胜的口号而已。
问题二：限流降级流于形式
没有哪个互联网公司的研发人员会承认自己不会做限流和降级。但是，这个事情往往都流于形式了。
限流降级本身是两个不同的技术点，但是限流就是有损服务，有损服务又必须有良好的降级方案去应对。
限流从接入层到资源层都需要面对。每一层都需要根据计算资源的配置情况和前期压测情况通过仔细斟酌来设定限流方案，而不是仅仅看本层服务的计算资源数量，一拍脑袋的就设置了一个值。这种值过于保守会形成瓶颈点，稍微大一点，又容易在极高流量的情况下被摸死。
降级更是需要在系统架构设计之初就需要考虑。降级不仅仅是服务出现故障时的托底方案，更是要跟业务方一同商量的业务范畴的降级手段。比如说直播间必须在前24小时建好，课件资源不允许即时修改等。
如果要有良好的限流降级方案，此次云平台服务商应该不会如此不堪冲击。
教育信息化公司要想解决上述问题，面临的难点我认为有如下：
1. 基础平台搭建困难
没有过硬的基础平台体系，想获得稳定的产品基本是空中楼阁。稳定的基础平台是需要时间积淀，不断趟坑才能获得的。不过好在有阿里云等各类云平台服务商，他们提供相对完备的解决方案。建议还在IDC机房自建的中小公司尽快上云。
2. 专业的架构师团队
专业的架构师团队是核心，否则所有的架构只沦落为皮毛，没有跟公司的自身业务融合在一起。不过尖端的架构师基本都被头部互联网公司争抢，如何获得这方面的人才是所有教育信息化公司需要考虑的事情。
3. 研发及运维成本
满足高并发的架构必然带来极高的研发成本以及运营成本。公司如何平衡并发量以及研发成本直接的关系，就是教育信息化公司的决策者们自己要考虑的事情了。
这次停课不停学，不仅是教育信息化企业的试金石，也是在线教学平台验证其架构师团队的试金石。高并发不仅是架构方案的模仿以及想当然的扩容，它需要架构与业务的深度结合、认真的压测准备以及团队的整体意识提升。
双11等活动倒逼电商公司技术的技术提升，也希望这次停课不停学能帮助各企业直面架构问题，并提升团队技术能力。
黄海感悟：
此文为业内专家所写，分析的十分到位清楚。难点的三大解决思路非常正确，各教育服务公司还都停留在业务系统提供层面上，无论在技术的积累，还是投入上都是十分有限或干脆没有。专业的架构师团队,长春的几家大型软件公司中，我知道的嘉诚、启明等级别的是有这个概念有这个层次的，对于我司来讲，概念上认为所有研发人员是一样的，不存在职能分别，就是要一个全栈式工程师，从需求调研，设计，开发，运维，一路到底，可以想象的出，我们的工程师哪个方面能有深入的研究，我司要想在新的一轮竞赛中保持优势，应该在公司高层领导思路上有整体的认识，在高层技术上投入人力，储备技术，给研发人员多一些时间，不断的优化代码，进行代码，而不是到期完成发绩效，到期不完成扣钱，这样都能到期完成，但质量实在是惨不忍睹。坑踩了一次，就不要再踩一次。