Serverless在编程教育中的实践

说起Serverless这个词 , 我想大家应该都不陌生 , 那么Serverless这个词到底是什么意思?Serverless到底能解决什么问题?可能很多朋友还没有深刻的体会和体感 , 这篇文章我就和大家一起聊聊Serverless 。
什么是Serverless我们先将Serverless这个词拆开来看 。 Server , 大家都知道是服务器的意思 , 说明Serverless解决的问题范围在服务端 。 Less , 大家肯定也知道它的意思是较少的 。 那么Serverless连起来 , 再稍加修饰 , 那就是较少的关心服务器的意思 。
Serverfull时代我们都知道 , 在研发侧都会有研发人员和运维人员两个角色 , 要开发一个新系统的时候 , 研发人员根据产品经理的PRD开始写代码开发功能 , 当功能开发、测试完之后 , 要发布到服务器 。 这个时候开始由运维人员规划服务器规格、服务器数量、每个服务部署的节点数量、服务器的扩缩容策略和机制、发布服务过程、服务优雅上下线机制等等 。 这种模式是研发和运维隔离 , 服务端运维都由专门的运维人员处理 , 而且很多时候是靠纯人力处理 , 也就是Serverfull时代 。
DevOps时代互联网公司里最辛苦的是谁?我相信大多数都是运维同学 。 白天做各种网络规划、环境规划、数据库规划等等 , 晚上熬夜发布新版本 , 做上线保障 , 而且很多事情是重复性的工作 。 然后慢慢就有了赋能研发这样的声音 , 运维同学帮助研发同学做一套运维控制台 , 可以让研发同学在运维控制台上自行发布服务、查看日志、查询数据 。 这样一来 , 运维同学主要维护这套运维控制台系统 , 并且不断完善功能 , 轻松了不少 。 这就是研发兼运维的DevOps时代 。
Serverless时代渐渐的 , 研发同学和运维同学的关注点都在运维控制台了 , 运维控制台的功能越来越强大 , 比如根据运维侧的需求增加了自动弹性扩缩、性能监控的功能 , 根据研发侧的需求增加了自动化发布的流水线功能 。 因为有了这套系统 , 代码质量检测、单元测试、打包编译、部署、集成测试、灰度发布、弹性扩缩、性能监控、应用防护这一系列服务端的工作基本上不需要人工参与处理了 。 这就是NoOps , Serverless时代 。
Serverless在编程教育中的应用2020年注定是不平凡的一年 , 疫情期间 , 多少家企业如割韭菜般倒下 , 又有多少家企业如雨后春笋般茁壮成长 , 比如在线教育行业 。
没错 , 在线教育行业是这次疫情的最大受益者 , 在在线教育在这个行业里 , 有一个细分市场是在线编程教育 , 尤其是少儿编程教育和面向非专业人士的编程教育 , 比如编程猫、斑马AI、小象学院等 。 这些企业的在线编程系统都有一些共同的特点和诉求:
屏幕一侧写代码 , 执行代码 , 另一侧显示运行结果 。 根据题目编写的代码都是代码块 , 每道题的代码量不会很大 。
运行代码的速度要快 。 支持多种编程语言 。 能支撑不可预计的流量洪峰冲击 。
例如小象学院的编程课界面:
Serverless在编程教育中的实践文章插图
结合上述这些特点和诉求 , 不难看出 , 构建这样一套在线编程系统的核心在于有一个支持多种编程语言的、健壮高可用的代码运行环境 。
那么我们先来看看传统的实现架构:
Serverless在编程教育中的实践文章插图
从High Level的架构来看 , 前端只需要将代码片段和编程语言的标识传给Server端即可 , 然后等待响应展示结果 。 所以整个Server端要负责对不同语言的代码进行分类、预处理然后传给不同编程语言的Runtime 。 这种架构有以下几个比较核心的问题 。
工作量大 , 灵活性差
首先是研发和运维工作量的问题 , 当市场有新的需求 , 或者洞察到新业务模式时需要增加编程语言 , 此时研发侧需要增加编程代码分类和预处理的逻辑 , 另外需要构建对应编程语言的Runtime 。 在运维侧需要规划支撑新语言的服务器规格以及数量 , 还有整体的CICD流程等 。 所以支持新的编程语言这个需求要落地 , 需要研发、运维花费不少的时间来实现 , 再加上黑/白盒测试和CICD流程测试的时间 , 对市场需求的支撑不能快速的响应 , 灵活性相对较差 。
高可用自己兜底
其次整个在线编程系统的稳定性是重中之重 。 所以所有Server端服务的高可用架构都需要自己搭建 , 用以保证流量高峰场景和稳态场景下的系统稳定 。 高可用一方面是代码逻辑编写的是否优雅和完善 , 另一方面是部署服务的集群 , 无论是ECS集群还是K8s集群 , 都需要研发和运维同学一起规划 , 那么对于对编程语言进行分类和预处理的服务来讲 , 尚能给定一个节点数 , 但是对于不同语言的Runtime服务来讲 , 市场需求随时会变 , 所以不好具体衡量每个服务的节点数 。 另外很重要的一点是所以服务的扩容 , 缩容机制都需要运维同学来实时手动操作 , 即便是通过脚本实现自动化 , 那么ECS弹起的速度也是远达不到业务预期的 。