想了解一个异地多校平台的架构演进过程吗？ 让我来告诉你！

1、背景

项目介绍

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

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

目前总体的教学组织架构是以深圳研发中心示范班+加盟校区的方式进行教学研发、培训、常规授课。一般新功能会先预发布到深圳示范班预授，稳定后才会发布到其余加盟校区。这样既能保证其余加盟校区稳定教学、又能快速迭代新功能。如下一个简化的组织架构图。

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

要解决的几个问题：

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

在这样背景下，蒲公英发布平台在内部开始推动。总得来讲大概经历3个阶段:

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

   

2、蒲公英整体架构图

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

下半部分是云端和校区的系统:

• CMDB：管理校区资产信息。蒲公英将发布的资源和cmdb的资产信息(校区城市、分校、教室、教学设备、校区服务器)关联一块儿.
• 版本管理：记录各终端使用的各种资源的当前版本号、历史版本、版本升级依赖.
• 发布平台：后台系统，负责资源的手动发布、自动发布、灰度发布、回滚等发布策略
• Mercedes Server: 负责接收上游发布平台的资源分发消息、转发消息给相应校区节点的Agent服务
• Beetle: 负责上传资源/下载资源
• Talgate：负责Mercedes Server和全部校区节点Agent服务地注册，会话链接管理，消息通讯等
• Mercedes Agent: 负责接收Server的分发消息、调度Beetle从云端OSS下载资源、同校区两台服务器的资源同步
• Cadillac: 负责接受校区教室主播端访问内网资源请求、校区教学服务的api gateway.

3、起源

痛点：课件视频文件很大，教研老师上传视频时间长、上传过程出现网络波动或者关闭页面需从新上传。课件打点审核经过后，如何快速提供给示范班使用。

解法：

• 课件系统是一个提供给教研老师制做课件、管理课件的后台系统。它是一个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 => 主播端播放课件视频

落地效果：基本知足早期业务需求

4、资源分发

痛点：各校区当地外网环境没法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接到任务、记录下载任务、下载课件 => 校区服务器双向同步资源 => 内网不可用时切换到外网.

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

5、多类型资源分发、版本管理

痛点：现有课件分发策略粒度比较粗，仅支持自动分发到全部校区。 一旦课件内容有问题，必将影响全部校区的正常教学。

解法：搭建统一发布平台，打通上游业务系统、CI/CD系统和下游资源分发系统。管理资源版本号、发布记录、制定按城市、校区、版本三个维度的发布策略。监控发布流程，出现失败的任务触发告警。

Q: 蒲公英发布平台除了支持课件视频发布外，也支持包括互动多媒体资源、安装包、Nodejs扩展库DLL、页面静态资源、脚本文件、Docker镜像等多种类型资源的发布。不一样类型资源是否有共性，能不能抽象成通用的一种资源，实现统一管理？

A：多种类型资源都有一些必要的属性：类型、发布源、版本号、文件名称、文件大小、文件存放OSS地址、MD5值、建立时间等，由此能够抽象成：“资源”、“发布任务”、“发布策略”、”发布任务历史“ 四个实体对象组成蒲公英的基础单元。

Q：其余类型资源的分发方式是否跟课件资源同样：由蒲公英主动推送分发任务给校区节点，再由校区Agent执行下载资源操做？

A：对于主播端、主教端、电子班牌、手表这类安装包，须要客户端执行下载安装操做。显然没法保证客户端24小时在线，蒲公英有发布任务时，很大几率是客户端不在线或者正在授课使用中，没法实时升级。所以被动接受发布任务的方式不适用于客户端升级。因此蒲公英须要提供接口给客户端检查是否有新版本更新，由客户端按期检查和执行升级。另外考虑到全部客户端都是运行在校区内，为了减小外网环境的依赖，大文件的安装包先分发到校区服务器，再由校区网关Cadillac提供版本更新接口，提升客户端升级成功率。

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

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

6、将来规划

持续优化各服务组件，优化系统使用交互体验，优化用户角色权限 ，解藕业务侧逻辑，解藕部署环境的依赖，引入多租户的组织结构，开放能力给集团其余伙伴使用。

7、经验总结

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

好将来技术团队正在热招前端、算法、后台开发等各个方向高级开发工程师岗位，你们可点击本公众号“技术招聘”栏目了解详情，欢迎感兴趣的伙伴加入咱们！

也许你还想看

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

WebRTC源码分析——视频流水线创建（上）

"考试"背后的科学：教育测量中的理论与模型（IRT篇）