共计 3065 个字符，预计需要花费 8 分钟才能阅读完成。
简介：目前，作业帮曾经和阿里云有一个对于 AEP 的 tair 计划的联合，在新的一年心愿咱们有更大规模的落地。文章里讲得比拟多的是对于降本做的一些技术改良，其实在降本增效这外面还有很大一块工作量是经营，老本经营咱们也通过自动化实现了平台化，将来咱们将会进一步向 BI 化、AI 化去演进。
本文整顿自作业帮基础架构负责人董晓聪在云原生实战峰会上的分享，解说作业帮降本增效实际的路线上遇到的问题及教训，次要分为三个方面。一是作业帮的业务和现状，以及为什么要做降本增效。第二，如何和阿里云一起解决在降本过程中遇到的一系列挑战，最初是对将来技术趋势的瞻望。
背景
作者 | 董晓聪
作业帮成立于 2015 年，是一家以科技伎俩助力普惠教育的公司，公司次要的业务分为两大板块。第一，作业帮 APP 是一款典型的流量互联网产品，二是作业帮直播课，是一款典型的产业互联网产品，涵盖教育主播链条，如教研、教学、教务、辅导等。我是 2019 年十月份退出作业帮的，过后我看到作业帮的技术现状演绎为两点。一是规模化，另外是复杂化。
- 规模化：作业帮线上有数千个应用服务，这么多应用服务对应数万个服务实例，这么多的服务实例跑在数十万的计算外围之上；
- 复杂化：作业帮整体的技术栈是比拟多元的。
其中占比最高的技术栈是 Golang 和 PHP，还有大量模块是 C++、Python、Java 等进行编写的，作业帮守业之初就在云上，充沛享受了云计算的红利，起初因为一系列起因创立了多元的架构，性能疾速迭代也是咱们一贯的谋求。那为什么要进行降本增效呢？这个事之前也始终在做，只不过明天须要做得更好，其中有几点起因：
第一点，随着互联网红利的消退，企业心愿每一分钱失去最大的收益，实现老本效益最大化。第二点，尽管咱们始终在强调降本增效，但必定还是有不必要的收入存在，这些节约是应该被节俭的。第三点，作为技术人员的幻想，还是想写出更优质、更高性能的代码。在降本增效的过程当中要留神一点，降本不能降质，降低成本时稳定性、效率、平安不能打折扣。咱们看一下老本模型。
各种各样的个性和性能利用在计算机上其实是一个一个的代码模块，这些代码其实还是须要各种各样的资源来运作，有计算、存储、网络等等，那么咱们看一下这个模型里降本增效怎么来做。
首先公司必定心愿本人的用户越来越多，应用越来越沉闷。其次，在利用侧降本增效做的事件就是要晋升单位算力承载量，艰深来讲就是 QPS。但咱们面临的一个挑战就是作业帮技术栈太多元了，咱们如何整体晋升？再看资源侧，存储、网络这些资源要么是刚需，要么就是很难管制老本。资源侧降本的重点还是计算资源，而对于计算资源咱们须要晋升单位成本的算力。
咱们面临的挑战是什么呢？就是如何抉择更优的机型以及在抉择完机型之后，如何让业务更加疾速、无感、平滑的过渡过去。在利用和计算资源的两头还有一块微小的晋升空间，就是两者之间的匹配和部署的问题。在部署侧咱们也面临一些艰难和挑战。
第一，咱们在线业务集群的负载并不高。对于高吞吐的业务个别作为外围业务，这些业务要留肯定的闲暇。对于低负载的业务要有碎片化和长尾化，把线上负载率拉低了。一方面是在线业务负载并不高，另外一方面是大数据离线计算要贴地进行，造成空间不均，还有工夫上的不均，互联网业务有显著的波峰波谷。在线教育更加显著，波峰波谷会差两个数量级，咱们始终在为波峰进行买单。
如何做到降本增效
下面列举了相干的问题和挑战，作业帮是如何来做的呢？咱们抉择和阿里云一起，抉择开源的力量再联合肯定的自研进行相干问题的解决。在利用层面，咱们晋升了支流技术栈的运行性能，对于应用最多的检索服务进行架构的重构，以此来晋升性能和运维效率。
在部署侧，通过 GPU 调度、ECS，在离线混部解决空间和工夫的不均。在资源 K8s 技术实现利用通明无感，这样替换机型变得更加快捷。
上面基于利用、部署简略来聊。
利用这一层对支流技术栈进行优化。第一，咱们是从新编译，咱们以 FastCGI 运行，对非线程平安进行编译，还有服务注册发现，摒弃之前传统基于名字服务，为了进一步晋升性能和成功率，咱们还做了 LocalDNS，应用更新的内核 4.10+，和阿里云内核团队进行相应的调优、优化解决一系列问题，解决 IPVS 过多的性能和稳定性问题。
最初得益于 Terway 网络以及网络做的长久化，能够对性能有更显著的晋升。实现之后裸框架能够有几倍的晋升，能够带来 43% 左右的收益。检索服务作为底层服务，对其性能要求比拟高，传统架构个别是计算存储耦合在一起的，随着底下文件数量越来越多，单机无奈包容，要进行切片。每个切片要高牢靠、高性能，由此造成二维矩阵，这种状况下存在诸多的问题，比如说像数据更新周期长、整体运维效率并不高，还有零碎的瓶颈迟迟得不到解决。
要解决上述问题要做计算和存储的拆散，咱们引入 Fluid 做一个要害的纽带。Fluid 是一款基于 K8s 的数据编排零碎，用于解决云原生过程中遇到的拜访数据过程简单、拜访数据慢等一系列问题，JindoRuntime 用于实现缓存的减速，当咱们应用 Fliud 和 JindoRuntime 实现整个检索系统的重构之后，取得的收益也比拟显著。
首先，作业帮的数据更新周期从之前小时级别缩短到三分钟以内，运维整个机器交付从之前天级别缩短到了小时级别，程序性能也失去大幅度晋升，晋升比例有 30%，带来了万核级别资源的缩减。
咱们再聊一下部署侧，作业帮线上有大量 AI 推理类业务，不光是图像识别 OCR、语音辨认、合成这一块。这些业务计算 GPU 长时间脱离整个运维体系，咱们心愿通过容器化革新将其纳管到对立运维体系里来。咱们调研业界支流的技术计划，它们或多或少都会对 GPU 性能造成肯定损耗，最初咱们抉择了阿里云开源计划实现了 GPU Share 的调度计划。
作业帮 GPU 服务所应用的算力和显存绝对比拟固定，咱们就实现了一套匹配机制。相似经典的背包问题。当实现整体一套之后，线上 GPU 资源的使用率失去了大幅度的晋升。在离线混部是工程畛域比拟经典的问题，一方面是在线集群在波谷时有大量的闲暇资源，另一方面大数据离线计算须要海量的计算资源，同时离线计算对时级要求并不高，所以两者联合会有双赢的后果。
但之前很大的技术瓶颈在于如果混部在一起，离线计算大量生产 CPU 和网络资源，会使得混部的在线资源服务成功率以及时延有大幅度的降落，应用阿里云 CFS 实现 CPU 的避让，实现空白避让以及混部。截止到目前，有万核级别的计算跑在在线集群上，为了进一步保障线上稳固，咱们在晚顶峰也做实时的调度，将离线计算份额进行缩减，实现这一套之后失去了兼顾稳定性和老本的计划。
作业帮整体 CPU 资源有三个池子，一个是 online CPU 机器，一个是 GPU 的 CPU 机器局部利用起来，第三局部是 ECI，通过 Pod 数目加减实现策略，包含定时 HP 策略，像一些 AI 模块，只有在固定课程才会利用到，咱们提前将课表导入，在上课之前把相干服务提起即可，咱们也给线上服务减少肯定 AutoHP 的策略。
将来瞻望
将来，作业帮会将定时业务、AI 计算迁到 ECI 之上来实现真正在线业务的削峰，并且咱们将继续摸索更具性价比的 IaaS 资源，这也是咱们始终尝试和摸索的方向。目前，作业帮曾经和阿里云有一个对于 AEP 的 tair 计划的联合，在新的一年心愿咱们有更大规模的落地。文章里讲得比拟多的是对于降本做的一些技术改良，其实在降本增效这外面还有很大一块工作量是经营，老本经营咱们也通过自动化实现了平台化，将来咱们将会进一步向 BI 化、AI 化去演进。
原文链接
本文为阿里云原创内容，未经容许不得转载。
