一、背景

我的项目介绍

励步双师课堂是以录播视频和线下中教老师联合的 AI 智能化面授教学课程。课堂中有三个角色：

  • 主播老师: 视频哈佛外教老师，带着小朋友进行英文知识点的教学。次要承载“教”的职能。
  • 主教老师: 次要负责疏导，陪伴，激励小朋友，组织课堂纪律，关注小朋友上课的状况，和家长进行一对一沟通等等。次要承载“育”的职能。
  • 学生: 上课小朋友，2-8 岁。

目前整体的教学组织架构是以深圳研发核心示范班+加盟校区的形式进行教学研发、培训、惯例授课。通常新性能会先预公布到深圳示范班预授，稳固后才会公布到其余加盟校区。这样既能保障其余加盟校区稳固教学、又能疾速迭代新性能。以下一个简化的组织架构图。

上文曾经提到双师课堂是以录播的模式进行教学，必然须要课件视频。其中课件视频会经验几个流程：录制、上传、打点、审核、教学应用。晚期起步阶段只有深圳研发中示范班授课，因而课件视频存储在本地机房，在同一内网下能失常应用。随着产品逐步打磨成形，必然要落地到加盟校区应用。可是一个迫切要解决的问题摆在咱们背后：加盟校区如何获取课件视频？

要解决的几个问题：

  1. 一个课件视频的容量比拟大: 1-2G, 一节课的课件视频总和: 2-3G。研发核心的教研人员如何疾速上传课件视频和预览课件视频，并且反对加盟校区主播端播放线上课件视频
  2. 加盟校区外网环境不稳固的状况下，如何保障课件视频流畅地播放.
  3. 如何在研发核心示范班和加盟校区间针对课件视频做灰度公布和A/B测试

在这样背景下，蒲公英公布平台在外部开始推动。总得来说大略经验3个阶段:

  • 阶段1: 课件视频从 “研发核心本地机房” => “云端OSS”
  • 阶段2: 课件视频从 “研发核心本地机房” => “云端OSS” => “校区机房”
  • 阶段3: 教学资源从 “研发核心本地机房” => “云端OSS” => “公布平台(治理)” => “校区机房”

   

二、蒲公英总体架构图

上方是蒲公英的总体架构图。最上层是现阶段反对的公布资源类型：课件视频/图片、APP安装包、页面动态资源、互动多媒体资源、docker镜像、脚本文件、Nodejs扩大库DLL等

下半局部是云端和校区的零碎:

  • CMDB：治理校区资产信息。蒲公英将公布的资源和cmdb的资产信息(校区城市、分校、教室、教学设备、校区服务器)关联一起.
  • 版本治理：记录各终端应用的各类资源的以后版本号、历史版本、版本升级依赖.
  • 公布平台：后盾零碎，负责资源的手动公布、主动公布、灰度公布、回滚等公布策略
  • Mercedes Server: 负责接管上游公布平台的资源散发音讯、转发音讯给相应校区节点的Agent服务
  • Beetle: 负责上传资源/下载资源
  • Talgate：负责Mercedes Server和所有校区节点Agent服务地注册，会话连贯治理，音讯通信等
  • Mercedes Agent: 负责接管Server的散发音讯、调度Beetle从云端OSS下载资源、同校区两台服务器的资源同步
  • Cadillac: 负责承受校区教室主播端拜访内网资源申请、校区教学服务的api gateway.

三、起源

痛点：课件视频文件很大，教研老师上传视频工夫长、上传过程呈现网络稳定或者敞开页面需从新上传。课件打点审核通过后，如何疾速提供给示范班应用。

解法：

  • 课件零碎是一个提供给教研老师制作课件、治理课件的后盾零碎。它是一个BS架构的WEB零碎，上传文件的形式是通过http直传，上传过程中一旦有中断，只能从新上传， 这样大大降低教研老师工作效率。通过调研决定采纳tus协定实现断点续传上传大文件。tus协定是一种基于HTTP/1.1和HTTP/2机制用于文件断点续传。这里画了一个大抵上传流程图，具体内容请查看tus官网文档(https://tus.io/)。

  • 教研老师上传课件后，还需通过审核员预览、审核通过后能力交付使用。因而思考能够先上传到研发核心的资源服务器，因为是在同一个内网环境，不须要通过外网，这样放慢了上传速度。待课件经审核员审核通过后，再经由资源服务器上传到云端OSS。
  • 课件视频上传问题曾经解决了。但加盟校区的主播端播放视频的优化计划还未到位，思考到示范班和加盟校区想尽早应用，火线业务不能耽误的状况下。咱们评估了走外网播放视频计划的可行性：校区教学网络外接两条电信线路上网，一条为30M专线网络，一条为200M拨号光纤。互为备份，防止复线故障。咱们在研发核心模仿校区的理论网络带宽，应用10台PC 通过有线网卡，同时播放视频，通过监控防火墙进口流量峰值、查看cacti 流量实时情况，并理论在PC 体验视频播放的晦涩度

测试后果：流量上行峰值为173.8M，平均值为50M。 流量上行峰值为5M. PC播放视频的理论体验成果不错，晦涩度良好.

就这样这套计划安稳地帮咱们过滤到下一个阶段。

上面给出晚期版本的简化架构图:

相应的简化流程：课件 => 断点续传 => 在线预览播放 => 审核通过，触发上传工作 => 异步上传到oss => 主播端播放课件视频

落地成果：根本满足晚期业务需要

四、资源散发

痛点：各校区当地外网环境无奈100%保障全天候稳固，主播端在线播放课件视频呈现卡顿、加载中景象。极其状况下影响失常授课。

解法：课件资源如果在授课前曾经存储在校区的服务器、开始授课时主播端只须要从内网拉取资源，这样就不依赖于外网环境。源着这个思路开始构思一个异地多校的资源散发零碎。

Q：资源散发零碎的云端Server和分校节点Agent如何端到端的实时通信?

A：复用双师教学系统的长连贯网关服务Talgate，各个节点(server, agent)须要先往网关核心Talgate注册，建设长连贯数据通道。

Q：如何保障长连贯通信单方音讯不失落?

A：ACK+ 超时重传 + 去重

  • Server推送音讯时，携带一个标识 SID，推送出音讯后会将以后音讯增加到“待 ACK 音讯列表”。Agent胜利接管音讯后，会给Server回一个业务层的 ACK 包，包中携带有本条接管音讯的 SID。Server接管后，会从“待 ACK 音讯列表”记录中删除此条音讯。【ACK】
  • 如果Agent接管不到音讯，Server的“待 ACK 音讯列表”会保护一个超时计时器，肯定工夫内如果没有收到Agent的 ACK 包，会从“待 ACK 音讯列表”中从新取出那条音讯进行重推。【超时重传】
  • 如果Agent接管到音讯了，but ACK包丢了，导致Server重传音讯，可能会让Agent收到反复的音讯，这时Agent须要依据SID来进行业务层的去重。 【去重】

  

Q：Server或者Agent宕机可能导致重传生效。下一次从新连贯上，Agent之前有若干条音讯失落，怎么办?

A：Server须要进行完整性检查，利用“工夫戳比对”机制，发现Agent“有音讯失落”的状况，能够从新同步失落的数据。

  • Server给接管方Agent推送 task1，顺便带上一个最新的工夫戳 timestamp1，接管方 Agent 收到 task1 后，更新本地最新消息的工夫戳为 timestamp1。
  • Server推送第二条音讯 task2，带上一个以后最新的工夫戳 timestamp2，task2 在推送过程中因为某种原因接管方 Agent 和 Server连贯断开，导致 task2 没有胜利送达到接管方 Agent。
  • Agent 从新连上Server，携带本地最新的工夫戳 timestamp1，Server将Agent 暂存的音讯中工夫戳大于 timestamp1 的所有音讯返回给Agent，其中就包含之前没有胜利的 task2。
  • Agent 收到 task2 后，更新本地最新消息的工夫戳为 timestamp2。通过工夫戳机制，Agent 能够胜利地让失落的 task2 进行弥补发送。 

  

Q: 校区Agent收到工作后，开始从云端OSS下载资源，如何防止反复下载，下载资源失败怎么办?

A：Beetle是上传/下载服务组件，部署在校区，负责接管Agent的下载指令，执行理论的从云端下载资源文件的工作。

  • Beetle先从本地文件列表查看文件是否曾经下载或者下载中，若曾经下载则返回胜利，若正在下载中则返回下载中，否则执行下一步。
  • Beetle计算待下载文件大小 查看是否大于 可用容量(磁盘残余容量-下载中文件大小)，若大于的状况，当初计划是返回失败。后续迭代计划是给资源文件按等级、文件大小做加权值，优先下载权值高的文件。
  • Beetle对于大文件的下载，按断点续传下载文件，若呈现网络不稳固下载失败，依据配置文件的重试次数，执行重试机制。若重试后有效，返回失败。
  • Agent收到下载失败后果，更新散发工作状态为“下载失败”，告诉Server工作失败。并触发告警到品质监控平台。

  

Q: 如果校区存储资源的一台服务器呈现故障，如何保障资源失常加载？

A：每个校区部署两台服务器，应用LVS做主机冗余，防止一台机器宕机，呈现单点故障。

  • Mercedes Server依据校区节在网关注册的先后顺序选举Master，先给校区Master 服务器A发送散发工作，服务器A实现资源散发后，需同步资源给Slave服务器B。
  • 应用类Rsync+Sesync的机制实现服务器文件双向同步，单方比对文件列表，若发现缺失则同步资源。
  • 如果服务器A呈现故障无奈应用，服务器B被选举为Master，接管资源散发工作，待故障机器A复原后，服务器B查看是否有新资源要同步给服务器A， 有则同步资源。

Q: 如果资源没有及时散发到校区节点，如何保障主播端失常加载资源？

A：每个校区的网关服务Cadillac提供查问课件资源文件URL，Cadillac会查看资源文件是否公布，如果公布则返回内网URL地址，若未公布则返回外网URL地址。

另外防止一些误操作导致曾经公布的资源失落的状况，而无奈提前发现，建设了一套预警机制：Cadillac每晚11点会查问往后7天所有校区课表的课件资源URL列表，通过http head办法批量查看资源是否存在于内网，若不存在则触发告警、流转到品质监控报警平台。

Q: 如果校区两台服务器都呈现硬件故障或者长时间断电的状况下，如何保障主播端失常加载课件资源？

A：主播端当被动探测到校区内网服务器无奈工作后，主动切换到外网拜访云端服务，加载外网课件资源。

上面给出相应的简化架构图：

相应的简化流程：课件 => 断点续传 => 在线预览播放 => 审核通过，触发上传工作 => 异步上传到oss  => Mercedes Server创立课件散发工作 => 选取指定校区的Master服务器、给它发送工作 => Mercedes Agent接管到工作、记录工作、给Beetle发送下载工作、Beetle接到工作、记录下载工作、下载课件 => 校区服务器双向同步资源 => 内网不可用时切换到外网.

落地成果：课件资源不依赖外网环境，主播端失常播放课件视频，进步教学系统的可用性。

五、多类型资源散发、版本治理

痛点：现有课件散发策略粒度比拟粗，仅反对主动散发到所有校区。 一旦课件内容有问题，必将影响所有校区的失常教学。

解法：搭建对立公布平台，买通上游业务零碎、CI/CD零碎和上游资源散发零碎。治理资源版本号、公布记录、制订按城市、校区、版本三个维度的公布策略。监控公布流程，呈现失败的工作触发告警。

Q: 蒲公英公布平台除了反对课件视频公布外，也反对包含互动多媒体资源、安装包、Nodejs扩大库DLL、页面动态资源、脚本文件、Docker镜像等多种类型资源的公布。不同类型资源是否有共性，能不能形象成通用的一种资源，实现对立治理？

A：多种类型资源都有一些必要的属性：类型、公布源、版本号、文件名称、文件大小、文件寄存OSS地址、MD5值、创立工夫等，由此能够形象成：“资源”、“公布工作”、“公布策略”、”公布工作历史“ 四个实体对象组成蒲公英的根底单元。

Q：其余类型资源的散发形式是否跟课件资源一样：由蒲公英被动推送散发工作给校区节点，再由校区Agent执行下载资源操作？

A：对于主播端、主教端、电子班牌、手表这类安装包，须要客户端执行下载安装操作。显然无奈保障客户端24小时在线，蒲公英有公布工作时，很大概率是客户端不在线或者正在授课应用中，无奈实时降级。因而被动承受公布工作的形式不适用于客户端降级。所以蒲公英须要提供接口给客户端查看是否有新版本更新，由客户端定期检查和执行降级。另外思考到所有客户端都是运行在校区内，为了缩小外网环境的依赖，大文件的安装包先散发到校区服务器，再由校区网关Cadillac提供版本更新接口，进步客户端降级成功率。

相应的简化流程：课件 => 断点续传 => 在线预览播放 => 审核通过，触发上传工作 => 异步上传到oss => 创立课件散发工作 => 蒲公英公布 => 选取指定校区的Master服务器、给它发送工作 => Mercedes Agent接管到工作、记录工作、给Beetle发送下载工作、Beetle接到工作、记录下载工作、下载课件 => 校区服务器同步资源 => 内网不可用、切换外网.

落地成果：蒲公英对立公布平台上线1个月左右来共公布250+个课件、1000+个互动多媒体资源、20+次客户端版本（主播端、主教端、手表）降级。

六、将来布局

继续优化各服务组件，优化零碎应用交互体验，优化用户角色权限 ，解藕业务侧逻辑，解藕部署环境的依赖，引入多租户的组织构造，凋谢能力给团体其余搭档应用。

七、经验总结

从技术架构角度来说，励步双师教学系统是一个异地多校的分布式架构，它复杂度起源次要包含：高可用，可扩展性。这里次要介绍了分布式资源散发（蒲公英）平台的架构演进过程，基于业务倒退阶段，别离引入资源散发、资源双备、版本治理，灰度公布等性能。
招聘信息

好将来技术团队正在热招前端、算法、后盾开发等各个方向高级开发工程师岗位，大家可点击本公众号“技术招聘”栏目理解详情，欢送感兴趣的搭档退出咱们！

兴许你还想看

DStack--基于flutter的混合开发框架

WebRTC源码剖析——视频流水线建设（上）

"考试"背地的迷信：教育测量中的实践与模型（IRT篇）