一、背景
我的项目介绍
励步双师课堂是以录播视频和线下中教老师联合的 AI 智能化面授教学课程。课堂中有三个角色：
- 主播老师: 视频哈佛外教老师，带着小朋友进行英文知识点的教学。次要承载“教”的职能。
- 主教老师: 次要负责疏导，陪伴，激励小朋友，组织课堂纪律，关注小朋友上课的状况，和家长进行一对一沟通等等。次要承载“育”的职能。
- 学生: 上课小朋友，2-8 岁。
目前整体的教学组织架构是以深圳研发核心示范班 + 加盟校区的形式进行教学研发、培训、惯例授课。通常新性能会先预公布到深圳示范班预授，稳固后才会公布到其余加盟校区。这样既能保障其余加盟校区稳固教学、又能疾速迭代新性能。以下一个简化的组织架构图。
上文曾经提到双师课堂是以录播的模式进行教学，必然须要课件视频。其中课件视频会经验几个流程：录制、上传、打点、审核、教学应用。晚期起步阶段只有深圳研发中示范班授课，因而课件视频存储在本地机房，在同一内网下能失常应用。随着产品逐步打磨成形，必然要落地到加盟校区应用。可是一个迫切要解决的问题摆在咱们背后：加盟校区如何获取课件视频？
要解决的几个问题：
- 一个课件视频的容量比拟大: 1-2G, 一节课的课件视频总和: 2-3G。研发核心的教研人员如何疾速上传课件视频和预览课件视频，并且反对加盟校区主播端播放线上课件视频
- 加盟校区外网环境不稳固的状况下，如何保障课件视频流畅地播放.
- 如何在研发核心示范班和加盟校区间针对课件视频做灰度公布和 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 篇）