背景：Kubernetes(k8s)/ack是一个开源的容器集群管理系统。在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。由于大数据集群资源使用庞大，成本高。资源使用存在潮汐现象，同样公司的业务体系也存在潮汐现象，并且对比资源使用情况，大数据集群和业务体系服务器正好形成错峰资源使用状态。线上业务只有白天会吃资源比较多，晚上所占的服务器资源比较空闲，这样可以让资源紧张的大数据生态去充分利用业务体系的空闲资源。结合k8s动态伸缩特性可以支持晚上大数据生态弹性错峰调度业务体系资源，达到资源共享目的，有效的节省成本，提高服务器资源利用率。01在离线混部实现方案1、目标资源共享，缓解“潮汐现象”；推进云原生方案快速落地；集群快速的弹性伸缩。2、在离线混部方案通过k8s的弹性扩缩能力，实现nodemanager的弹性扩缩容。具体方案图如下：在离线混部方案实现过程改造RM支持pod-NM的注册，主要解决了node_allow、nm

请求就能完成一次攻击，拿到用户隐私数据。这种url类似于：https://xx.com/xx?query=alert(document.cookie)解决办法:尽量不要使用eval

背景：本文从一个有序单链表的数据结构开始，讲解有序单链表的插入、查询过程，通过插入、查询过程来引出有序单链表对于"高效"插入、查询的问题，然后通过对有序单链表的不断的改造，逐渐形成一个新的数据结构-跳跃表，并推导出跳跃表的、插入、查询时间复杂度，然后引出我们的主题的实现，通过对其数据结构、高度算法、插入、查询、删除的逐行源码分析让大家充分的了解其底层的实现，最后再通过跳表跟哈希表、平衡树、Btree之间的对比来说明为什么Redis会选择跳跃表这种数据结构作为Sorted-Set的实现。希望通过本文让大家真正掌握跳表这种数据结构，掌握Redis的Sorted-Set底层实现的原理。01单链表1.1

前言：本文记录了Cocos多边形点击的两种实现方式，和解数独过程中的优化和思考。01Cocos多边形点击背景：正在用cocos做一个七巧板拼图小游戏，成品效果如下～由于cocos提供的节点点击事件只支持矩形，这种模式下七巧板中的三角形实际点击区域是个矩形，表现就是视觉上没有点到三角形却响应了点击事件，严重影响体验，所以需要优化点击区域的判断我总结了下面两种方法：方法1：像素透明度判断观察三角形图片发现：图片分为三角形显示区域和透明区域，需要响应点击的是显示区域，只需要判断出是否是透明区域即可。判断方法如下：将点击坐标转换为图片对应像素点，获取像素点alpha值进行判断：

测试右移灰度发布，新功能上线前灰度环境全方位回归测试，减少线上问题。监控，加入报警监控群，通知开发排查频发报警问题。用户反馈，参与客诉值班，为线上问题排查主力。3）线上客诉问题分析A.

加速，就齐了且慢，运维伙伴反馈：由于二级域名过多，导致全集团加速的域名已经要超出套餐数量为了达到套餐内能实现预发布环境部署来验证实际的优化效果，我们内部决定要做一轮

PlayBook剧本是一个DAG图，其控制整个数据流的消息流转，顺序，worker交互，实现了ttl计算处理算法，无环检查等。其功能特性补充如下：（1）保证分布式Server一致性，数据一致性，

导读：本章节主要介绍服务端对于网络并发模型以及Linux系统下常见的网络IO复用并发模型。文章内容一共氛围两个部分。第一部分主要介绍网络并发中的一些基本概念以及我们Linux下常见的原生IO复用系统调用（epoll/select）等。第二部分主要介绍并发场景下常见的网络IO复用模型，以及各自的优缺点。01网络并发模型中的几个基本概念1.

什么是轻舟业务网关轻舟业务网关是轻舟大学生项目组所有API服务的入口。他承载了项目组内所有API的流量，且在网关层具备了传输解密,登录态鉴权,传输防篡改,路由修改,缓存,未发布Mock,APi文档等通用能力。是使用Openresty+Lua技术栈实现，在Lua层实现业务逻辑，并使用nginx的proxy能力进行反向代理。01现状1、控制颗粒细相比于集团网关，轻舟业务网关更贴近于业务。拥有更细颗粒度的控制。我们以method+path+api_version来确定唯一控制级，在这个控制级里可设置是否签名,登录态鉴权,内外网访问,后端转发Path,后端服务器等等。可以说是以接口来控制业务。e.g请求

数据中台的Node.js中间层从7月份开始讨论可行性，截止到9月已经支持了4个平台，其中3个平台生产环境稳定，另1个在测试阶段近期上线。我4月份刚加入数据中台，原本的想法是半年内不做大刀阔斧的改变，优先完善团队现有的基建设施，比如组件库、charts库、工具、规范等。Node.js中间层的立项完全是一个意外。某次中台周例会上讨论到前后端协作效率问题，我提到了Node.js中间层的想法，将应用平台的一些与DB无关的逻辑放到Node层让前端伙伴们负责，让后端伙伴集中精力做底层服务建设。本来就随口一提，结果老板当真了，当场拍板：搞！我当时的表情大概是…没办法，自己画的饼，哭着也要吃完。01Node.js的定位数据中台

出于业务的需求，我们实现了一套直播可用的轻量型人脸贴纸。下面简单介绍一下实现的过程和难点。01技术分析对于这个需求，实现上需要考虑的地方有:首先保证可用和效果良好；由于使用场景是在直播，本身功能的各方面性能消耗就高，所以要尽可能的优化性能；控制包增量；侵入性低；使用方便。经过调研，我们的技术方案确定如下:视屏处理：视频方面采用GPUImage来进行处理。开源，完成度高，而且流式结构以及对滤镜，视频的抽象都很好，使用方便。唯一美中不足的是采用单例来保存BufferCache以及Context，对于只是实现额外贴纸功能的我们（APP的主功能并非视频处理）带来的内存增长利大于弊【注释1】。人脸识别模块：人脸识别模块我们做了很多调研。其中包括付费的商汤，Face++，开源的智云（HyperLandmark），OpenCV，原生的Vision，ARKit等。多方对比过：商汤，Face++这些在人脸准确性，稳定性，使用便捷上都非常出色，但是本身带有不小的包增量，对于我们这个小功能来说负担很大。开源方面，智云只有安卓版本，而iOS版本（HyperLandmark-iOS）内部使用的引擎是opencv，稳定性和准确性不高，另外包增量很大（OpenCV依赖，内部很难分离其中的人脸识别模块，cv::mat的数据流通也需要转换）。原生方面ARKit的性能由于实时分析，结构光等原因，很难在低端机使用（本身版本限制，硬件限制很多）。只有Vision是相对较好的选择，无包增量，识别效果较好，稳定性虽然较差，但是这个可以通过算法优化。版本限制也不高（iOS12即可使用），考虑到性能问题本身就有限制，这个的影响其实可以接受。当然，Vision作为一个原生库，很多地方都不够完善，例如欧拉角的识别，识别点防抖的处理等。人脸贴图：人脸贴图与视频的合成，视频处理的内容，使用OpenGL。贴纸格式参考市面上SDK的部分进行设计。02流程介绍实现上大致分成三条线处理，这三部分是异步的互不干扰：接收到视频数据后，对视频方向和分辨率进行处理（视频方向对人脸识别精度影响很大），生成人脸特征点，留待备用。接收到人脸贴纸后，对放大比例，坐标，特征点，触发进行处理，留待备用拿到视频数据，人脸特征点，贴纸图片和信息，进行绘制03实现细节及难点1.贴纸json解析width和height，以及贴纸图片地址，每帧速率都很容易解析。定位相关的数据在下面"position":

将数据转换为Rowdata。com.ververica.cdc.connectors.mysql.source.reader.MySqlRecordEmitter#emitRecordpublic

具体的打法自下而上，根据数仓提供的标准化收集需求模版定期（月末）收集下个月的需求，支持数据中台横向项目.自上而下，梳理好未来各事业部的用户行为，并标注核心用户行为，结合业务理解数据.通过

背景：原来部门内没有专门的消息队列服务团队，且不同的研发团队使用的语言不同，在使用消息队列服务时，还需要各个研发团队关注底层消息队列系统的选型、协议以及使用方式，经常由于稳定性和容错机制等问题，导致业务服务受到影响。基础服务中台MQ团队基于kafka官方的提供java客户端，自研了分布式消息中间件MQProxy。用户可以通过简易的SDK轻松地接入MQProxy进行生产和消费，使用丰富、快捷、可靠的消息服务。01设计目标MQProxy主要目标是让研发人员能够方便的使用消息队列服务。研发人员可专注业务编码，无需了解以下内容：底层消息队列系统的选型；底层消息队列系统的协议；底层消息队列系统的使用方式；底层消息队列系统的健康状况与容错机制；03已实现功能为实现上述目标，MQProxy负责完成的基础功能包括：对常见的开源消息队列系统选型统一使用研发人员更熟悉的HTTP协议、TCP协议提供简单的produce/consume/commit

综上操作，内存耗用截图如下,无用内存大部分得到释放：扫描下方二维码添加「好未来技术」微信官方账号进入好未来技术官方交流群与作者实时互动~(若扫码无效，可通过微信号TAL-111111直接添加)-

导读：随着公司业务的不断扩张，尤其是在2020疫情开始后，整个在线教育行业的竞争变得异常严峻，作为这个行业的领路人，用户流量更是成倍增长，这就对我们在线业务运维体系的稳定性提出了更高的要求。对此网校整体产研部每年寒、暑假都会针对性成立寒、暑特战队。特战队成员为各业务总接口人以及各专项总负责人，特战队成员共同目标为：保障寒、暑假期间百万学员同时稳定上课，无S0事故。每个部门方向均需要输出负责人review过的保障方案，如需有风险，列出整改计划，这里我们从SRE视角对活动保障体系进行了系统性的梳理和总结，将好的沉淀总体分享给大家。整体来看，保障大致分成三个阶段：重保前-重保中-重保后

H1，是我们要收集证据去支持的假设。举个例子对于开启APP的用户，我们想测试弹屏A和弹屏B，哪一种带来的用户点击率和转化率更高那么这个实验里，原假设是A和B的点击率没有差别，备择假设是点击率不同。当

01网络编程模板常见的网络编程模式如下(以ipv4中tcp协议编程为例)，首先创建一个socket套接字，即用于监听的文件描述符listen_fd；将它与具体的ip和端口号绑定；开启监听；使用一个循环来接受客户端的请求；创建子进程或者线程来处理已经连接的请求。//创建监听的文件描述符listen_fd

背景：实时监控大屏，作为大数据领域的经典应用，已经普遍存在在各大互联网公司的应用案例中，像淘宝双11的实时销量大屏、滴滴的用户地域分布等场景，那么在好未来的业务体系中，也有很多核心场景是需要通过实时大屏来进行统一监控的，此文主要介绍「未来云-业务监控」中提供的实时监控大屏解决方案；01关键点整个实时大屏的建设分为技术上和产品两部分，下面列举一些项目中的关键点和难点：技术上海量日志的秒级实时指标计算；日志流量潮汐性较大时的计算保障；不同类型指标的存储选型。产品上哪些业务需要实时大屏；哪些指标需要展示在大屏上；怎么去定义一个实时大屏的价值。02技术架构1.架构详解来源层：来源层主要包括所有和目标业务相关联的核心日志信息，业务数据等，主要包括：客户端日志：用户埋点信息、行为操作、网络请求、崩溃异常等；链路日志：请求调用链路中涉及的关键步骤日志，包括DCDN、源站、服务端Trace等；业务日志：业务事件的关键日志信息，映射到关键业务行为的痕迹；业务数据：结构化的数据库中的多维度业务基础信息，例如用户、课程、订单等传输层:

前言：在互联网时代，消息服务已成为必备的产品。比如微信、钉钉和QQ等以IM为核心功能的产品。还有一部分是直播间内用户聊天互动，形式上也是常见的IM消息流；直播间内常见的消息流包括直播弹幕、互动聊天、信令、涂鸦、消息推送等。在线教育行业内消息服务尤其重要，直播授课过程中的互动答题、涂鸦、表演、点赞等，不过对消息可靠性有非常高的要求，而且对消息的即时性也非常敏感。01消息服务当说到消息服务的时候大家都会想到微信等常见的IM产品，所以直播间内的聊天消息经常类比于群聊，而1v1的消息类比于单聊。大部分人听到消息服务的时候都觉得消息服务很简单，不就是分为单聊和群聊两种。单聊不就是把消息转发给某个用户；群聊不就是把消息广播给聊天室内所有的用户。那消息服务面临的挑战有哪些呢，看下图：02业务场景分析针对上面的难点，我们来梳理一下如何构建直播的消息系统。面临的问题初期业务主要的场景是直播间的群聊消息以及一小部分的单聊消息。由于是教育场景，所以业务在划分聊天室的时候是以班级为单位进行划分的，假设每个聊天室为500人。问题一：用户的维护直播场景的群聊与微信等常见的群聊在用户维护上有很大区别。微信的群用户关系相对比较固定，用户进群退群是相对低频操作，用户集合相对固定。而直播间里的用户进出是非常频繁的，而且直播间是有时效性的。实际进出直播间峰值QPS不会超过1万，使用Redis可以解决聊天室用户列表存储及过期清理问题。问题二：消息转发当一个500人的聊天室所有用户同时发送消息时，消息的转发QPS为500*500=2.5w。从直播用户端视角考虑：实时性：如果消息服务做消峰处理，峰值消息的堆积会造成消息延时增大，而有些信令消息具有时效性，太大延迟会影响用户的体验及互动实时性。用户体验：端展示各类用户聊天和信令消息一般一屏不会超过10-20条；如果每秒超过20条消息下发会出现持续刷屏的现象；大量的消息也会给端上带来持续的高负荷。因此我们为消息定义了不同的优先级。高优先级消息优先转发处理并且保证不丢弃；低优先级消息进行一定丢弃策略后再进行转发。问题三：历史消息业务上需要生成回放视频，需要获取历史信令、互动聊天等消息。要求能够快速写入历史消息以保证消息转发的时效性。消息的保存主要包含写扩散和读扩散两大类。我们采用读扩散的方式，读扩散可以减少存储空间，也可以减少消息保存的时间。考虑到回放的优先级不高，所以在存储组件的选择上我们选择了Pika。Pika是接口与Redis类似可以减少学习、开发成本。同时由于它是采用追加的方式，所以写性能可以与Redis媲美。问题四：消息顺序信令消息顺序的要求，需要保证同一个人发送消息的顺序，以及需要保证同一个聊天室内的用户收到消息顺序都是相同的。解决消息顺序可以使用Kafka之类的队列来保证，但是用Kafka有一定的延迟。为了降低延迟我们采用一致性哈希的策略来处理消息的转发，稍后会详细介绍。03设计目标打造稳定、高效的消息通讯服务端。提供高可靠、高稳定、高性能的长连接服务；支撑百万长连接同时在线；支持多集群快速部署，扩容；04服务架构从早期快速实现业务到后期的业务量上涨服务端的架构经历了几个阶段。架构1.0服务介绍服务设计综合考虑服务分为两部分，接入服务和业务逻辑服务。其中最核心服务是AccessServer和MessageServer两个服务。这两个服务的交互流程大致如下：从上图可以看出一个聊天室的人不一定全部都在同一台接入服务上，所以当一个500人的聊天室消息转发的时候服务端的QPS为500*500=2.5w的基础上再乘接入服务的数量。AccessServer接入服务维护与客户端TCP建立长连接。AccessServer主要的目标是处理网络IO数据包，采用异步非阻塞的方式提高并发性能。同时在内存中维护聊天室与用户的对应关系，保存聊天室相关缓存信息。解析与客户端的协议包。AccessServer主要处理的消息有两大类：客户端发送上行消息时，解析相关请求参数后将消息投递给MessageServer，由MessageServer获取路由信息并将消息投递给相应的AccessServer处理。MessageServer广播下行消息时，如果是单聊直接查询对应用户的TCP连接信息，封包、发送；如果是群聊消息时，遍历聊天室用户列表获取对应的TCP连接信息，封包、发送；在AccessSever维护聊天室与用户的映射关系可以减轻MessageServer与AccessServer交互的压力。MessageServer消息服务负责与Redis、Pika交互。将消息持久化到Pika。将聊天室用户列表、聊天室路由（聊天室的人分布在哪些AccessServer）信息、用户路由（用户在哪一台AccessServer）信息等信息更新到Redis，需要的时候从Redis查询相关信息。处理用户登录、退出、进出聊天室、单聊消息、群聊消息、涂鸦消息的转发逻辑。MessageServer如何来保证消息的顺序呢？首先AccessServer会根据按一致性Hash策略将同一聊天室的消息投递到同一台MessageServer来处理；接着MessageServer采用Hash策略将同一聊天室的消息转交到同一线程处理。我们来看下服务的线程模型：将网络数据处理和业务逻辑处理的线程隔离，避免业务逻辑处理阻塞网络线程造成TCP阻塞。网络线程采用Epoll的方式收发数据提高并发；业务线程专注业务逻辑处理，可以根据不同业务配置不同的线程池，比如上下线、进出聊天室、消息发送、不同优先级消息分配不同的线程组。缓存优化我们知道线程数越多性能不一定越好，因为线程上下文切换会带来很大一部分性能的开销。而且为了保证消息顺序性使用了线程池。如果全部依赖Redis会面临以下问题：新用户进入聊天室需要从Redis获取用户列表，而且用户上下线也会更新Redis聊天室用户列表、路由等信息，聊天室用户越多对系统的压力越大；业务场景上老师会加入几百个聊天室，这种场景会导致老师开课延时增加。每发送一条消息都需要从Redis查询聊天室的路由信息，假设网络IO+线程调度一次查询请求0.5ms，那么QPS也就2000，而类似涂鸦这类消息每秒15~20条消息，当负载持续一段时间后容易导致队列阻塞、任务超时等问题，容易引起雪崩。针对上面的问题，我们在AccessServer和MessageServer都做了二级缓存的策略，防止内存过载也在做了缓存淘汰相关策略：MessageServer会缓存聊天室用户列表、聊天室路由缓存，考虑缓存一致性会定时与Redis同步。用户进出聊天室的时候会将信息广播给对应的AccessServer，在AccessServer也会缓存聊天室用户列表，这样可以减少AccessServer和MessageServer之间的RPC压力。集群管理上一节介绍的服务组成一个集群，不同集群间目前不会相互通信。集群的管理是为了在业务上做隔离，因为不同的业务方在使用消息服务的时候要求性能不一样，最大程度的减少因为一个业务过载影响其它业务正常使用。同时可以根据不同业务方的业务量建设不同承载能力的集群，提高资源利用率。多集群的管理就需要DIspatchServer调度服务发挥作用了。客户端与服务端建立TCP长连接需要知道接入的IP和端口，客户端建立连接前会通过HTTP请求调度服务，调度服务会根据配置策略分配接入点的IP和端口给客户端。如下图：架构2.0当业务量增加以及业务场景多样化后，1.0架构的弊端也逐渐暴露出来：不同频率的消息会抢占资源，相互影响，比较涂鸦消息和信令消息；横向扩容MessageServer无法从根源解决不同消息相互影响问题，反而降低资源的利用率；服务拆分针对上面的问题将MessageServer进行拆分，分为三个服务：MessageServer：处理聊天室相关逻辑。包括进出聊天室、群聊消息、聊天室缓存管理、缓存同步广播。BinMsgServer：涂鸦消息处理逻辑。处理涂鸦消息逻辑。PeerMsgServer：处理单聊逻辑。包括用户上线、下线、单聊消息转发；服务拆分后服务间的状态同步、调用关系也发生了变化：拆分后就能根据业务对不同消息并发量不同扩容相应的服务，提高机器资源利用。AccessServer和HttpPushServer将不同的消息投递给不同服务处理。缓存升级架构升级后对缓存的策略也做了调整，MessageServer需要同步路由信息给BinMsgServer，同时BinMsgServer也需要做缓存一致性处理。新缓存策略：为减少非必要的RPC调用，在缓存同步的时候采取了一些规避策略：首先，MessageServer同步缓存给BinMsgServer的时候不是简单的在每次用户进出聊天室都同步给BinMsgServer，只是在聊天室路由状态发生变化时才会进行同步；其次，MessageServer不会将同一个聊天室路由信息同步给所有BinMsgServer，前面介绍了AccessServer会采用一致Hash策略将同一聊天室消息投递给同一个服务器处理，所以MessageServer也采用相同的一致性Hash策略将聊天室路由同步给对应的BinMsgServer；以上两步可以大量减少MessageServer和BinMsgServer之间的RPC调用，将资源充分用于消息转发处理上。架构3.0作为消息服务只局限于直播聊天的场景是不够，需要支撑更多的业务类型，比如IM、推送、透传等。如果在当前服务里去增加相应功能不仅对当前服务影响很大，也会加大后期维护成本。不同业务的要求都有些差别。直播聊天和IM虽然类似，但是对消息的要求不同。比如IM消息对消息的持久要求、一致性要求更高，而对消息延时要求会相对低一些。而推送场景和直播聊天建立连接的时机不同，直播聊天只需在用户进入直播室的时候建立连接，而推送则要求APP启动的时候就必须建立连接。从服务端的角度来看如果一种业务都搭建一套接入服务不仅在资源上浪费也会加大维护成本。从客户端的角度来看如果每种业务都建立一条TCP长连接会增加客户端性能的损耗，尤其是移动设备会增加耗电。为了应对业务的快速变更，3.0架构应运而生：3.0的架构是需要SDK配合升级。TcpProxyServer3.0新增了TcpProxyServer服务。该服务可以理解为是一个7层代理，不过协议不是HTTP之类的协议，而是自定义的协议。为了实现在一条TCP连接上承载多业务，我们抽象出了Session的概念，目前支持的Session包括Chat(直播聊天)、IM、学研Push、推送和透传。考虑后续快速支撑新业务，TcpProxyServer在设计成可动态配置业务转发路由，无需开发只需要修改配置文件就能完成业务的转发。2.0的客户端是直接与AccessServer建立TCP连接的，而3.0是与TcpProxyServer建立连接，TcpProxyServer将请求通过RPC转发给AccessServer。TcpProxyServer可以通过动态配置控制请求投递给后端服务的策略，包括轮训、Hash、一致性Hash等策略。随着客户端迭代升级，目前V3版的SDK用户已经占了70%左右。05未来规划连接迁移如果AccessServer过载过高或者异常重启后会导致用户重新登录、进聊天室，会出来大量进下线、进出聊天室消息的广播，对服务端和客户端都是不必要的性能消耗。目前我们正在做状态迁移的开发，AccessServer会将每个用户的状态保存起来，并且实时同步用户的状态用于恢复。当用户所在AccessServer-1因过载或重启后，对应的漂移到AccessServer-2的时候能够恢复最近在AccessServer-1的状态并且进行正常的消息转发处理，这种情况下对客户端是无感知的，也提升了用户的体验。QUIC目前，消息系统在稳定性和扩展性方面已经有了很好的表现，但是我们的学生用户遍布全国各地，用户的网络情况也千差万别，受限于TCP协议栈和操作系统，在弱网情况下我们很难在TCP协议的基础上进一步提高消息的实时性。由于TCP存在队头阻塞的问题，在弱网环境、丢包率较高的场景下消息延迟的问题就突现出来。对于QUIC而言，由于采用UDP可以避免上述的问题。扫描下方二维码添加「好未来技术」微信官方账号进入好未来技术官方交流群与作者实时互动~(若扫码无效，可通过微信号TAL-111111直接添加)-

背景：企业微信这两年在线下场景呈现爆炸性增长趋势，相比个人微信而言，企业微信有很多个人微信无法比拟的优势，比如品牌标识的加强，外部客户的管理，丰富的运营手段等等，说白了企业微信就是面向企业使用的，个人微信是面向个人使用的，定位的不同也决定了企业微信更加适合在运营、营销、推广方面来使用。经过

-好未来直播中台荣获「亚太内容分发大会」RTC技术创新奖服务网格在网校平台研发部的实践和思考深入容器之构建大型容器网络我知道你“在看”哟～

概要2021年6月9日，「亚太内容分发大会暨CDN峰会」在北京举行，直播中台受邀出席大会，冯权成老师代表直播中台出席大会的论坛「互动直播论坛」，并发表题为「实时音视频在教育场景下的成熟应用」的主题演讲，向业界介绍了好未来在RTC（Real

01服务网格方案介绍服务架构从单体发展到微服务，在云原生时代，微服务发展成服务网格。依托容器等技术，服务治理功能独立成基础设施层，与被治理的服务相互分离。1）服务治理介绍软件领域一直追求高可用、高性能、易扩展。在软件变得复杂之后，需要多人进行协作开发，服务的可用性、高性能和可扩展性受到越来越多的挑战。在一个庞大、复杂的单体服务下进行产品迭代，牵一发而动全身的窘境，简直是开发者的噩梦。为改变这种状况，很自然地会将单一庞大而复杂的服务做拆分，即进行服务化拆分。一个服务由多个微服务组成，微服务通过接口相互调用来提供完整的服务。软件架构大师马丁·福勒在2014年给出了微服务软件架构的综述性论文，译文见参考1。在微服务架构下，软件被拆分成有边界的、能独立开发和部署的、能相互通信的微服务。服务拆分成微服务后，服务的边界明确了，功能和逻辑也清晰了，维护起来也更容易了。随着spring

https://cilium.io/blog/2018/04/17/why-is-the-kernel-community-replacing-iptables(2019)

概述首先，web的免安装，即用即走的特性，再加上没有版本的限制，可以快速迭代或者试错，特别的适合一些业务场景，例如创新性业务，快速迭代业务，关于web能不能支撑直播业务，web直播性能行不行，带着这两个疑问，我们对web直播能力做了探索。通过读这篇文章你可以了解到到web、h5、小程序是否能够做直播，以下探索基于网校学研大班直播体系。01web1.0版本横空出世背景是产品侧提出讲座业务要重构，这时候天时地利人和都占有了，快速组建团队，耗时1个多月，做出了支持rtmp视频播放、即时聊天、投票、献礼物等功能，简单，够用。但天有不测风云，由于这样那样的原因，最终项目也没有上线，夭折了。你以为就此草草收场，那不是我们的脾气，继续发动每一个人的小宇宙。02web1.1版本初生牛犊不怕虎这个版本最大的亮点是要跟PC客户端进行功能追齐，那摆在我们面前有三个大坑需要填，一个是web的AI能力，一个是连麦中的rtc能力，还有一个是web的课堂互动拉齐。首先解决最难的，AI能力，通过探索，我们借助hark插件进行收音。this._speechEvents

告警分级都标注出来了，下面谈谈。其他的这里就不再展开了，其实做好监控是非常复杂的一件事情。如何与组织树和值班信息联动，如何进行告警的分类分级统计，如何进行告警流量清洗，这些都是很值得深入研究的。

背景：学而思网校直播课堂在线安装程序，是一个独立的应用程序，提供学生端的安装功能，为了减少安装包体积，避免引入第三方网络库，使用的是操作系统的WinInet网络库。为了更好的优化网络，提高网络连接的成功率，避免Local

前言：Java并发编程学习分享的目标Java并发编程中常用的工具和类用途与用法Java并发编程工具的实现原理与设计思路并发编程中遇到的常见问题与解决方案如何根据实际情景选择更合适的工具完成高效的设计方案学习分享团队学而思培优-运营研发团队Java并发编程分享小组：@沈健

你有多久没有静下心来，用心去阅读一本书～你还记得一口气读完一本书后，内心的畅快与成就感么？是什么原因让你逐渐远离了书和阅读？是快节奏的工作，让你每天忙碌在字符之间没有空闲阅读～还是当你想要阅读的时候，却突然发现手边没有合适的书？

背景：当前各个事业部前台均有不同的用户增长建模场景，数据特征的建设进度较为分散，形成数据孤岛。此外，大多数事业部不具备实时特征的生产能力，开发进度上也不一致，对于新用户的特征构建大多处于一个缺失的状态。基于此，中台在底层统一数仓、ID-Mapping技术、数据算法平台等统一底层建设的基础上，提出了全域特征池的概念。通过标准化特征数据生产、管理和服务的过程，打通数据算法一体化解决方案，提高算法人员的开发效率，为增长业务赋能。01整体项目架构特征生产层：特征的数据源主要为离线数据和实时数据两个部分。离线数据一般存储在hive中，通过hive/spark等离线特征生产框架进行特征处理后形成用户特征表、物品特征表、交互特征表三种特征表类型。如果特征需要提供特征服务的功能，则需要额外存储在hologres等KV数据库中。实时数据则一般通过kafka等消息中间件与holo中的数据进行交互，通过flink等在线特征生产框架对特征进行写入和更新。特征管理层：特征管理模块对特征表建立特征档案，并使用MySQL数据库作为存储介质，保存特征实例、标签信息、平台操作日志等信息。特征的产出方可以将符合平台规范的特征表进行注册上传至特征平台进行管理。特征池中的所有特征表默认对所有用户开放只读的权限。此后特征产出方对特征表进行修改（尤其是删除列、修改列、修改列类型等操作）时，需要重新注册特征表。平台方应当对用到该特征表的下游任务方进行通知。平台方应当管理特征的生产调度过程，以及特征的数据质量监控。当特征发生大的波动异常时，及时对特征进行下线处理。特征服务层：离线特征服务时，具有读取权限的数据平台用户可直接通过平台的相关组件进行数据访问，也即通过T-mining算法平台进行样本拼接、特征筛选的过程。如有模型服务和特征服务的需求，则额外需要通过统一的数据接口获取实时的特征。02特征使用流程如图，在算法应用中，有两种对特征的应用方式。一种是通过算法平台对样本和特征进行拼接，完成离线的训练和预测功能。而部分线上要求更高的算法场景，则需要实时获取用户的特征，通过模型服务的功能进行实时预测。离线场景下的特征使用场景在我们当前的大多数业务中更加频繁。我们现在的平台能力已能支持算法人员通过T-data+T-mining数据算法平台完成全域特征数据实际的应用过程，如下图所示：整个流程模板包括三个部分：输入（Input）、转化（Transform）、输出（Output），

前言：Java并发编程学习分享的目标：Java并发编程中常用的工具用途与用法；Java并发编程工具实现原理与设计思路；并发编程中遇到的常见问题与解决方案；根据实际情景选择更合适的工具完成高效的设计方案学习分享团队：学而思培优-运营研发团队Java并发编程分享小组：@沈健

脑科学实验室期待您加入也许你还想看“解放”技术人生产力，好未来开放流量回放平台源代码好未来数据中台｜学而思网校户外广告投放实战初探简述「培优呼叫平台」系统演进过程我就知道你“在看”

前言：批改移动端在此次重构的时候，技术选型上我们团队选择了Flutter来进行本次移动端的重构，因为使用Flutter可以在UI的开发效率上充分节省人效，可以把更多的时间放在其他方面的研究上。但是在实际开发中，有部分的功能Flutter是不支持的，还需要native端来进行支持，而如何使native端支持的功能可以方便的、高效的服务于我们自己的同时又可以对外提供便利，在其他项目或者是其他团队在需要使用同样功能的时候可以不需要重复的造轮子，如Java的jar包，Android的aar包，Web的npm包,

近日，继开源AI、PHP、GO等多个技术方向后，科技教育企业好未来宣布面向全行业开源“柯南流量回放平台”，旨在帮助各行业伙伴加强在服务端测试领域的人效和质量保障，“解放”技术人的生产力。柯南流量回放平台作为智慧教育国家新一代人工智能开放创新平台建设单位，好未来倡导开源、分享、共建的理念，致力于用技术推动行业发展。业务的线上质量与研发全流程的效率始终是技术从业者的关注重点。近几年，持续集成ContinuousIntegration(CI)和持续交付Continuous

导读：最近二十年，互联网/移动互联网取得了长足的发展，近几年来看，线上资源竞争越来越激烈、流量成本越来越高、产品同质化越来越明显，OMO的概念开始越来越火爆，我们集团作为教育行业领军企业，有着丰富的线下教学业务（学而思培优，智康一对一等）和线上业务（学而思网校，题拍拍等），教育OMO在公司也被视作发展方向之一，本文将介绍数据中台算法部与网校市场营销部在第二个“O（offline）”上的进行的相关合作尝试和技术沉淀。本次分享主要分为三个部分：背景介绍方案实践挑战与展望涉及了行业大图（OMO），行业子图（线下投放），通用能力（人群预估）三个层级的内容，涵盖了行业知识，人地关系等要点。01背景介绍一

前言我们知道，在一个技术领域里，随着技术的发展，最优解永远在变化。同样，一个业务系统也一样，从初期创建到承接的业务量和业务场景的不断变化，在不同阶段时，面临的问题和系统的设计思路也是不断变化的。之所以想分享一下系统演进过程，是因为每个系统的业务场景和发展阶段虽然不同，但在技术实现上，回归到系统本身的设计和优化思想是万变不离其宗的，不同发展阶段的技术变化也基本是遵循一定规律。所以，本篇文章通过结合培优呼叫平台随着业务发展阶段的变化而采用的技术手段和架构优化，去看一下系统架构设计一般会经历的阶段，以及每个阶段都解决了哪些问题，同时会引出哪些问题。系统发展总的来说，培优呼叫平台起步较晚，目前所处的阶段也是比较初级的（1.X），虽然系统启动建设时行业中服务化、数据分布式存储、缓存、异步等技术都已经非常成熟了，但也遵循着系统设计的规律进行的，是基于自己的系统建设背景、业务量级的变化，在不同阶段有不同的架构设计侧重点，并不是盲目的在项目初期就去为了应用服务化架构技术而直接应用微服务架构、分布式数据存储架构等。（盲目的/过度的追从复杂的技术架构，会出现问题难以追查、难以维护等多方面问题）>

近日，好未来旗下学而思网校的产品研发团队正式推出T-Slides未来课件。T-Slides

请点击【阅读原文】进行投递关于校招问题解答欢迎点击下图查看也许你还想看Clickhouse架构及应用好未来开源近600小时中英文混合语音数据集，填补教育AI研究空白【年度硬核干货】

内容大纲：背景；Clickhouse介绍；Clickhouse架构及性能；Clickhouse在好未来的实践；建设与规划；参考文献。1背景在日志中心发展早期，日志检索分析主要基于elasticsearch进行，随着日志中心接入的业务越来越多，数据量也逐渐增长，基于日志进行分析和监控告警的需求变得越来越复杂，很难用elasticsearch来满足，所以需要根据需求场景来选择合适数据库。我们需要的：数据量会很大，因此需要分布式；支持实时写入，支持快速计算，在较短时间内能完成计算；强大的sql能力，实时指标sql化；人力有限，运维需要简单；高效的压缩比存储，服务器有限，可以用更少的服务器存储更多的数据；基于以上特点，我们选择了Clickhouse，接下来会介绍Clickhouse的特点、系统架构以及使用情况。2Clickhouse介绍1、Clickhouse特点图2-1

作为教育科技的先行者，好未来近日开放了一批长达587小时教学场景中的中英文混合语音数据集。该数据集源自语种混合最具代表性场景之一——教师英语授课场景。好未来此次开放的数据集是迄今教育行业最大的语音开源数据集之一，也是目前已知全球较大的中英文混合场景开源数据集，有效填补了中英文混合语音识别研究的数据稀缺空白。算法、算力、数据是人工智能技术发展的三大基石。一个AI模型从设计到训练，再到部署使用，整个过程中，数据集的选择十分重要。高质量的数据集往往能够提高模型训练的质量和预测的准确率。由于行业的天然壁垒，智能教育领域目前开放的数据资源非常有限，而经过清理、标注、注释、结构化的数据，更为少见。作为教育行业内人工智能技术领域的代表企业，好未来很早就开始布局人工智能技术的教育场景落地，也在多年的实践中沉淀了大量优质教育资源和海量教学数据，并推动了多项智慧教育解决方案的落地。同时，作为智慧教育国家新一代人工智能开放创新平台的承建者，好未来肩负着为智慧教育行业关键技术创新提供支撑和服务的使命，将通过开源开放的形式，加速资源共享与技术融合创新。早在2020年3月，好未来就开放了第一批教育开源数据集——“小学低年级算式数据集”。该数据集包括33550张算式图像，均来源于小学1~3年级学生的数学练习册和作业，涵盖各类数学口算题目类型。每张图像经过手工剪裁，并提供相应标注。随后，好未来又陆续开放了手写中英文、手写公式、中文语音识别、语音情感等多个数据集。值得一提的是，好未来此前开放的手写公式数据集成为了第五届中国创新挑战赛智慧教育专题赛“教育手写公式识别”比赛的官方数据集。该比赛依托于智慧教育国家新一代人工智能开放创新平台，由北京市科学技术委员会与好未来联合承办，吸引了来自清华大学、北京大学、中国科学技术大学等国内高校及科研机构，以及阿里、腾讯、百度等一线互联网公司数百支队伍参赛。该数据集数据量更为丰富、数据场景更为复杂，均超过之前的同类开源数据。历经18年的高速发展，好未来已成为国内领先的科技教育公司。为实现技术资源共享与技术落地经验复用，好未来内部建立起跨业务的技术互通机制，积极推进技术中台建设，推动内部开源。这也是好未来对行业开源开放的坚实基础。随着智慧教育国家新一代人工智能开放创新平台的深入建设，好未来积累的大量教育场景数据集也会逐步开源开放。同时也将通过建立数据标准和数据服务机制，吸引更多的教育机构和科技企业，开放共享更丰富多元的教育数据，共同构建智慧教育行业生态体系。数据集下载方式点击【阅读原文】查看数据集详情，复制链接https://ai.100tal.com/dataset并使用电脑打开进行下载。详见下表也许你还想看20年好未来技术团队年度必读书单｜文末有福利好未来数据中台实时数据平台演进【年度硬核干货】

季羡林先生说过“书能给人以知识，给人以智慧，给人以快乐，给人以希望”。读书是人生成长道路上的必修课，提升自己最好的方式就是阅读。2021年春节马上就要到了，由于今年疫情的特殊原因部分老师可能无法回家与家人团聚。这个特别的春节正是各位提升与沉淀的最佳时机，小编从过去一年中好未来集团技术老师分享的书籍中，筛选出了如下12本书籍推荐给大家。希望大家在春节的假期里放松心情的同时，利用碎片化的时间学习成长、汲取营养，从而更好的迎接2021年的工作。一起来看看书单中都有哪些书籍吧～导读：这本书侧重于实战的技术书籍，其详细介绍了Jenkins2的核心特性

摘要：本文由好未来资深数据平台工程师毛祥溢分享，主要介绍批流融合在教育行业的实践。内容包括两部分，第一部分是好未来在做实时平台中的几点思考，第二部分主要分享教育行业中特有数据分析场景。大纲如下：背景介绍好未来

时光荏苒，2020年倏然而逝。全球新冠肺炎疫情的爆发，无论对个人、公司而言，还是对整个国家乃至世界而言，都带来了复杂严峻的变化。2020注定是极不寻常的一年。作为科技教育企业代表，好未来集团积极发挥在线教育优势，凭借强大的技术实力，支撑起全国在线免费公益课，这可以说是技术人第一次冲锋在了业务最前线，用代码24小时诠释着对教育的坚守与热爱，帮助校长、主讲、学科扫清在线教学一路上的技术难题，与业务伙伴共同撑起停课不停学的“避风港”。为数千万因疫情居家学习的孩子们传递知识。一场疫情加速了在线教育的发展，但同时也是对在线教育行业的考验和挑战。面对挑战及实时自我更新的好未来技术人，通过一次次挑战思考和技术升级不断去逼近能够做到的最好的极限。在线教育、AI人工智能以及双师课堂等等吸引着人们的注意力。然而，这些都离不开我们技术人的默默耕耘与付出，他们用一个个通宵一行行代码助力几近停摆的线下教育重新运转前进，凭借随脉搏一起跳动的信念与坚持，让更多人看到“教育+科技”的无限可能。希望这些在教育一线经过真金火炼，在各教育场景中得到反复验证的技术，能够给热爱教育科技的大家一点启迪！这里是好未来技术2020一整年的精华技术内容合辑，涵盖了好未来业务实践优秀案例、教育行业最全的中台组件技术知识以及通用基础技术能力方向的沉淀含服务端、大前端、直播等不同方向。本书内容页数530+，全部内容将近20万字，下面我们对整本书的内容做个简单介绍。本书共计分为三个篇章，具体如下：业务实践篇业务实践篇我们共计精选了6篇业务实战记录的技术沉淀。来自7位老师。内容不仅涵盖好未来学而思网校在提升用户体验方面的技术实践及数据指标体系的建设实践，也还有关于具体教育业务场景下的问题攻坚和思考。

01背景说明在业务开发过程中经常会进入一些三方sdk,这些三方的sdk引入so库,有些so库文件还比较大,这时候我们就需要考虑so库从网络获取异步加载,减少发布包的体积02传统方案关于so异步加载方案,网上的资料随便搜下大把,核心思想so库文件放到网络->下载到本地沙盒->通过System.load载入看起来挺简单的

“开篇诗词点题，结尾升华主题，非常赞！细节上，人物描写方法多样，人物的性格特点描绘细致；整体上，内容凸显文章主题，语言新颖清爽，读来令人如沐春风！”这是一份语文作文的批改反馈。不过，这份生动详细的批改反馈并不普通，它是利用好未来自主研发的“中英文作文批改解决方案”完成的。

文章整理自TiD2020质量竞争力大会赵明（好未来AI中台质量与工效负责人）《AI工程提效平台研发实践》演讲TiD2020质量竞争力大会邀请了好未来AI中台质量与工程效率部负责人赵明为参会者带来《AI工程提效平台研发实践》精彩演讲。赵明从准、快、稳三个关键词分享了AI算法指标与评测平台架构与实践、AI微服务性能测试平台架构与实践、数据集管理平台架构与实践以及相应的案例演示。准

引言

12月5日，由智慧教育国家新一代人工智能开放创新平台联合好未来集团共同举办、开源中国技术社区协办的“第一届PHP开源技术大会”在北京举行。大会汇聚PHP开源社区极具影响力的技术大咖，带来前沿技术实战干货分享。大会受到业内软件工程师和技术爱好者关注，近300人来到现场，千余名开发者通过线上直播参与其中。开源即开放源代码，正逐渐成为各个领域的事实标准，驱动全球范围的技术革新、模式创新和产业变革。本次PHP开源技术大会是好未来第一次举办开源方面的大型会议活动。好未来集团CTO田密发表开场致辞好未来集团首席技术官（CTO）田密作为大会主办方代表，发表了题为《用技术让世界更美好一点》的开场演讲。他表示，从前端技术到人工智能，科技正在全方位推动教育行业变革。好未来重视技术的长期价值，坚定构建高效、敏捷的技术中台，并依托智慧教育国家新一代人工智能开放创新平台，积极拥抱技术开源开放，把好未来历经教育场景验证迭代的技术能力与行业分享，并邀请心怀开源精神和教育理想的技术从业者，用一行行持续优化的代码，共同构建智慧教育新生态。田密表示，作为以爱和科技让教育更美好为使命的科技教育公司，好未来希望通过此次活动对业界未来的技术选型、研发思路有所帮助。TAL科技正让教育“更有趣、更有效、更有料、更有爱”好未来深耕教育培训行业17载，很早就意识到技术进步对于教育变革的深远影响，积极投身前沿技术与教育实际应用场景结合的探索实践中，成为最早一批全面换掉黑板，实现多媒体数字化面授教学的教育机构。同时，也是最早布局线上教育，开创双师模式的教育机构之一。值此移动互联、人工智能、大数据等技术风起云涌之时，好未来正用一系列覆盖教育全场景、全周期、全环节的科技教育产品和解决方案，为学生和老师提供“更有趣、更有效、更有料、更有爱”的智慧教育新体验。会上，田密分享了四个科技正以不同形式让教育更美好的案例。第一个案例是好未来自研T-Creator情境化互动教学课件创作平台。它大幅降低老师制作互动教学课件的技术门槛，只需半小时即可完成课件制作，让在线教学更有趣。第二个案例是为广大用户提供真人在线免费答题服务的“免费答题”APP题拍拍。题拍拍在高准确度拍照搜题技术、海量优质题库、清华北大答题官的共同加持下，可在14分钟内为用户提供正确的答案，还会给出答题步骤并辅之以清晰的语音解析，帮助学生迅速理清思路，让作业练习更有效。第三个案例是AI老师汉语学习系统。该系统是好未来旗下学而思网校为四川省凉山彝族自治州的学前儿童定制的，大山里的孩子从此有了“带不走的老师”。AI老师汉语学习系统深度融合语音识别、语义测评等技术，帮助彝族孩子打破语言障碍，打开通往山外广阔世界的大门，让语言学习更有料。第四个案例是好未来“停课不停学”行动。今年新冠肺炎疫情期间，好未来用科技搭建了教育的“避风港”，为行业开放好未来直播云的线上教学系统，帮助4万多机构和学校的14万名老师共渡难关；好未来智慧教育累计为全国49个市县的公立学校提供直播教学系统和学而思网校免费直播课，惠及500多万师生，保障“停课不停学”，让教育科技更有爱。在科技让教育更美好的过程中，好未来逐渐形成颇具“好未来特色”的技术体系，涵盖大前端中台、服务中台、直播中台、AI中台、数据中台、脑认知中台等在内的十余个门类清晰的技术中台，横向支撑包括学而思培优、学而思网校、小猴AI课、题拍拍等好未来旗下所有业务部门。同时，好未来不断加强与学术界的合作，和清华大学、斯坦福大学、中科院计算所、北京师范大学、华东师范大学等高校科研院所建立了人工智能、脑认知方向的联合实验室或联合科研项目，并获国家人社部批准设立博士后科研工作站。对前沿科技和学习科学源头创新的重视，也让好未来在科教融合落地成果不断涌现的同时，收获了一系列技术荣誉。好未来至今已获得200多项教育科技专利授权，并拥有600余项软件著作权，处于教育行业领先地位；数十项学术成果入选AAAI、WWW、AIED、NCME等国际顶级学术会议；更斩获世界计算机视觉领域顶级会议CVPR-EmotioNet竞赛冠军、世界人机交互与普适计算领域顶级会议UbiComp竞赛冠军、世界神经信息处理系统顶级会议NeurIPS教育主题单项挑战赛冠军、中国计算语言学大会CCL2020竞赛冠军等荣誉。好未来旗下学而思网校也连续三年入围中国互联网百强，并因“创新应用信息与通讯技术提高教学、学习和整体教育绩效”方面卓有成效的表现荣获联合国教科文组织表彰。TAL拥抱技术开源开放，共建教育新生态随着新一代信息技术的快速发展，开源已成为实现支持互联网、物联网、云计算、大数据、人工智能等领域快速发展的重要动力，成为信息技术发展的重要支撑。开源凭借着开放性、低成本、灵活性、安全性等特点，持续推动着全球软件产业的创新发展和格局演化。作为智慧教育国家新一代人工智能开放创新平台承建单位，好未来充分认知到，教育行业受众广泛、需求多样、场景复杂，相比互联网通用技术，教育科技有其自身的特点与要求。然而，目前在各大技术领域都缺少适配教育行业的高水准开源项目与资源。为了推动解决这一问题，好未来依托国家开放创新平台，全面推进教育行业开源开放工作，从2020年8月发布第一个开源项目以来，陆续上线30余个教育专属开源项目，包括以快速实现业务为主要目标，在好未来内部有多个团队项目正在使用的高性能PHP框架Fend；以及教育领域首个在线教学中文预训练模型TAL-EduBERT，在多个教育领域的NLP（自然语言处理）下游任务中得到了显著的效果提升。未来，好未来希望通过推动网络服务、数据存储、直播和框架服务等6大方向的组件开源，在教育各场景通用技术能力方面进行一系列开源动作，促进平台生态的参与者共享平台成果。好未来通用技术能力未来开源架构图同时，好未来开放了覆盖“教、学、测、练、评”各教学环节的10余项智慧教育解决方案，开放包括小学算数、手写中文、手写英文、手写公式等6大数据集，以及推动建设并对外开放了覆盖小学、初中、高中三个学段数学学科的知识地图。此外，好未来还通过承办中国创新挑战赛、举办开源技术大会、拥抱开源技术社区等多种形式，打造教育领域开源开放生态与文化，赋能技术创新者与中小教育机构。田密表示，无论是在好未来内部推进技术中台建设，还是面向行业推进技术开源开放，好未来技术体系都秉持着“开源、分享、共建”这一共通的理念，用历经海量教育场景验证迭代的技术能力，与行业协同创新，共同成就教育美好，这也是好未来作为一家科技教育企业的责任与担当。也许你还想看好未来举办首届PHP开源技术大会【网校事业部】基于线上流量回放的质量保障方案好未来斩获NeurIPS2020国际竞赛冠军我就知道你“在看”

随着AI能力从实验室逐渐走向市场，需要在特定应用场景下将神经网络模型执行预测到相应的结果。针对不同业务背景，云端智能化方案和用户端智能化法案也都处于快速发展的阶段。想要在网页上实现智能化的能力，达到特别效果，你会发现浏览器等载体下实现本地智能化实时预测是非常必要的。很多业界一线公司也都在布局web智能化，比如Google的TensorFlow.js，百度的paddle.js以及阿里淘系技术团队正在酝酿MNN.js，W3C也开始联合各大公司深入讨论WebNN规范的设计，未来AI能力将会渗透在更多的应用领域。作为国内第一个开源的web前端智能化开源方案paddle.js的发起人和设计者，王老师非常荣幸与大家一起分享web前端机器学习引擎的应用场景和实现原理。对于实现人工智能有很多方式实现，如机器学习就是一种特别接近于人的认知方式，就像田老师所描述的，“神经网络Neural