项目背景

laughing168 2022年02月21日 945 0

几年前，很多人对网络课程并不熟悉。随着移动设备的普及和音视频技术的发展，现在在线教育产品已经百花齐放。在线教育产品可以在没有流媒体分发技术支持的情况下服务成千上万的学生。这个LiveVideoStackCon

2021音视频技术大会北京站邀请了网易有道的R&D工程师周啸天为我们分享网易有道在线教育业务的流媒体分发相关内容。

大家好，我是网易有道精品课程研发团队的。如今，音视频已经引起了社会各界的广泛关注，“Live Plus”成为热点。大型厂商也推出了一系列音视频相关服务。

网易是一家智能学习公司，使命是实现学习者的“高效学习”。依托强大的互联网AI等技术手段，网易围绕学习场景构建了一系列深受用户欢迎的学习产品和服务。除了各种场景的在线教育平台，还有有道词典、有道词典笔等领先市场的软硬件学习工具。

音视频技术内容面广，链条长，每个点都会很深。所以今天分享的内容以有道的在线教育业务为主题，重点介绍有道的流媒体分发服务器。

今天的内容分为三个部分，分别是有道在线教育业务介绍、分发系统架构演进和分发难点的思考与实践。

不同的阶层对应不同的需求。2013年左右，1V1课程和普通小班首次出现。本质上是借助RTC实时交流模式搭建的教育产品。后来的游戏直播和娱乐大家都比较熟悉，而现阶段大家熟知的在线学习的主要形式就是VOD模式，比如网易公开课。随着音视频技术的成熟和用户对在线教育需求的升级，在线直播课程发展迅速。直播课大约出现在2014年，疫情过后受到了前所未有的关注。

传统的大班直播课是老师单向推送。在互动大班中，学生可以进一步与老师互动，获得更好的课堂体验。一堂课的主要内容包括学生教学、屏幕/白板、教师视频和互动信息。

互动小课堂进一步优化了产品的互动性，提升了学生的课堂参与感、学习体验和学习效果。音频和视频+H5交互组件+灵活的布局要求也带来了额外的复杂性。

面向业务的设计服务在采用相应的技术之前，需要了解不同业务之间的差异。这里有一个思路:以一个互动大班为例，一个老师和一个学生在犁地，然后把犁地的过程分给其他同学。对于流媒体分发，右侧列出了一些考虑因素:需要什么程度的延迟和流畅度？有多大？需要多高的媒体质量？当前业务对该方案的成本有多敏感？

这样就可以进一步横向比较不同的课程，通过它们的差异获得更细化的要求。

比如大班直播课和互动大班课对比:对于一个M规模的对话，大班直播课要把一个人的信息分发给M-1个人，这可以通过基于CDN的视频直播来完成。如果想为产品进一步增加连续麦的互动，可以成为互动大课堂。连作的增加会把简化模型变成两部分。如何在一个教室里满足这两个要求？最简单的思路是在原有CDN分发的基础上，通过RTC交换连麦的内容，然后通过原有CDN系统分发他们的信息，但这样会造成内容延迟、用户切换延迟等问题。

对比互动大班和(线上线下)双师课堂，虽然模式相似，但场景中双师课堂的一个“学生端”可能对应一个线下教室的所有学生，会增加非正常单通道分发的价格。这样的差异也需要系统针对不同的场景配置不同的策略。

除了在线教育，横向比较的思路也可以用来分析其他场景的业务线，比如普通的小课堂，黑游戏。黑开看似类似于普通的只发语音的小班课，但在性能和网络占用方面更加严格。在尽可能不占用游戏带宽的同时，也要尽量减少CPU运行，为游戏提供充足的计算能力。如果在游戏中直接使用小班课程的RTC接口，不仅不能保证通话质量，还会影响游戏。如果期望一个系统支持多种服务，则有必要在系统设计的早期阶段阐明业务差异和设计要求。

通过以上分析，我们可以列出在线教育业务对媒体分发系统的一些主要需求点。第一，要满足配送低延时，装麦低延时的要求。第二点是大规模分发。相对于一些娱乐场景，需要达到高稳定性和高可用性。第四点是控制成本。最后，不同的学生，不同的教室，对上课场景的需求是不一样的，所以一定要支持多终端接入。

当多条业务线走向小班，直播走向大班，互动走向大班，互动走向小班，这将影响分发系统的演进进程。一种想法是，随着业务的演进，分发架构变得越来越复杂，不断支持越来越多的特性。有道并没有采用这种思路，而是经历了从基于CDN的分发到面向所有服务的实时通信网络(RTN)的切换，架构上没有中间过渡状态。

基于CDN网络的直播内容分发的树形结构非常清晰。结构本身决定了数据路由，并且易于维护，风险和成本可控。当用户选择边缘接入时，媒体数据的分发路线已经被规划。同时，它也有自己的缺点，如:只支持单向分发，协议引起的固定延迟等。

为了增加互动性，减少延迟，早期通过CDN模式部署的直播在CDN架构的基础上做了两处优化。一方面，边缘流节点支持RTC接入(图中也写成RTN边缘节点)，屏蔽了媒体封装协议带来的延迟，增加了IM交互效果，同时也增加了弱网阻力。另一方面，为了进一步增加互动性，增加了RTC bypass系统，支持双向连播，再将连播内容转移到CDN网络完成直播。一些“低时延CDN直播”产品采用的就是这个原理。

刚才提到连麦使用的bypass RTC系统需要将内容转移到CDN分发网络。这个系统还能做CDN大规模分发的任务吗？于是就有了纯RTN架构。这种体系结构不再具有独特的树形分布结构，而是使用网状拓扑来分布所有内容。任何单向流客户端都可以随时切换到双向通信，而无需首先切换系统。

通过以上分析，我们可以大致总结出行业流媒体直播分发的演进方向——音视频直播CDN和RTC的网络边界模糊，逐渐融合。直播CDN厂商从单向大规模分发逐渐支持低时延接入和持续小麦。之前的RTC产品，从面向会议的小型架构开始，为了同时服务几千人和一万人，逐渐开始将分发网络复杂化。所以现在我们可以看到，网易的WE-CAN分布式传输网络、阿里云GRTN流媒体总线等“X-RTN”都是这个演进过程的结果。

刚才提到的架构主要是ToB厂商的产品。在ToC服务场景中，也会出现上图所示的架构，通过一个媒体服务器集成两个分发网络提供服务，尤其是在同时存在自研和三方接入的情况下。这种结构不仅带来了新的非功能特性，也存在很大的风险。没有选择过度使用类似的架构，而是直接用RTN分发网络替代原有功能。

该架构可以满足各种场景的需求，也支持各种推拉式的流客户端访问。比如学生在公开课的时候，直接通过微信小程序或者浏览器观看最方便。已经使用过课程APP并参加过一系列课程的用户，使用APP接入，获得最佳体验。

相对于决定数据分发路由的CDN架构本身的拓扑，RTN网状拓扑带来的是灵活性和复杂性。比如路由不能直接从拓扑中获取，需要额外的调度中心来计算和规划路由，完成相应转发资源的调度，这也凸显了RTN架构下调度中心的重要性。

图中还有一部分CDN bypass，主要作用是平衡一些突然访问过多的课程的负载，增加系统的灵活性。

有一种说法是，在设计网络节点的拓扑时，更加灵活。一方面，分布节点没有层级和等级之分，采用扁平化拓扑。另一方面，可以通过配置不同的属性和角色来改变网络分布特征。

流媒体分发系统有四个关键点:接入问题、网络连通性、路由建立和转发。此外，我想分享分层设计和渠道的概念。

解决接入问题的核心思想是“近”接入——网络质量最好的接入就是“最近”的接入。(不同类型的商家可能有不同的思路:在一个众所周知的教学场景下，尽量让每一个已有的用户体验都做到最好，类似贪婪算法；然而，在其他服务中，当达到QoS最低限制时，想法可能是选择具有最佳全局成本的接入和路由模式。)最直观的方式就是使用IP和基于位置的访问推荐。利用不同网关的网络检测和连接历史数据，进一步优化推荐结果。除了利用线上线下数据统计得到的先验知识进行访问推荐，考虑到这种方法不能覆盖所有特殊情况，还引入了手动配置的支持。支持一些ToC场景的手动热配对非常有效。

右下角是一个大班老师丢包率的点阵图。可以看到，有规律的丢包，平均在9%左右。老师用固定的设备在固定的地方长时间直播，早期有技术支持的同学查网络，网络一直很好。按照之前的算法，他的位置没有变化，网络没有变化，使用的推荐数据库也没有太大变化，所以按照算法，每次都会给出相同的推荐结果。突发的、有规律的丢包是假设流量行为被运营商识别和分类，并且受到政策限制。

这种情况下，修改算法是不可行的。通过热配置的方式，可以在上报问题时手动修改配置，下一次老师接入会避开相应的接入节点来解决丢包问题。

我们通过“过滤”机制实现这个操作:如果所有可访问的节点形成一个池，那么最终“过滤”的结果形成一个推荐给客户机访问的列表。所以过滤规则的计算过程作为算法写入系统，算法执行中要用到的参数作为可以热更新的数据写入数据库。

接入只是解决了配电网的入口问题，那么配电网是什么样的拓扑呢？这涉及到网络节点的连通性设计。有道网是平面拓扑，每个机房都是拓扑中的一个平面点。理论上所有的节点都可以连接起来形成网状网络，所以这个网络会极其灵活，任何路径都可以规划，实际的路由选择完全取决于算法。有道没有采用这种方式。

我们引入了一些人工经验，比如根据经验删除一些机房的连通性，变成非全网状结构。可以认为修剪和组织是通过手工方法进行的。除了连通性，还需要解决路由计算中权重的获取问题，这就需要对节点连接的差异进行定量描述。这种量化基于常规的QoS检测。与前面的访问选择问题类似，算法可能无法精细地满足所有情况或一些特殊情况，所以除了量化差异，我们还使用可配置属性来描述定性差异，以增加拓扑的灵活性。

之所以提高灵活性，支持手动配置，是为了满足不同业务的差异化需求。同时有一个代价，就是复杂度的增加。所以也许没有最好的架构，只有更适合的。

在接入位置确定(配送的起点和终点确定)和配送网络连通性建立后，要解决的问题就是路径规划或调度。这里有三点实践和思考可以分享:一条路线规划，多条路径，成本控制。规划单条路线是数据分发的基础。我们根据动态检测和刷新的网络QoS的定量质量，并基于当前节点状态和节点配置来计算路由权重。有了无向加权图、端点和起点，就可以规划最短的配送路线。

接入问题已经解决，配电网连通性的定义已经完成。现在媒体数据分发路线的规划已经解决，看起来分发任务可以完成了。然而，这对于适当的业务需求来说是不够的。为了进一步保证用户体验，需要提高分发网络抗抖动和丢包的能力。多路分配是一种保证方法。分布式网络中有三条路径:主路径、备用路径和实时路径。主路径直接用于业务分发；备选路径是主路径的备份，在主路径规划时生成，在主路径异常时切换。实时路径是在主路径之外额外建立的多路冗余分发路径，提供更强的抗分发抖动和丢包能力，对于一些关键任务和大规模分发任务具有重要价值。

以橙线为例。是移动、联通、电信三家单线机房。除了主路径之外，还可以在两边的联通运营商之间建立实时路径，在实现实时备份的情况下，可以降低备份线路的成本。

控制中心完成数据分发路径的规划后，需要沿线节点执行转发任务。这涉及到高性能流媒体分发服务器的设计。上图显示了转发服务器的线程模型。协议和端口对应不同的线程，在端口有限的情况下，尽可能多的利用多核资源。

除了绑定到每个协议端口对的IO线程之外，还有一个核心线程来完成来自不同访问的数据包路由。例如，一个流用户从协议A的端口A1访问(如果使用UDP从端口3000进行流传输)，同一会话中的另一个流用户从协议B的端口B1访问(如果使用TCP从端口4000进行流传输)。这两个用户按照IO线程模型是不能分配到同一个线程的，所以需要跨线程的数据转发。此时，核心线程会根据会话发布和订阅的关系，将接收队列的内容转发到相应IO线程的队列中。

线程模型的设计也与业务的类型和比例有关。当时系统负载主要是大班，也就是推流量的人比拉流量的人少很多。如果业务类型发生变化，比如班级类型越来越小，课程每个成员推流，服务器用户总数不变的情况下，核心线程的转发负载会比大班大大增加。这也是小类业务带来的挑战，需要架构灵活应对业务变化。

除了上述四个关键问题，我想借此机会分享和讨论两个额外的细节:分层设计和渠道的概念。

分层设计相当于转发问题的延伸。服务器从连接中获取数据后，它通过核心线程分发数据。逻辑上可以理解为三层:链路层解决不同协议的连接问题；路由层负责数据的内部分发和传递；会话层维护发布-订阅关系，引导路由进行分发，并将数据发送到正确的连接。这种分层的思想不仅用在单机线程模型中，而且用在整个分发网络中。

当一个业务方接入一个实时通信SDK，不同的ToB厂商对“渠道”会有不同的定义，简单理解就是对实时媒体传输资源的抽象。比如一些厂商服务的业务场景主要数据是面屏共享，对应的SDK可能只提供两个通道资源，其中面通道支持大小流同时推送。

上图以互动大班为例，介绍有道对“频道”设计的思考。左下角的图是典型的互动大班的老师上课效果:右上角的老师是讲师，他正在和左边的学生一起，那么如何进一步把当前界面的所有信息传递给其他学生呢？有道实时通讯SDK提供直播、RTC、群组等多种渠道资源。SDK公开的通道资源的数量可以不同地定义和配置。虽然名称不同，但底层资源属于同一类别。一个通道对应一路同步的音视频分发能力。

以刚才的场景为例:示意图左边是老师，右边是学生。就是橘子RTC频道，完成师生连作。然后老师在服务器上混合连麦的内容，课程白板等等，混合成音频和视频，通过直播频道发给其他听课的同学。比如可以获取当前屏幕内容在终端上做混流。在互动大班业务场景中，学生需要获取的所有信息都在这张图片中，这是视频和音频的媒体信息。这样就可以把两个渠道结合起来，一个是和小麦连接，一个是直播，从而完成整个业务。

不同的通道之所以有不同的名称，而不是使用通道对象的数组，是为了进一步降低客户端的访问门槛。比如直播通道在概念上比RTC更流畅，可以对应更大的最小视频缓冲区，提高网络抗抖动能力。

在业务方面，发现SDK提供渠道资源的方式可能会影响业务方的思维模式:如果只有“面渠道”和“屏渠道”，这可能会限制业务产品在新课程形态上的思维。

借此机会和大家分享一些关于互动小班的尝试，从以下两个方面与大家交流:什么是小班的“互动”？以及互动课程的录制。

在小班里，很多学生和老师可以一路连麦。可以把不同的同学拉到台上，随时分享和回答问题。除了音视频和白板，我们还增加了一些互动元素:本地媒体元素播放、多人实时互动棋盘等。这种互动元素带来了什么影响？

上面提到的互动大课，可以在服务器上混合，然后发送到直播频道，这样流媒体不仅可以省去在单独的服务器上混合流带来的视频延迟和同步问题，还可以完整的传输所有的课程信息。但对于互动小班，如果老师通过这个截屏把内容分发给其他同学，那么互动元素的互动性就丧失了，布局也无法改变。当一个学生回头看录播时，他无法参与，只能作为旁观者观看其他学生的互动过程。这也是互动小班的第一个难点——如何处理互动元素？怎么录？如何在播放过程中保持同步？其实坑多，挑战多。

这里部分内容摘自ToB厂商对痛点的分析，自研所遇到的问题可以分为以下几点:

成本:除了人力、资源覆盖、动态扩容收缩的运维，还有相应的机会成本。前两点比较重要。另外，不同业务的带宽峰值位置不同。重用一组基础设施和带宽资源可以减少资源和能量的消耗。

边界:比如是否增加特殊配置来解决业务问题，如何通过团队内部的自研来把握业务需求的边界？

系统优化门槛:运行完上面提到的所有内容，业务就可以运行了。但如果想进一步降低成本，就需要对技术栈有更深入的了解，比如数据驱动的全链路传输优化、编解码优化，需要的难度和人力可能更高。

对音视频基础设施的理解:音视频已经逐渐成为一种基础设施，但如果团队只是通过第三方SDK接入音视频能力，可能无法深刻理解音视频技术的难点，正确评估风险，把握潜在机会。

更多的原子能力:自研技术可以根据复杂的业务需求更灵活地根据业务线进行配置，并以合理的方式暴露更深层次的接口，这将使业务层更加灵活。

对产品、R&D和技术支持的帮助:音视频技术涉及面广、复杂，客户的R&D学员和技术支持学员很难根据掩埋的数据准确排查业务异常、分析问题原因。依靠音视频自研团队积累业务中遇到的问题，了解更深层次的原因，排查未来可能存在的隐患，是一种有效的方法。音视频自研团队可以辅助产品设计，加速音视频技术的研发，也可以辅助技术支持确定业务中用户问题的原因，及早发现更深层次的隐患。毕竟工单系统再快，也未必比下一个工作站的支持来得快。

成本控制，面向业务的优化:当可以控制的技术下到底层，针对具体业务的优化空间会更大，在进一步优化体验的同时，成本压缩的空间也会更大。

在code_pc项目中，前端需要使用rrweb录制老师的教学内容，学生可以录制和回放。为了减少记录文件的体积，目前的记录策略是先记录一个完整的快照，然后记录增量快照。在记录阶段，我们实际上是通过MutationObserver来监控DOM元素的变化，然后将事件推送到数组中。

对于持久存储，可以将记录的数据压缩并序列化为JSON文件。老师会把JSON文件放到课件包里，打包成压缩包上传到教务系统。学生回放时，前端会先下载压缩包，通过JSZip解压，得到JSON文件，反序列化解压得到原始录音数据，然后发送给rrwebPlayer实现录音回放。

在项目开发阶段，测试录音不会太长，所以录音文件大小较小(在几百kb左右)，回放也比较流畅。但随着项目进入测试阶段，在模拟录制了一个很长的上课场景后，发现录制文件变得非常大，达到了10-20 m，QA同学反映，打开学生回放页面时，页面明显卡顿了20多秒，而在这段时间内，对页面交互事件没有任何响应。

页面性能是影响用户体验的主要因素，这么长的页面卡顿显然是用户无法接受的。

经过群内交流，我们知道可能导致页面卡顿的因素主要有两个:zip包的前端解压和录放文件加载。同事怀疑主要问题是zip包的解压，希望我能尝试把解压过程放到worker线程中。那么zip包前端解压导致页面卡顿是真的如同事所说吗？

对于页面卡顿问题，首先肯定是线程阻塞造成的，所以需要找出长任务出现在哪里。

所谓长任务是指执行时间超过50ms的任务。众所周知，Chrome浏览器页面渲染和V8引擎使用一个线程。如果JS脚本执行时间过长，会阻塞渲染线程，导致页面堵塞。

对于JS执行耗时分析，大家应该知道如何使用性能面板。在性能面板中，通过查看火焰图来分析调用堆栈和执行时间。火焰图中每个方块的宽度代表执行时间，方块叠加的高度代表调用栈的深度。

如你所见，replayRRweb显然是一个很长的任务，耗时近18s，严重阻塞主线程。

但是replayRRweb耗时太长，因为有两个内部调用，左边的浅绿色部分和右边的深绿色部分。让我们来看一下调用堆栈，看看哪些地方需要更多的时间:

熟悉Vue源代码的同学可能已经看到了，上面这些耗费大量时间的方法是Vue中的递归和响应方法(右边显示这些方法来自vue.runtime.esm.js)。

为什么这些方法会占用主线程很长时间？Vue性能优化有一个规则:不要把复杂的对象扔进数据中，否则Vue会深度遍历对象中的属性，添加getter和setter(即使视图渲染不需要这些数据)，从而导致性能问题。

在上面的代码中，创建了一个rrwebPlayer的实例，并将其分配给rrWebplayer的响应数据。在创建实例时，我们还接受了一个eventsRes数组，它非常大，包含数万条数据。

Data选项中没有提前定义数据，但是this.rrwebPlayer是在组件实例创建后动态定义的(没有提前依赖集合，没有递归响应)；

数据是在数据选项中预定义的，但是当状态随后被修改时，对象被Object.freeze处理(使Vue忽略对象的响应处理)；

数据以模块私有变量的形式在组件实例外定义(这样的话要注意内存泄露，Vue不会破坏组件卸载时的状态)；

重新加载页面，我们可以看到此时页面仍然卡滞，但是卡滞时间明显缩短到5秒以内。根据火焰图，在replayRRweb的调用栈下，递归响应的调用栈已经消失了:

可以看出问题还是出在replayRRweb这个函数上。是哪一步:

因为rrweb录放需要dom操作，所以必须在主线程中运行，不能使用worker线程(无法获取dom API)。对于主线程中的长任务，很容易想到长任务被时间切片分成小任务，任务被事件循环调度。当主线程空闲且当前帧有空闲时间时，执行任务，否则渲染下一帧。方案确定了，接下来就是选择哪个API，任务如何划分的问题。

这里有些同学可能会问为什么解包过程不能放到worker线程中执行，worker。

Thread将数据解压缩后返回给主线程进行加载回放，这样就可以实现无阻塞了？

仔细想想，工作线程解包的时候，主线程必须等到数据解压完成后才能回放，这和直接在主线程中解包是一样的。

没有本质区别。只有当有多个并行任务要执行时，工作线程才具有性能优势。

说到时间片，很多学生可能会想到API requestIdleCallback。RequestIdleCallback可以在浏览器渲染一个框架的空闲时间执行任务，以免阻塞页面渲染、UI交互事件等。目的是解决当任务需要长时间占用主进程时，优先级较高的任务(如动画或事件任务)无法及时响应，导致页面丢帧(卡顿)的问题。因此，requestIdleCallback的定位是处理不重要和不紧急的任务。

渲染任务已完成，在执行之前还有时间。在这种情况下，下一帧需要完成requestIdleCallback的执行才能继续呈现，所以

30ms，如果控件长时间不返回浏览器，会影响下一帧的渲染，导致页面卡顿，事件响应不及时。

看起来requestIdleCallback似乎很完美。能否直接用于实际业务场景？答案是否定的，查看MDN文档可以发现，requestIdleCallback只是一个实验性的API，浏览器兼容性一般:

通过查caniuse可以得到类似的结论，并不是所有的IE浏览器都支持cani use，safari默认不启用:

而且还有一个问题，requestIdleCallback的触发频率不稳定，受多种因素影响。根据实际测试，FPS只有20ms左右，正常情况下一帧的渲染时间控制在16.67 ms。

在项目中，考虑到api回退方案和对取消任务函数的支持(以上代码比较简单，只添加任务函数不能取消任务)，最终采用了React的官方源代码。

根据rrweb文档，rrWebplayer实例提供了动态添加播放数据的addEvent方法，可用于实时直播等场景。按照这个思路，我们可以把录好的回放数据分成块，调用addEvent进行多次添加。

按照上面的方案，我们重装了学生回放页面看了一下，现在几乎察觉不到停滞。我们找一个20M的文件加载，观察火焰图。我们可以看到，录音文件加载任务已经被分成了小任务，每个任务执行时间约为10-20ms，不会明显阻塞主线程:

优化后页面还是卡。这是因为我们的分割任务的粒度是100。在这种情况下，加载录音回放还是有压力的。当我们观察到fps只有十几的时候，就会有卡壳的感觉。我们继续将粒度调整为10。此时页面加载明显流畅。基本上fps可以达到50以上，但是录制、回放、加载的总时间略长。使用时间切片的方法可以避免页面卡住，但是录音回放加载平均需要几秒钟，有些大文件可能需要十秒钟左右。我们在这种耗时的任务处理中加入了加载效果，防止用户在录制文件加载前播放。

有的同学可能会问，既然加了加载，为什么还要时间切片？没有时间切片，加载动画就不会显示，因为JS脚本一直在占用主线程，阻塞UI线程。只有通过时间切片，释放主线程，才能执行一些优先级更高的任务(比如UI渲染、页面交互事件)，这样加载的动画才会有机会显示出来。

使用时间片并非没有缺点。如上所述，录制回放加载的总时间略长。幸运的是，10-20M的录音文件只出现在测试场景中，老师在课堂上实际录制的文件都在10M以下。测试录音回放后，2s左右就可以加载，同学们不会等太久。

如果后续录制文件很大，如何优化？我们没有把前面提到的unpack进程放到worker线程中执行，因为考虑到放到worker线程中，主线程要等worker线程执行完，和主线程没什么区别。不过受时间切片的启发，我们也可以将unpack任务切片，然后根据navigator . hardware concurrency API开启多线程(线程数等于用户CPU的逻辑核数)，并行执行unpack。因为多核CPU的性能，应该能显著提高录制文件的加载率。

本文通过性能面板的火焰图分析调用栈和执行时间，进而找出导致性能问题的两个因素:Vue复杂对象的递归响应和录放文件的加载。

对于Vue复杂对象递归响应带来的耗时问题，本文提出的解决方案是将对象转化为无响应数据。为了解决加载录放文件带来的耗时问题，本文提出的方案是使用时间切片。

由于requestIdleCallback API的兼容性和不稳定的触发频率，本文参考React 17源代码分析了如何实现requestIdleCallback调度，最后用REAT源代码实现了时间切片。经过实际测试，优化前页面卡顿20s左右，优化后无法检测到卡顿，fps可以达到50以上。但使用时间切片后，录制文件的加载时间略长。后续优化方向是将unpack进程分成块，开启多线程，并行执行unpack，充分利用多核CPU的性能。

这不，年度科技先锋榜正式出炉了。网易有道的技术团队登上年度技术团队榜和科技品牌影响力企业，中国。

2022年1月13日，SegmentFault作为国内领先的新一代开发者社区，基于对社区用户行为大数据的综合分析(如文章&问答发表数量、人气&好评等)，评选出30支最优秀的年度技术团队。).

最终评选出30个年度技术团队，部分技术团队入选，并登上2021年中国技术先锋年度榜单，荣获2021年度技术团队称号。

本文是网易有道企业发展高级效率项目经理张皓然题为《R&D效率实践助力互联网行业项目管理有效》的演讲，围绕两个主题:R&D效率实践和项目管理。

写分享PPT的时候，我首先想到的是互联网行业的项目管理。但现在不仅是互联网，传统行业也在进行数字化转型。所以这个项目管理是可以全行业讨论的。之前做研发，后来主要做项目管理，过程中做了一段时间的产品管理。目前主要在网易有道企业发展部，提升整个R&D效率，完善项目管理。

有一种说法是网易有道推出了专为4-8岁儿童设计的线上年。它开发了中国第一个在线互动围棋动画课程。从孩子的理解和喜好出发，使围棋知识变得简单、有趣、易懂、易学，帮助孩子掌握了围棋的各种规则和技巧。不仅如此，课后还有AI游戏功能，可以智能识别孩子的水平匹配游戏练习，从根源上培养孩子的思维习惯。每局结束后的智能分析会从全局、算力、稳定性、格斗、棋型五个方面进行全方位分析，帮助孩子在复盘中取得进步。

谷歌Deepmind提出的AlphaGo、AlphaGo Zero和alphazeroseries算法展示了深度强化学习在国际象棋领域的非凡能力。2016年AlphaGo横空出世，以4: 1击败欧洲围棋冠军范辉二世，2017年4:1击败14位世界冠军李世石，2018年3: 0击败最年轻的六冠王柯洁九。从此再也没有人质疑AI在围棋领域的霸主地位，同时也引发了职业棋手学习AI绝招的热潮。在职业围棋比赛中，“狗把戏”经常出现。学习和研究AI招数背后的逻辑，已经是职业棋手的必修课。

此次以Redis为例，主要从声明式管理、操作员工作原理、容器安排、主从模式、集群模式、高可用策略、集群伸缩能力等方面，阐述了一个基础设施团队在基础设施容器化道路上的实践。

Redis是业务系统中常见的缓存服务，常用于流量高峰、数据分析、积分排序等场景。中间件可以实现系统间的解耦，提高系统的可扩展性。

传统的物理机部署中间件需要运维人员手工搭建，启动时间长，不利于后期维护，无法满足快速业务发展的需求。

与传统IT相比，云原生可以帮助业务平滑迁移、快速开发和稳定运维，大大降低技术成本，节省硬件资源。

基于云的中间件是指容器化、服务网格、微服务、无服务器等技术。，构建可扩展的基础设施，持续交付生产系统的基础软件，从而在不改变功能的情况下，提高应用的可用性和稳定性。

在这个大趋势下，有道基础架构团队开始了云原生中间件的实践，包括Elasticsearch、ZooKeeper等等，此外还有本文介绍的Redis。

本文地址： http://www.fadun365.com/jinrong/105513.html

文章来源：laughing168

版权声明：除非特别标注，否则均为本站原创文章，转载时请以链接形式注明文章出处。