《原动力 x 云原生正发声 降本增效大讲堂》第七讲——作业帮云原生降本增效实践之路原创

各位网友大家好，欢迎观看原动力云原生正发生降本增效大讲堂系列技术直播。本次大讲堂是由中国信通院、腾讯云fio产业标准工作组联合策划，目的是与开发者一同交流提升资源利用率、降本增效的方法与优秀实践。今年大讲堂将分为三期共十讲，那第一期聚焦在优秀实践方法论、资源与弹性架构设计，那第二期呢？聚焦全场景赛、离线分布Co GPU资源效率提升、Co资源拓扑感知调度主题。第三期将邀请四家业界知名企业分享企业云原生降本增效技术实践，从而给开发者带来更多样化的场景业务下的技术干货啊，那期待已久的我们第三期直播来了，今天是该大讲堂的第七讲，直播主题是作业帮云原生降本增效实践之路。

今天我们也请到了作业帮基础架构负责人董晓聪来为我们分享作业帮云原生降本增效实践之路，我们有请董晓聪老师。大家好，我是董浩聪，嗯，今天很高兴来参加中国信通院腾讯云分OS产业标准工作组一起举办的原动力原生政发声降本增效大讲堂。啊，我现在在作业帮这边担任基础架构的负责人啊，负责作业帮的架构研发，运维D安全相关的工作啊，同时也是腾讯云原生方向的TVVP，嗯，今天我跟大家分享的主题是作业帮基于原生的降本增效实践支柱，呃，下面我就开始今天正式的一个分享。嗯，我会分成这么几个部分来讲，嗯，首先来介绍一下我们为什么要进行降本增效，嗯，这里面会做一下背景的介绍，嗯，这帮是一家什么样的公司啊，我们的技术现状是怎么样的？嗯，第二块呢，会基于架构的全貌啊，来看一下降本增效的关键技术点是哪一些？

嗯，接下来我会围绕这些关键点展开来讲啊，比如在应用层，我们是如何通过呃，应用技术站和核心系统的原生改造啊，来实现降本增效的啊，以及在资源调度层，我们是如何进行降本增效的。嗯，最后进行一下相关的一个总结。嗯，先来介绍一下作业帮啊，作业帮成立于2015年，是一家用科技手段助力普惠教育的公司，嗯，公司主要带的业务板块有两块啊，一块是做业帮APP啊，是一款面向于K12的呃学习辅导工具平台，是一款典型的流量互联网的产品。呃，另一块业务是作业帮直播课啊，这是一个产业互联网的产品，涵盖了教育的诸多链条啊，如教研，教学，教务辅导等等，除此之外呢，公司也在一些新的方向啊，如教育硬件上啊，有一些呃布局和探索。

嗯，我是2019年底加入作业帮的，呃，当时我看到的公司的技术现状可以归纳为两点，呃，规模化和复杂化。呃，规模化这块是指啊作业帮的呃，线上服务比较多呃，一共有数千个呃，对应了数万的服务实例，呃，而这么多的一些服务实力呢，是运行在数十万的计算核心之上。啊，复杂化这块呢，是指作业帮的技术占啊，极为丰富啊，基本上主流的语言都有啊，其中像PP啊，架构量因能够占到总数的60%，呃，除此之外呢，还有大量的系统使用，呃，Noe JS Java CI加Python等进行编写。

嗯，即使是同样的技术站啊，也会因为不同的团队特点啊，业务特点呈现出一些较大的差异，嗯，所帮从2020年初开始选择走一条原生的道，来解决发展过程中啊所遇到的一系列的稳定性，成本、效率呃，安全上的问题。通过原生的改造啊，用基础设施去接管业务当中的大量非功能逻辑啊，以此来实现弹性、可观测性、韧性、自动化、可持续等相关的一些特性啊，即使现在回想起来，当时做这个事情啊，其实还是挺有魄力的一件事。因为它毕竟是一个啊公司底层技术的重塑啊，截至今天啊，已经公司已经完成了96%业务的容器化改造啊，95%的业务也已经达成了一个混合云多活架构，呃除此之外，我们还建设了一套完备的呃微服务治理体系呃涵盖了基于靠DNS加IPVS的呃原生注册发现机制呃同步和异步流量的治理。

呃，全面的感知能力，呃，一套以应用为中心啊，贯穿整个应用生命周期的DAO s offs体系。呃，我们来讲一下我们为什么要进行降本增效啊，其实这个事情我们之前也一直在做啊，比如像在学习架构下啊，通过服务的稳步呀，啊业务的优化，其实我们已经将整个资源的利用率，嗯，做到一个较高的水平啊，但今天呢，啊，公司在这块的一个要求是持续的啊，甚至说是更高的。首先是随着互联网红利的一个消退啊，公司其实是希望每一分钱都能够去产生一个更大的一个价值啊，实现成本效益的最大化啊，其次，虽然我们一直强调啊成本的管控，但是资源的浪费其实还是普遍存在的啊，举个例子啊啊，比如说呃，某些应用服务器，它的负载只常年只有10%，呃，但却在独享的机器资源。

再比如说啊，一些历史的不再使用的日志啊，一直占据着存储的资源啊，没有去进行有效的归档或者删除等等诸如此类的事情其实还很多，这些不必要的开支是需要被节省的，嗯，最后呢，就是一个技术从业人员的一个追求吧，啊，作为程序员其实还是想写出更好啊，更高性能的代码。嗯，在进行降本增效的同时，我们要明确一点啊，降本但不能降至啊，降低成本的同时，稳定性、效率、安全等均不能为此打折扣。呃，举个例子来说啊，我们不能为了去控制服务器的成本，呃，人为去缩展系统的一个并发量。这样做就舍本求末了，呃，业务的发展才是一切技术建设的前提，呃，亦或者为了嗯，极限的成本管控，嗯，大幅度去缩减嗯，监控。

链追踪日志的一个存储量啊，让研发需要花更大的精力，更多的时间来去分析跟解决线上的问题，这个也是不可取的啊，技术效率的提升能够使公司在有限的投入情况下。呃，有更大的一个产出，呃，那么在这么多的一些限制条件下，我们应该如何去开展降本功效，降本增效的工作呢？呃，下面基于架构全貌来进行一个分析。嗯，架构我们从大的层次上可以分成两层，应用层和资源层啊，用户广泛的使用我们的产品啊业业务和产品映射到技术的世界，是一个个应用模块。呃，这些应用的运行需要各种各样的I资源，如计算，存储网络等等啊，计算了，包括各种样的裸金属啊，虚拟机以及一些异构的计算。

呃，存储的话包含了呃块存储，文件存储，对象存储等等，呃网络包含的实体就会更多一些。我们先看了一下在应用层啊，我们应该如何进行降本增效呢？我们首要做的事情就是要去提升应用层的一个性能啊，也就是在单位资源下啊，可以去支撑更高的一个业务并发量啊，通俗点说也就是一个服务的QPS。而这块作业帮面临的一个挑战在于哪一块呢？呃，就是我们的技术专业实在是太多元了，呃，面对这么数千个异构应用，我们该如何下手呢？呃，我们再来看一下资源这一层，呃，存储啊，网络这些的成本，呃，要么对一个公司的总的it支出来说占比比较低，呃，要么它就比较刚性，没有多少油水啊，所以我们资源层降本增效的一个重点还是在于计算这一层，呃计算这块的呃，两个挑战是是什么呢？是，呃，第一我们是如何去寻找一款更优的机型，呃，提升单位成本价的一个算力，呃另一块呢，就是我们有了合适的机型啊，如何实现业务的平滑无感的一个切换。

嗯，除了这两层之外呢，在应用和计算之间，还有两者的匹配啊，也就是资源调度层啊，这一层同样有着巨大的优化空间，嗯，这块也面临着一些诸多挑战啊，主要有这么几大类。呃，第一块呢，就是在线服务，呃，资源的利用率不高啊，我们可以分成这么两派来讲，呃，像高并发的业务，其实为了去频繁的，嗯去为了去应对频繁的流量突增啊，需要保证一定的八法。呃，对于第流量业务呢，为了保障其高可用呃，较容易出现碎片化呃，而这类业务的又特别的长尾呃，进一步去拉低了在线服务的呃资源利用率。

呃，在线资源的一个尴尬的地方呢，一方面是在线服务的资源利用率，嗯，就百分之二三十，另一方面呢，大数据却时长100%的负载啊，贴地运行啊，这就是整个资源调度一个空间不均啊，还有就是时间上的不均，呃，互联网业务一般具有明显的波峰波谷啊，对于家庭教育可能会更加明显。呃，我们是一直在为我们的峰值进行买单。呃，讲了这么多，一些挑战，我们该怎么解呢？呃，最终我们选择走一条原生道，呃，和云厂商一起，呃，来充分释放云计算的一个潜力。嗯，先来看一下应用层的降本增效，呃，我们采取的是抓大放小的方式，哪些是大头呢？呃，一方面是模块数量最多的应用技术站，一块是单服务使用资源最多的服务啊，这两个就是降本的一个大头。

作业帮初期因为业业务快速发展，服务端采用PP为主要的开发语言啊，很好的支撑了业务的一个快速发展迭代。呃，当时使用的框架是ODP，呃，相信嗯，在百度工作人对这个其实并不陌生啊，因为ODP其实来源于百度内部。呃，说它是框架呢，其实本质上是一套以框架为核心的虚机下的整体技术解决方案，呃，它能够有效的去支撑新业务的快速构建，呃，发展迭代。但是随着业务的发展呢，呃，以ODP为代表的PP服务端，呃，技术站遇到了一些问题啊，主要在于。第一块是性能瓶颈啊，PHP缺乏线程协程的支持啊，在单位的并发下资源使用率高啊，这这样的话就会对着业务的成本也会是更高。

在一些高并发、高性能的场景上，与一些高性能的语言，比如像勾浪，其实是有一定差异的。一块就是微服务支撑的一个欠缺。嗯，ODP框架下呢，服务之间可以使用呃，IPC进行调用，也支持混之后。进行一个本地的调用，这样就会导致服务与服务之间的边界是模糊的啊，这样就会导致责权利不清。呃，整个框架需要全局部署，每次更新迭代特别容易出现一些啊，牵移发动全身的一些稳定性问题啊，再比如说还缺乏一些现代化的包管理工具。呃，原生带来了，给我们带来诸多的技术红利，比如像容器化呀，啊，服务治理啊，S这些都是里面的一些关键技术，呃，但是他们跟PP结合呢，就是PP的适配地可能会偏低。啊，比如像在FPM发射cgi啊，在原生麦上的支持啊，以及在CD上其实也会存在一些过多的耦合，嗯，所以最终呢，作业帮去选择了勾浪作为主推的服务端的开发语言去替代PP，嗯，PP的勾浪呃语言框架呃接近是基于近衍生而来啊，是面向外部服务的呃开发框架提供了开箱机用的常用组件和功能，呃侧重通用性和稳定性，兼顾性能和时延啊，构建了符合公司业务场景的生态体系。

呃，我们这套自定义的框架从大的层次上可以分成这么几个部分啊，首先是下面的htp server，它是基于近的基础上进行了一个二次的开发和优化啊，再有就是左侧的这边，呃，业务控制层，嗯，请求的入口我们除了去包装呃上游发起的HP请求之外，嗯，还有服务自自身运行的定时任务，呃，MQ我们都进行了一些包装，呃，定时任务这边，呃任务这块除了包含有一次性任务、周期性任务、定时任务之外，呃，我们。

还在框架中啊，去模拟了整个链路的一个。呃，封装实现，呃实现了request ID串联整个请求啊，支持加载中元件等等的功能。在右边的呃，网络交互的client，呃，通常的client组件包含像消息队列啊，对象存储啊，DBRA啊等HTP啊等一些常用的库啊，还有一些其他的公共库啊，比如像我们去针对公司的一些基础函数进行了一些封装，避免业务线每个都去实现一遍啊，然后的话还会对勾浪里面常用的一些方法啊，嗯。它相对比较损呃损耗性能却不容易发现的一些方法去进行一个封装，呃，避免因为避免业务去过度的关注基础方法性能优化的一些问题。

嗯，基于这么几大块啊，业务再来构建自身的一个功能逻辑。呃，性能优化这块我们知道啊，在HTP生物中啊，以性能著称的fast htp，呃，与近相比，它的一个很大的优势就是在于复用了连接池啊，但是我们并没在近的二次开发里面去实现连接池，而是考虑珠海将能力进行一个下移啊，借助底层架构的能力啊，多与原站之间保持一个相同的能力。呃，我们多数模块已经嗯去接入了sales match，呃，上游的请求实际上是跟match的proxy去建立了连接I match的proxy和服务之间啊，是通过UDS进行通信并保持长链接啊，同时又优化了US0拷贝的问题啊，除此之外，在性能上我们还做了一些其他的一些优化。呃，比如像针对运行资源去优化GC的参数，呃，针对裸金属服务器的诺马特性做了啊GP的调度优化等等。

呃，效率工具方面做的事情相对比较多啊，比如像有提供代码生成的工具啊，性能分析的平台，本地测试的工具，整个代码生成工具相对简简单易用啊，可以根据脚手架快速的去生成服务代码啊，其中呢，又可以去根据一些基础的模板啊，可选的一些组件啊，来生成业务的应用代码，应用功能。呃，通过代码生成工具我们可以呃规范业务对框架的使用啊，从目的结构上啊，配置的加载方式呀，组件的初始化上都给出了相关的一些模板范例，避免一些个性化的写法啊，进而减少后期啊业务去追查问题维护的一个成本。呃，问题和性能分析这块我们会根据业务的需求，呃需求可以在性能平台上啊，按照条件和需求开启people off啊，提供一个在线的分析报告啊，支持业务开启runtime呃，通用指标采集呃，并有一个统一的监控大盘进行展示。

呃，测试环境互通工具这块，我们可以提供一个简单的命令工具呃，实现将呃远端的测试环境的流量啊代理到本地的一个端口，也可以将本地的呃模块的一个出流量，然后转发到测试环境之上。呃经过两年的发展，呃在作业帮啊沟量从零个模块演变成了服务端使用语数量最多的开发语言，呃当前有600多个模块是基于呃最近构建的，啊整个性能上的收益也是特别明显的。我们保守来看，呃应用模块从PHP重构为呃购量，呃大约能带来五倍以上的性能提升，从原生的进到最近的收益也是很明显的。

呃，右边这个图呢，就是一个真实业务迁移前后的一个负载对比，我们能够看到，呃，在10:30发布之后，整个资源的使用量，呃下降了一半。嗯，再来讲一下我们的核心系统，呃，检索系统作为公司最底层的核心系统之一啊，是C语言战线的道排索引和综合策略索引，为上层的智能推荐、资料分析、搜索提供一个底层的支撑啊，整个基系统所用的规模也是比较大的，大概是千台级别啊，计算核心达到10万盒以上。整体的数据量也是比较大的，时效数据的话会有数百TB，呃，每日新增数据也是TB级别。基于这么大的一个数据量，嗯，我们需要去周期性的进行一个数据的拆分，以及全量数据的再均衡。

呃，整个检索系统对机器的各项指标要求也比较高啊，比如像实验这块要求P99在1.3毫秒以内啊，吞吐的话峰值需要达到100GB这个级别啊，稳定性的话要在五个九以上啊，综合来说，其具备低食盐，高稳定性，高吞吐等一系列一些特点，呃，也正是由于这一系列特点的一些要求吧啊，所以整个检索系统其实对机器的一个指标要求的比较敏感。呃，特别是呃要求的比较敏感，比如像一些啊内存行驶速度的差异啊，啊CPU内存机线带宽的差异，都可能会导导致呃监测系统在不同机器上啊一个巨大的性能上的一个差异。呃，检索系统底层的设施主要包括两块，一块是作为源头的数据产出服务，呃，一块是呃权威的数据存储服务。我们下面主要来讲一下数据存储服务啊，由于监控系统前面一系列的特性要求啊，低时延啊啊，高稳定性啊，高吞吐啊，所以在早期的设计里面很自然的就去选择了本地存储啊，这样就会导致计算跟存储耦合在一起，随着数据量的越来越大啊，单机无法承载所有的一个数据量。

就需要对数据进进行一个切片，每一个节点呢，只需存储一部分的数据，呃，然后又处于高并发啊，高可用的一个要求，呃，每一个分片还需要有多个副本，呃，由此就形成了一个M乘N的一个多维矩阵。呃，当需要进行数据更新的时候，呃，由于数据量比较大啊，几百TB，呃，我的数据产出服务无法依次将全量的数据推到线上几千个节点里面。啊，就只能先从现在下个节点里面先去选择出一部分啊，进行同步啊，然后再以这部分节点为基准，进行一个二次跟三次的分发。

呃，整个更新周期较长，呃，是以小时来计，呃，而且中间还需要一个层层校验，确保数据的一个准确，呃，保证一致性。嗯，这个架构呢，其实对运维也并不友好，但我每次需要进行扩容的时候啊，并不能去简单的扩机器的数量，呃，而要关注我在哪一个分片下需要去扩多少的机器。扩容完成之后呢，还需要再进行一个数据的同步。整个周期一般以天来计算，嗯，这样的话其实就很难去应对一个流量的突增啊。检索系统作为单服务资源使用量最大的服务啊，也是我们降本增效所关注的重点啊，但在这之前其机器负载已经达到了40%~50%啊，再有流量的增加啊，就会导致耗时呃，稳定性的一个剧烈的抖动。呃，通过对检索系统啊整个架构的分析，我们发现当前嗯的关键问题是由于计算和存储耦合所带来的，呃，因此只有引入计算跟存储分离的架构啊，才能从根本上去解决复杂度的这些问题。

呃，计算跟存储分离，本质上我就要将呃原来分片内的本地存储呃转移到呃远端的机器上。呃，但是它可能也会带来一些新的问题啊，比如像我报道我转移到远端上之后，它的数据读取的像稳定性啊，性能能不能达到我的一个要求呢。嗯，虽然有这么多的问题啊，但是我们认为这些问题其实是可以解的啊，所以我们一个大的方向其实是没有变化的啊，在这么一个大的前提下，我们去寻找一个新的解决方案啊，这个新的解决方案要具备以下的能力啊，首先是读取的稳定性啊，存算分离本质上是使用一系列的专元件，呃，配合替换到了原始文件的本地读取，呃，这种情况下它的一个稳定性应该跟呃本地读取是持平的。

啊，第二呢，就是我数千个节点同时去更新数据的，去拉取数据的时候，呃，我如何才能够更快的完成这一个数据的分发。再有就是呃，整体的一个易用性，呃，我们考虑到这套方案最好是可以支持的一个接口，呃，因为只有使用了po的接口才能够，呃使得底层一个变动，对上层是更无感的。呃，第四一块的话，是整个数据迭代的一个可控性，呃对于在线业务而言，其实数据的迭代，呃也应该被看成同代码的CD一样啊，是应该被管控起来的。嗯，最后呢，就是数据集合的可伸缩性，呃前面也讲到了，我们整个呃检索系统的总的数据量比较大，呃每天的数据更新也比较大，所以说需要进行一个周期的数据的呃拆分以及全量的再均衡。

在这样的一个背景下啊，一套数据集合，可伸缩的一个架构啊，对研发效率的帮助啊，其实是特别大的。啊，基于前面的一系列要求，我们最终完成了一个技术的选型，啊，我们选择了弗洛伊德加金东time的组合。嗯，弗伊德是一款开源的K8S，原生的分布式数据，呃，编排和加速引擎。呃，它通过数据的编排啊，是应用数据的调度呃，来解决在原生过程中所遇到的一系列数据问题。比如像访问数据的实验过高啊，多数据联合查询困难啊，以及应用数据过程，嗯，整个过程比较复杂等一系列的问题。嗯，京东runtime是弗洛伊德的一种分布式缓存实现啊，实现了HDFSS3协议的，呃，访问和缓存加速。啊，通过我们这些原生的改造啊，整个检索系统啊，变成了一个标准的无状态的容器应用啊，和正常的在线业务并没有什么差异啊，服务也可以去进行一个正常的扩缩。

嗯嗯。我们来看一下最终的一个数据使用的一个流程。呃，数据产出服务呃将数据传到对象存储当中呃弗洛伊德驱动京东runtime，呃完成一个数据的加载，呃检索的进程呃通过说伊德挂载的PVC去访问f use，呃，F use将呃po协议转换为对远端run time的一个IPC的访问。啊，整个数据应用的过程变得比较简化啊，这里我们为什么要去京东runtime里面去获取数据，而不是直接去对象存储中访问呢？呃，我们主要是由这么几点的一个考虑啊，通过generalle runtime实现了一套可控的啊，有事物有版本控制的数据更新机制，呃，再一个就是京东runtime，它对乐的数据会加载到内存当中。

呃，叫对象存储的直接访问，会有一个明显的一个性能优势。嗯，再有就是我们虽然说对象存储它的，呃存储是分布式的，但它其实的访问还是有一个出口的网关，呃，这个网关有一定的带宽上限啊，它会在一些高吞吐的一些场景里面会有一些制约啊，所以我们通过引入金东run time，呃，极大的去提升了呃整套系统的一个吞吐能力。呃，是能够实现一个数据快速的分发。呃，完成架构改造之后啊，我们对整个系统的瓶颈进行了一个分析啊，发现导致性能无法提升的原因在于跨驽马的一个内存访问带宽啊，有上限明确问题之后，呃，整个的性能优化就会比较简单，我们去添加了调度器啊，是进程绑定no马，呃，保障CPU和内存的访问不跨驽马。

嗯，最终整个项目的一个收益也是很可观了，呃，就是原来数据同步的周期，从呃之前的小时级别降低到了分钟级别。呃，一般在八分钟以内可以完成。啊，整个运维的成本也大幅度下降啊，交付的中期从天级别降低到小市级别。整个检索系统也终于纳入到统一的呃运维体系里面来。呃，性能的提升也比较明显，幅度达到30%啊，直接节省了万台级，万台万核级别的机器。呃，监控系统的原生改造比较成功，呃也在新能源举办的2022年云先生产业大会中被评为呃优秀案例。呃，资源调度层的降本增效的核心还是在在于解决前面提到的几个问题啊，在线集群的负载不高啊，资源分布的空间布均，资源分布的时间不均等一系列的问题啊，我们的应对方案就是通过啊自定义的CPU调度器啊，在离线混部，还有广泛的去应用service来进行一一的解决。

呃，在2020年上半年的时候，我们完成了流量型业务的容器化改造啊，我们机器的平均负载得到一个大幅度的提升。啊，但是我们发现一个比较奇怪的现象啊，就是。我们其实在容器化之前，我们在晚峰的时候只需要去做一些简单的操作啊，并不需要做一些其他过多的一些运维动作。但是我们随着容器化之后，呃，机器的负载虽然上去了，但是不同机器之间的差异较大，呃，我们在晚高峰除了在巡检之外还需要做。挺重的一些操作啊，比如像去针对这些负载不均的机器去人工的进行封锁啊，并将上面不均衡的pod进行一个驱除。

呃，为什么会出现这样的问题呢？呃，我们分析了一下啊，其主要的原因还是在于Q8原生的调度器。啊，其调度的依据是以依据request为主啊，互联网业务都有明显的波峰波谷啊，在线教育的波峰波谷可能会。更剧烈一点啊，波峰跟波谷可能会有两个数量级的一个差异。研发的发布其实一般是在呃波谷的时候，这个时候所有机器的资源利用率都很低啊，所以服务怎么调度都是可可以的啊，但是到了晚高峰啊，一些资源骤增的pod啊，可能恰巧就聚集在少数的一些节点上啊，就会导致这些的节点啊负载。变得异常。呃，从这我们能看出来啊，就是原生的调度器啊，只去考虑了一些简单的指标啊，同时也没有去考虑呃，未来的一个变化。

嗯，所以我们去做了自定义调度器来解决这些问题，嗯，首先嗯，就要先去采集更真实的数据，我们的底层数据啊，改为了依赖普罗米修斯去采集的，呃，真实资源的使用情况。嗯，只有这个还是不够的啊，我们还要去进行历史进行一个预测啊，也就是说呢，我们进行调度的时候，并不是看当前的表现，呃，而是去结合这个服务峰值的表现进行调度。嗯，只看CPU和内存这些指标也是远远不够的，呃，我们还需要将更多的因子考虑进来，呃，举个例子吧，就像呃，就是系统的一个日上传上传量，呃，我们发现有些机器有些服务的日上量就是比较大啊，也会导致机器之间的一个资源不均，所以我们也要把这个因子给考虑进来啊，最终我们这套自定义调度器啊，能够去采集真实的指标啊，能够对未来进行一定预测，然后同时会将多种因子考虑进来。

呃，我们上线这套自定义的调度呃器之后，呃，机器之间的负载变得均衡了起来，呃，然后再通过一些自动化的机器训练能力，整个运维的成本得到一个大幅度的下降。嗯，整套方案做下来之后，是兼顾了成本和效率。嗯，在离线混部是工程界一个比较经典的课题，呃，互联网业务都有明显的波峰波谷，波谷的话其实是有大量的剩余资源在贡献呃，而大数据离线计算需要大量的呃计算资源，呃，但是呢，其实大数据这些离线任务呃，对计算的一个实时性并没有那么强的一个要求。啊，也没有说必须在需要在几分钟啊，或者说呃，十几分钟之内算出结果，呃几个小时之内跑出来也是可以接受的。啊，如果我们在在线集群的时候来跑大数据的离线任务啊，整个大数据离线的一个计算资源就可以有大量的节省。

以此达到一个双赢的效果啊，但是这个方案其实面临很多挑战啊，首先就是很难做到，呃完整的一个资源隔离，呃在线资源的一个稳定性跟时延都会受到离线计算的一个影响啊，负责在线业务的同同学可能也会有一定的顾虑。呃，我们是怎么来做的呢？呃，首先我们是使用腾讯t Linux的新特性。呃，其在内核的cfs还拍之间，啊，增加了一个新的调度器，呃，Offline啊，我们将大数据的任务放在offline调度器上。呃，以此来实现了一个CPU的一个B啊，在放量的整个过程中，我们也整体控制节奏，呃，我们现在夜间在线服务没有什么量的时候来跑离线的计算啊，然后跑到相对比较稳定之后啊，我们再在。白天的波谷啊，来跑大数据的离线啊，又经过一段时间稳定之后，我们现在其实在晚高峰的时候也在跑一些离线的任务，只不过是将它呃整体控制在10%的CPU使用以内。

嗯，So一直是作业帮技术架构探索的核心方向之一啊，以其来解决资源分布的时间不均的问题。嗯，目前业界so主要有两种形态，一种是函数计算，一种是K8虚拟节点。嗯，基于对方这边多数业务已经完成了容器化的背景，我们选择使用K8S虚拟节点的方案。呃，使用QS虚拟节点，对已经完成容村化改造的业务来说啊，没有再额外的改造成本啊，可以实现整体的无无感平滑的迁移，对研发相对是友好的。呃，我们在2020年的时候开始将部分密集计算调度到service之上，呃，利用虚拟节点呃，底层服务之间强隔离的能力啊，来规避服务之间的相互影响。

嗯，在二一年呢，我们将定时任务调度到索斯之上啊，去应对那些短周期呃，运行的任务，提升整个资源的利用率，去降低成本。嗯，在二二年，我们开始将部分核心的在线业务调度到service的虚拟节点上啊，以实现业务的真正削峰。Service会有一个怎样的成本优势呢？我们可以来算一笔账啊，目前作业帮的大多数服务已经完成了容器化的改造啊，在线业务有着明显的波峰波谷。啊，高峰持续的时间较短，每天约四个小时左右啊，在这段时间内啊，机器的一个负载接近于60%，呃，而在低峰的时候呢，负载可能不到10%，呃，这个场景就非常适合service的弹性伸缩。我们假设啊，包年包月的服务器每小时的成本是C，呃，使用server呃，服务计算资源的单位成本是1.5C啊，那么呃，全部是一天全部去使用包年包月服务器的成本是为24C。

呃，那么我换一种模式。保留70%的自由服务，在高峰期的时候增加百分之的30%的sola来应对呃，那么这一天的总成本就会变成呃，18.6C。嗯，按照此种模式运行模式，我们可以直接降低啊22.5%的成本，嗯，可见将在线服务高峰期弹性调度到service上，可以节省大量的呃资源成本。当然我们在推进service时候并不是一帆风顺的啊，也遇到很多问题和挑战啊，首先面临的就是调度上的挑战，在调度层首先要去解决两个问题啊，第一是我们在扩容的时候创建的pod啊，是基于何种的策略去调度到虚拟节点之上啊，第二呢，就是在缩容的时候，呃，我们如何来实现优先去缩减虚拟节点上的pod。

这两个能力在当前K8S的版本中是不具备的。呃，第一种，嗯，就是针对这些，其实也也会业界也会有一些解决方案啊，其中方案一呢，就是最朴素的方案啊，使用原生标签的方式啊，通过node select啊，节点清和污点熔人等等等。嗯，最最简单的把虚拟节点这个资源给利用起来，嗯，但是这种利用呢，其实是割裂的。呃，一个服务呃，无法同时运行在呃虚拟节点和标准节点之上。一个服务要么只能上啊虚拟节点，要么就全不上虚拟节点，呃，这样显然无法达到一个成本的最大化。呃，第二种方案呢，就是部分云厂商提供的方案啊，用户不需要去指定select啊，当pod因为固定节点的资源不足调度pending的时候啊，再尝试调度到虚拟节点之上。

呃，该方案的问题在于什么呢？呃，当整个集群的资源已满的情况下，才进行一个虚拟节点调度，呃，会导致pod的部署过于密集，呃，节点的负载太高去影响业务。我们理想的方案呢，是整个集群的固定节点资源，呃，达到一个利用的瓶颈之后，呃，扩容到so训节点上啊，这样就可以呃，既没有负载过高的风险，也可以去实现一个成本的优势。嗯，所以我们自研的方案啊，是使用自然调度器啊，将超过一定数量的pod去调度到虚拟节点之上啊，这个数量就是一个关键的阈值啊，该阈值基于在线业务的波峰波谷啊进行一个预测。推荐。嗯，计算出呃高峰期该业务在集群物理机上运行的副本数量中的最优解，嗯，这样呢，既能够去满足啊整个固定节点的机器的利用率呃，也能够去满足性能一个要求啊，该方案除了支持啊自动调度到虚拟节点的阈值，还支持进行一个人工的手动设置，呃这样业务其实就可以做一个更精细的调度。

嗯，整个调度策略还可以结合HP同时使用啊，满足业务的一个灵活需求。嗯，解决扩容的问题，我们再来看缩容的问题，呃，缩容时优先去算service，虚拟节点上的po也是很好理解的。啊，因为呃，包年包月的资源单价其实更低，呃，而虚拟节点上的资源按量计费啊，它的成本更高，所以我们应该优先去说啊，Service的po。嗯，具体的做法呢，是通过自然的调度器对虚拟节点上的pod啊注入自定义的注解啊，将带有虚拟节点的自定义注解的pod啊置于整个缩容队列的顶部啊，来完成优先缩容虚拟节点pod的这个实现。

呃，讲完调度的问题，我们再来看一下观测的问题，呃，我们的观测服务都是自建的，比如像日志检索呃，监控报警，分布式链路追踪等等。呃，因为是虚拟节点，Pod里面跑的这些监控组件日采集啊，是云厂商内置的啊，但我们呢，需要给业务呃的整体感知能力呃上包一层，给他们提供一套统一的界面。呃，所以我们就需要去做一个转化到我们自由观测服务的一个过程，我们先来看一下日志采集这块，我们通过CD啊，配置志采集啊，将日志发送到统一的卡夫卡啊，通过我们资源的日志消费服务啊，消费云厂商的自由节点日志啊，实现了虚拟节点和正常节点上日志的一个统一。再来看兼控层面啊，云厂商虚拟节点实现的，呃，Matrics接口和库完全兼容啊，可以无缝的去接入普米修斯啊，实现了。

完成pod实时啊，CPU啊，内存啊，磁盘啊，网络流量等的监控，做到和普通节点上的pod是一致的啊，在分布式追踪这块啊，由于无法部署n set形式的啊，1AGENT啊，我们在1CLIENT上做了一些改造。啊，通过环境变量识别port运行的环境啊，如果是在虚拟节点上，则跳过agent这个流程啊，直接将分布式的链路追踪数据。嗯，讲了这么多啊，我们一起来做一下总结的回顾啊，作业帮基于原生进行了一系列的改造啊，最终实现了降本增效啊，整体降本的服务幅度可以达到40%。这里面有几个关键的技术点，首先是在应用层选择使用最多的应用站，使用资源最多的核心服务，进行一个原生的造。

在资源调度这一层，通过CPU自定义调度器在离线啊service大幅度去提升资源的利率。嗯，在应用这层呢，选择更合适的机型，比如像我们现在已经开始规模化在使用AMD的机器。嗯，直接带来30%的收益，嗯，基于原生我们更换机型，嗯，会变得更加容易快速，对业务无感。前段时间我们就把主机型完成一个换本需一个，除了这些优之呢，一个的非体系也是不可或缺的啊，这个体系建立的首要因素就是要明确组织关系，呃，责权利清晰之后。啊，各自队负责的资源啊，才能有一个更好的维护的动力。其流程中，多。

啊，我本次分享内容就到这里了，谢谢大家，谢谢大家。非常感谢董晓聪老师的分享啊，董晓聪老师很全面的为我们介绍了作业帮云原生降本增效的背景，实施的关键点，以及应用层和资源层进行降本增效的具体实践，这是一个十分具有借鉴意义的案例啊，大家可以收藏本次的一个直播链接，回放地址呢，就是我们当前的直播地址，那有的小伙伴呢，可能会问啊，就说我们错过了前两期的直播怎么办呢？也不用担心啊，我们每一场的直播结束呢，都会有回放，回放呢也就是当前我们的直播地址，上两期呢，我们进行了六讲的直播，在6月23号，6月30号，还有7月7号呢，我们进行了第一期主题分别是云原生降本增效优秀时间案例分享。Coad云上资源的分析与优化，Ad集群利用率提升，时间在7月28日，8月4日，还有8月11日呢，我们进行了第二期的直播。

直播主题分别是KNS全场景在离线混部通过云原生管理coinetic GPU资源。资源拓扑感知调动，欢迎大家观看回放，点击当前直播间下方的网期直播或进入活动专题页面即可观看和学习。好了，我们今天的直播到这里就结束了，我们下期再见。