猿辅导校招提薪!平均30W,SP更高!我们的技术优势在哪儿?
猿辅导2019年校招内推提前批面试已经火热开启!hr姐姐透露今年校招offer提薪的消息!不过要拿到这么给力的offer,需要我们技术功底扎实过硬!
那么猿辅导的技术优势在哪儿呢?下面就是满满的干货啦!猿辅导公司的技术大牛分享了一些公司所遇到的技术挑战,希望对同学们有所帮助:
公司正在发力在线教育的各个方向,各种项目很多,这里简单说几个我所了解到的技术挑战。
1、高质量的直播平台
和秀场类这种单向、表演性质的直播不同,我们的直播平台是为教育场景而设计的,需要支持多人音视频互动,因此在技术挑战上完全不一样。主流的基于CDN推流的直播架构,常态会是几秒钟级别的端到端时延,而流畅的音视频互动需要把时延降到百毫秒级别。CDN推流方案首先协议上是基于TCP的,而我们知道TCP不是为实时传输而设计的,在发生网络丢包、拥塞的时候时延会急剧增大。再者多级的CDN节点也会增加网络传输的时延。因此我们基于UDP来实现整个音视频协议,还做了很多应用层路由优化和抗丢包优化来提高网络传输的质量。但是对于网络的优化是无止境的,我们还需要非常多的努力来保证最佳的直播体验。
除了网络协议,维护直播教室的状态也是一个困难的问题。因为直播教室是有复杂状态的, 而基于扩展性、实时高可用考虑,我们需要让同一教室的状态在复制到多个服务节点上。用户可以连接到任一服务节点上,当房间状态变迁时,怎么解决不同节点的状态一致性问题,也是我们面临的一个挑战。
1、高质量的直播平台
和秀场类这种单向、表演性质的直播不同,我们的直播平台是为教育场景而设计的,需要支持多人音视频互动,因此在技术挑战上完全不一样。主流的基于CDN推流的直播架构,常态会是几秒钟级别的端到端时延,而流畅的音视频互动需要把时延降到百毫秒级别。CDN推流方案首先协议上是基于TCP的,而我们知道TCP不是为实时传输而设计的,在发生网络丢包、拥塞的时候时延会急剧增大。再者多级的CDN节点也会增加网络传输的时延。因此我们基于UDP来实现整个音视频协议,还做了很多应用层路由优化和抗丢包优化来提高网络传输的质量。但是对于网络的优化是无止境的,我们还需要非常多的努力来保证最佳的直播体验。
除了网络协议,维护直播教室的状态也是一个困难的问题。因为直播教室是有复杂状态的, 而基于扩展性、实时高可用考虑,我们需要让同一教室的状态在复制到多个服务节点上。用户可以连接到任一服务节点上,当房间状态变迁时,怎么解决不同节点的状态一致性问题,也是我们面临的一个挑战。
2、功能强大的云端容器
当前STEM教育和青少年编程教育走上了快车道,我们也推出了推出了猿编程系列课程,并研发了适合线上场景编程和AI教育的在线IDE平台。这样一个运行平台也和传统的编程平台很不一样,它们一般是将程序设计语言转化为JavaScript并在前端运行,但这类平台普遍无法支持复杂的功能。我们的在线IDE平台给学员提供了各种AI模型的调用,从而让我们的学员有机会建立从感性到理性的认知。
不同于OJ平台提交代码的简单交互,猿编程IDE需要给用户提供从输入、输出到弹窗、播放音视频的全面交互方式,让师生在感受在线IDE便捷的同时,获得媲美本地的交互体验。这给我们前端和后端的研发都提出了很多的挑战。比如说,为了支持上述全交互的特性,我们需要给每个学生都提供一个完整的运行环境,而学生们在猿编程IDE的操作,会导致大量密集的容器级指令。在这种场景下,普通的Kubernetes平台性能不能达到我们的需求,因此我们也需要自己开发容器管理系统,来支持高并发的自动部署和扩展。
3、微服务架构下的开发流程
我们几年前就全面的开始使用微服务架构进行开发,随着功能的不断迭代更新,我们也碰到了非常多的挑战,一个典型的问题就是如何保证系统的一致性。在单体应用中,只要服务本身是无状态的,一致性问题一般可以通过数据库事务的方式来解决。可是在分布式系统中,由于CAP定理的限制,高可用性和严格的一致性难以同时满足,各个服务之间只能通过消息来维护最终一致性,而这是一个比较弱的保证,会导致很多隐晦的一致性问题。
系统中需要多个服务配合才能完成一个功能,状态和逻辑散落在各处,为避免错误需要在开发过程中思考整个流程的交互细节,这就大大增加了开发同学的心智负担。因此我们在努力的总结微服务架构下的开发范式,已便于大家愉快的写代码。比如我们采用领域驱动设计(DDD)的理念,来更好的抽象我们的系统划分和服务边界。我们研究了CQRS、长时事务(Saga)、TCC事务等一些开发范式,应用到各种场景中。我们也在调研各种基础设施希望能够更好的支撑我们的需求,比如切换到带有顺序保证的消息系统,就能够减少部分消息乱序带来的问题。
我们几年前就全面的开始使用微服务架构进行开发,随着功能的不断迭代更新,我们也碰到了非常多的挑战,一个典型的问题就是如何保证系统的一致性。在单体应用中,只要服务本身是无状态的,一致性问题一般可以通过数据库事务的方式来解决。可是在分布式系统中,由于CAP定理的限制,高可用性和严格的一致性难以同时满足,各个服务之间只能通过消息来维护最终一致性,而这是一个比较弱的保证,会导致很多隐晦的一致性问题。
系统中需要多个服务配合才能完成一个功能,状态和逻辑散落在各处,为避免错误需要在开发过程中思考整个流程的交互细节,这就大大增加了开发同学的心智负担。因此我们在努力的总结微服务架构下的开发范式,已便于大家愉快的写代码。比如我们采用领域驱动设计(DDD)的理念,来更好的抽象我们的系统划分和服务边界。我们研究了CQRS、长时事务(Saga)、TCC事务等一些开发范式,应用到各种场景中。我们也在调研各种基础设施希望能够更好的支撑我们的需求,比如切换到带有顺序保证的消息系统,就能够减少部分消息乱序带来的问题。
4、极速的拍照搜题体验
小猿搜题拍照识别是我们用户最多的产品,我们希望提供给用户最快的搜题体验。而延迟的很大部分来自于用户上传照片的过程,这也成为我们必须要优化的关键步骤。普通的上传文件操作都是基于TCP来实现,但是TCP不是为了实时传输而设计的,它的拥塞控制算法和Head-of-Line Blocking 等问题的存在,导致无法高效地利用带宽,尤其是如今的网络环境,很多是高带宽、高时延的"LongFatPipe", 或叫Elephant网络。
因此我们自研了用户态传输层协议Kel来处理实时可靠传输的场景,从而降低了用户上传图片的时延。实现这样一个传输协议是一个很大的工程,我们必须自己来处理传输过程中丢包重传、冗余部分、保持连接等各种问题。目前Kel协议已经得到了成功的应用,但还要很多的方向需要我们去进一步的优化完善。
上面聊到的一些挑战,当然还只是我们工作的一部分。归根到底,所有的技术挑战都是对我们开发同学能力的挑战,需要不断的学习新的技术理念,不断总结各种工程经验,既要能够对复杂的问题进行抽象,又需要真正脚踏实地处理好细节。所以我们也提供了多种不同形式的培训和分享来帮助团队成员来成长。即有每周一次全司的技术分享,覆盖工作内外各种技术话题,也有各组内的集体学习,针对特定问题提升能力。对于新入职的毕业生,我们还有为期三个月包含二十来个专题的新人培训,每个专题会包含6-8个钟头的课前阅读和4个钟头的集体讨论,来帮助大家夯实工程理论基础。
小猿搜题拍照识别是我们用户最多的产品,我们希望提供给用户最快的搜题体验。而延迟的很大部分来自于用户上传照片的过程,这也成为我们必须要优化的关键步骤。普通的上传文件操作都是基于TCP来实现,但是TCP不是为了实时传输而设计的,它的拥塞控制算法和Head-of-Line Blocking 等问题的存在,导致无法高效地利用带宽,尤其是如今的网络环境,很多是高带宽、高时延的"LongFatPipe", 或叫Elephant网络。
因此我们自研了用户态传输层协议Kel来处理实时可靠传输的场景,从而降低了用户上传图片的时延。实现这样一个传输协议是一个很大的工程,我们必须自己来处理传输过程中丢包重传、冗余部分、保持连接等各种问题。目前Kel协议已经得到了成功的应用,但还要很多的方向需要我们去进一步的优化完善。
上面聊到的一些挑战,当然还只是我们工作的一部分。归根到底,所有的技术挑战都是对我们开发同学能力的挑战,需要不断的学习新的技术理念,不断总结各种工程经验,既要能够对复杂的问题进行抽象,又需要真正脚踏实地处理好细节。所以我们也提供了多种不同形式的培训和分享来帮助团队成员来成长。即有每周一次全司的技术分享,覆盖工作内外各种技术话题,也有各组内的集体学习,针对特定问题提升能力。对于新入职的毕业生,我们还有为期三个月包含二十来个专题的新人培训,每个专题会包含6-8个钟头的课前阅读和4个钟头的集体讨论,来帮助大家夯实工程理论基础。
btw.公司现在校招正在火热进行,目前招聘深度学习研发,web前端研发,客户端研发和服务器研发四个岗位,有意向的同学们可以登录官网直接报名 传送门:hr.yuanfudao.com