开发者学堂课程【云原生最佳实践案例：实战案例——作业帮】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1052/detail/15275
实战案例——作业帮
内容介绍：
一、技术现状
二、背景和目标
三、成本模型
四、部署挑战
五、解决路径
六、应用层运行态
七、应用层检索
八、容器技术 GPU 共享
九、容器技术 在离线混部
十、容器技术 弹性扩缩
十一、展望
作业帮成立于2015年，以科技为手段致力于教育的公司，主要业务分为两大板块，第一是作业帮APP是一款面相于K12的学习辅助工具平台，是一款典型的流量互联网产品，另一块是作业帮直播课，是一款典型的产业互联网产品，含盖了教育的诸多链条，如教学教研教务辅导等等。
一、技术现状
2015年作业帮主要技术现状分为两点，一点是规模化，另一点是复杂化。规模化是指作业帮线上有数千个应用服务，这么多的服务对应了数万的服务实例，而这些服务实例是跑在数十万计算核心之上。复杂化是作业帮整体技术站，比较多元，更多的模块是Java，C++等进行编写的。作业帮从创业之初就是在云之上，充分享受了云计算的红利，也由于一些原因，建成了一个多元应用架构，高可用，性能快速迭代也是我们的一贯追求。
二、背景和目标
降本增效需要做的更好，有几点原因，第一点是随着互联网红利的消退，企业希望每一分钱利益最大化，另一点是虽然一直在强调降本增效，肯定还是有一些不必要的支出存在，应该被节省。最后一点是作为一个技术人员的追求，希望写出更优质更高性能的代码，在降本增效的过程中需要注意一点，降本不能降质，降低成本同时稳定性、效率、安全均不能打折扣。
三、成本模型
各种各样产品的特性功能映射到计算机的世界后，是一个个的代码模块，它想要work需要各种各样的资源。降本增效应该如何做，在应用模块中，降本增效是主要提升单位承载量，但面临的一个挑战是作业帮技术站太多元了，如何去进行整体提升。在资源模块中，像存储网络这些资源，不是使用比较刚性，就是没有多少利益可以控制。降本的重点在于计算的资源，也就是在提升单位成本算例。一些相关的挑战是如何选择更优的机型，以及选择后如何让业务更加快速平滑过渡。在应用和计算资源中间，还有一块巨大的可提升空间是两者间的匹配。
四、部署挑战
第一个挑战是在线业务资源负载低，要为核心业务留下资源，会有一定的空闲，对于一些低负载业务，往往会产生碎片化。线上的负载率被拉低了。一方面是在线业务负载低，另一方面是大数据离线计算要贴地运行，会有空间不均，还有时间不均。互联网业务会有明显的波峰波谷现象，在线教育会更明显，波峰波谷会差两个数量级。而我们在为波峰进行买单。
五、解决路径
作业帮在应用层面，提升了一个主流技术站的运行性能，对于使用资源最多的检索服务，进行了架构重构，以此来提升性能和效率。在部署层面，通过GPU调度、ECS、在离线混部解决一系列空间时间不均。在机型层面，实现了应用对资源的透明模板，在替换机型的时候变得更加快捷。
六、应用层运行态
对主流技术站进行优化，主要有进行重新的编译，以fastCGI进行运行，对它进行了非线程安全编译以提升效率。另一块是在服务的注册发现，摒弃了传统的名字服务，整体切换到云原生服务，以此大幅度提升性能，为了进一步提升性能和成功率，还做了一层localDNS，在内核层面使用更新的，也和阿里云内核团队进行了相关的优化。来解决性能和成功率问题。最后就是得益于Terway 的容器网络+网络连接持久化，进一步对性能更明显的提升，完成后，框架会有几倍的性能提升。将它提高到业务里面，降本带来43%的收益。
七、应用层检索
检索层作为底层的服务，对其性能要求比较高，在传统架构里，一般是计算和存储里融合在一起，随着文件数量越来越多，单机无法容纳，需要对它进行数据切片，每个切片为了保证高性能，需要多个副本，如此形成了二维的矩阵，在这种情况下，存在的诸多问题，首先要做计算和存储的分离，引入了Fluid做一个关键纽带，它是基于K8S数据编排的系统，解决原生过程中一系列问题。JindoRuntime是用于实现缓存的加速，当我们使用Fluid和JindoRuntime完成整个检索系统重构之后，获得的收益也比较明显，首先数据的更新周期，从小时级别缩短到三分钟之内。运维的提交速度从天级别缩短到小时级别。程序性能也得到了大幅度提升，提升比例由30%带来了万核级别缩减。
八、容器技术GPU共享
作业帮线上有大量的AI推理业务，不论是图像识别或者是云识别和合成。但是之前的计算GPU服务长时间脱离统一运维体系，希望通过改造将其纳管到运维体系中。但是在调研主流的业务方案，或多或少都会对GPU性能损耗，最后选择了阿里云开源方案，实现了一套GPU share的调度方案。我们的GPU服务是用的算例相对比较固定，以此实现了一套资源服务匹配机制，例如经典的背包问题，当完成整体一套后，线上的GPU的资源使用率得到了大幅度提升。
九、容器技术 在离线混部
在离线混部一直是工程领域比较经典的问题，一方面是在线集群在波谷的时候有大量空闲资源，另外大数据的离线计算需要海量资源，离线计算对数据的实例要求不高，在小时左右内出数是可以接受的，两者间的结合会有一个双赢的结果。但之前很大的技术瓶颈在于，混在一起，离线计算会大量消耗CPU和网络资源。会使得一些混部的资源成功率，会有大幅度的下降。使用阿里云改造后的CFS来实现了CPU的避让，实现了在线服务和离线计算的平稳混部，截止目前，已经有一个万核级别的离线计算跑在在线集群上。同时为了更进一步维持稳定，在晚高峰时，会做一些实时调度，将计算份额进行缩减。我们得到了一个兼顾稳定性和成本的方案。
十、容器技术 弹性扩缩
作业帮的整体CPU资源会有三个池子，一个是大量的CPU机器，另一块也把机器CPU部分利用起来。第三块是通过数目的加减实现弹性策略，会有一些人工干预策略，也会有一些定时的HPA策略，留下一些AI模块，只有在固定的课程时，才会用到，只需要提前将课表进行导入，在上课前将相关服务启动，为了让线上服务应对一定的突增流量，我们为相关的服务增加了AutoHPA策略。
十一、展望
虽然现在已经将定时任务以及部分的AI计算已经迁到ECS之上，但是我们认为在线服务，部分也可以做到迁到ECS之上，来实现一个真正的在线业务学峰，另一方面是探索更具性价比资源，我们之前也一直在尝试探索，在Redis领域开始使用跟阿里云一些方案的结合，在新的一年希望达到更大规模的落地，在降本增效这一方面还有很大的一块工作量在运营方面，整体的成本运营通过之前的自动化平台化，未来会向AI化更进一步。
