《云原生架构白皮书2022新版》——各个行业面临的挑战及解决方案——作业帮原生降本增效实践之路（上） https://developer.aliyun.com/article/1232803
下面基于应用、部署简单来聊。
应用这一层对主流技术栈进行优化。第一，我们是重新编译，我们以 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 的策略。
3、未来展望
The Cloud-na
未来，作业帮会将定时业务、AI 计算迁到 ECI 之上来实现真正在线业务的削峰，并且我们将持续探索更具性价比的
IaaS 资源，这也是我们一直尝试和探索的方向。目前，作业帮已经和阿里云有一个关于 AEP 的 tair 方案的结合，
在新的一年希望我们有更大规模的落地。文章里讲得比较多的是关于降本做的一些技术改进，其实在降本增效这里面
还有很大一块工作量是运营，成本运营我们也通过自动化实现了平台化，未来我们将会进一步向 BI 化、AI 化去演进。t
