我们若已接受最坏的，就再没有什么损失。
—— 戴尔·卡耐基
因为“停课不停学”，钉钉火了，以至于“火”到了求饶的地步，不明觉厉的请看MV：《钉钉本钉，在线求饶》。
钉钉尚且如此，假如是自建“停课不停学”系统的话……
以下，就是我对自建“停课不停学”IT系统的一些建议：
使用云服务
为了应对“在线复工”洪流的冲击，钉钉临时从阿里云扩容了十万台服务器，这样的弹性扩容规模已经不亚于“双十一”。云计算已经成为整个社会的基础设施，我们在自建“停课不停学”系统的时候没有理由不去使用。
当然，云计算不等于服务器，在构建“停课不停学”IT系统时除了云服务器，还有以下这些服务用的上：
- 视频点播、播放提前录制好的课程，在提供近乎无限的并发点播能力的同时还提供防盗链、健权、加密这些功能。
- 视频直播、通过专业直播机、PC、甚至手机实时推送视频流到云端，再通过云端分发实时视频。视频直播支持连麦功能，可以进行小规模的互动。
- 音视频通信 RTC（Real-Time Communication）、提供小范围（20人左右）的低时延互动视频和音频通讯功能，通过就近接入和遍布全球的运营商支持，可以保证全球范围内的高品质互动教学的流畅性。
- PolarDB云原生数据库、作为一个云原生数据库，PolarDB每个节点最大支持88个vCPU，710G内存，能横向扩展到16个节点，最大可提供1408核的计算能力，单个数据库可扩容到100TB，并可以结合DRDS实现多个数据库的“捆绑”。PolarDB具备5分钟增加节点的快速弹性扩容能力、可以在几十秒内完成10TB级别数据库的备份。PolarDB提供MySQL以及PostgreSQL的100%兼容能力、Oracle数据库的90%以上的高兼容能力，已经开发好的应用基本不用做修改就能使用。
压力测试
为了避免系统在万众瞩目下崩溃、出丑、有必要在上线前就对“停课不停学”系统进行压力测试，以做到心中有数。
压力测试的工具有开源的AB和JMeter、也有商业软件LoadRunner，这些都可以用，但要想更接近实际的应用场景还是建议使用阿里云PTS。
阿里云PTS通过分布在全国的CDN边缘节点可以更好的仿真实际的大并发访问场景，并支持导入开源的JMeter测试脚本。
和PTS配合使用的是ARMS，可以在进行压测的过程中对系统的运行状态进行细粒度的监控。
（上图来自阿里云官网）
ARMS是一款APM产品，支持对Java和PHP开发的服务器端应用进行接口级别的细粒度监控。通过PTS和ARMS的结合一方面可以了解高压下的系统整体性能水平，另一方面通过ARMS还可以收集应用内部的各接口之间的调用和响应数据，及时发现系统的性能瓶颈点。
优化应用架构
一旦发现系统无法满足性能指标，要进一步提高系统的并发处理能力，通常的做法有五个：
- 加缓存、为了尽可能避免数据库操作成为系统的瓶颈，可以在应用系统和数据库之间增加缓存服务，将经常需要访问的数据在缓存中保存和直接调用，降低数据库系统的压力。目前最常见的缓存服务就是Redis，在阿里云上的Redis服务有标准版、读写分离版、集群版三种，分别可以提供1万、6万、50万的最大连接。
- 异步化、假如代码之间采用直接调用耦合的方式，上游模块突然增加的流量，如果下游模块处理不及时就会将系统整个给“拖死”。可以将这样的地方改用消息中间件耦合的方式，上游模块将请求直接丢入消息队列后就直接返回以开足马力处理后续的请求，下游模块从消息队列中获取数据和指令进行后续处理，即便下游模块的处理能力跟不上新增的请求，指令和数据也只会在消息队列里堆积而不会造成系统的崩溃。阿里云的消息队列服务是经过双十一检验过的，能够承受万亿级数据流转、千万级并发、亿级消息的堆积而不影响集群的正常服务。阿里云消息队列服务MQ目前提供RocketMQ版（双十一采用）、AMPQ（RabbitMQ）、微消息队列MQTT版（物联网、活动直播），可以根据需要选择。
- 限流、假如通过压力测试可以探查出系统的最大处理能力（TPS）来，就可以依据这个数值对系统的进入流量进行限流。阿里云用于流量限流的服务叫做AHAS，可以在突发的流量洪峰到来的时候限制能够进入系统的流量，保护后端的数据库等系统免受冲击，并为系统的扩容争取时间。阿里云AHAS的接入方式有三种：不需要修改代码的Agent方式、通过Kubernetes接入、通过AHAS 的SDK接入。其中支持Agent方式的框架和应用服务器包括但不限于：Dubbo、Spring Boot、Spring MVC、String Cloud Gateway、Zull、Jetty、Tomcat、WebLogic等。
- 降级、当面临无法应对的流量时可以舍弃部分非重要功能来保障关键功能的运行正常。通过阿里云AHAS可以对不影响整体流程的第三方应用的调用应用降级规则，在异常比例超过一定的阀值时，在降级窗口时间内对第三方服务的所有请求都会快速失败。
- 隔离、有些对第三方组件或服务的调用会影响系统的整体处理流程，这时就不能对这个服务的调用进行快速失败，这时就可以使用隔离功能，阻止更多的请求进入本服务，直到堆积的请求线程处理完成。在阻止请求进入时可以根据上游应用的重要程度设置不同的资源阀值，保证核心系统能够获得更多的资源。通过AHAS的隔离规则功能可以设置当自身的线程数达到一定的阀值以后从指定应用来的请求都会快速失败。
备用的系统
无论如何，总有一些意外会发生，总有一些你没想到的原因会让系统崩溃，因此事先准备一个静态页面呈现给用户要比将系统的报错信息显示出来要好的多。对于一个“停机不停学”的IT系统，这个静态页面甚至还可以再提供一些视频的静态链接。
阿里云的OSS最适合用来做这个静态页面了。
