嘉宾|董小聪出品| CSDN云原生

2022年9月1日，在由中国信通院、腾讯云、FinOps行业标准工作组联合主办的“Powered by X Cloud”系列直播活动第七讲上，作业帮基础架构负责人董晓聪分享了云在作业帮的降本增效实践。本文整理自董小聪的分享。

为什么要进行降本增效作业帮的技术现状可以归纳为两点，分别是规模化和复杂化。规模化：数千个应用服务，对应数万个服务实例，运行在数十万计算核心之上；

复杂化：技术栈极为丰富，涵盖多种主流语言。复杂性:技术栈极其丰富，涵盖了很多主流语言。

2020年初，作业帮开始走云起源之路，解决开发过程中遇到的稳定性、成本、效率、安全性等问题。通过对云的原始改造，基础设施接管了业务中大量的非功能逻辑，从而实现灵活性、可观察性、弹性、自动化和可持续性。

为什么要进行降本增效？

互联网红利下降，企业希望成本效益最大化；

资源浪费现象普遍，节省了不必要的浪费；

从技术人员的角度来看，期望写出质量更好、性能更高的代码。

在降本增效的过程中，我们需要明确:降本不降质。在降低成本的同时，稳定性、效率和安全性不能妥协。

降本增效的关键点降本增效关键点

在各种制约因素存在的情况下，如何开展降本增效工作？

应用层首先要做的就是提高性能，也就是增加单位资源可以支持的业务并发。对于作业帮来说，多样的技术栈给应用层的效率提升带来了挑战。

资源降本增效的重点在于计算水平的优化，有两大挑战:

寻找更优机型，提升单位成本的算力；

有了合适的模型之后，业务就可以平稳无感的切换了。

资源调度层有巨大的优化空空间，但也面临诸多挑战:

在线资源负载不高，对于高并发业务，为了应对频繁的流量突增，需保证一定的Buffer，同时低流量业务通常长尾，进一步拉低了在线资源的利用率；资源空间不足，在线资源利用率一般在30%，而大数据通常100%负载；

时间不均衡，互联网业务资源使用有明显的高峰和低谷。

应用层降本增效

应用技术栈改造技术堆栈转换的应用

起初，作业帮采用PHP为服务端的主要开发语言，并使用ODP框架，能够有效地支撑新业务的快速构建及发展迭代。但随着业务的发展，以ODP为代表的PHP服务端技术栈遇到了诸多问题：最初，作业帮采用PHP作为服务器和ODP框架的主要开发语言，可以有效支持新业务的快速构建和开发迭代。但是随着业务的发展，以ODP为代表的PHP服务器technology stack遇到了很多问题:

性能瓶颈，PHP缺乏线程与协程的支持，在单位的并发下，资源使用率、业务成本高；欠缺微服务支撑，ODP框架下，服务之间可以使用RPC进行调用，也支持混部后进行本地调用，服务之间边界模糊、权责不清等问题开始显现；

云原生适配不足，云原生带来很多技术红利，比如容器化、服务治理、DevOps等。但是PHP适配性低，不能与之结合。

所以我们选择用Go语言代替PHP作为服务器的主要开发语言。语言框架ZGIN，源于GIN，是一个Web服务的开发框架，提供通用的组件和开箱即用的功能，注重通用性和稳定性，兼顾性能和延迟。

应用技术栈——整体设计

GIN是一个通用的应用框架，我们在GIN的基础上做了性能优化，用来适配底层的基础设施技术方案，同时可以提升业务场景下的性能。

与GIN相比，在HttpServer中一直以性能著称的fasthttp有一个显著的优势:重用连接池。而我们在GIN的二次开发中并没有实现连接池，而是将能力下移，让多语言栈保持与底层架构能力相同的能力。目前，大多数服务模块都可以访问服务网格，上游请求与网格代理建立连接。Mesh-Proxy通过UDS与服务模块通信，并保持一条长链路。同时优化了UDS的零拷贝。

效率方面，提供了简单易用的代码生成工具，根据脚手架快速生成服务代码。通过代码生成工具，规范业务对框架的使用，降低业务后期定位和维护问题的成本。

在测试环境互操作性工具方面，提供了一个简单的命令工具来将远程测试环境的流量代理到本地端口，并且还将本地模块的输出流量转发到测试环境。

应用技术栈——成果

经过两年的发展，Go语言已经演变成作业帮中使用最多的服务器语言。目前基于Go语言构建的模块总数已经达到600+，性能提升明显。如上图所示，使用Go语言重构应用模块，可以带来5倍以上的性能提升。

核心云的原生转变

检索系统作为公司最底层的核心系统之一，是C语言栈下的倒排索引和综合策略索引，为智能推荐、智能数据分析和搜索提供底层支持。机器规模一千台，计算核心千万核以上，老化数据一百TB，数据日增量TB。

检索系统——架构

检索系统的基础架构主要包括两部分:数据输出服务和数据存储服务。

由于检索系统对低延迟、高稳定性和高吞吐量的要求，早期选择本地存储，带来了计算和存储的耦合问题。随着数据量的增加，单机无法承载所有的数据，所以需要对数据进行切片，每个节点存储一些数据。由于高并发和高可用的要求，每个切片需要多个副本。

当数据需要更新时，由于数据量巨大，数据输出服务无法一次性将全部数据存储在在线节点中，只能选择部分数据进行同步，然后基于这部分节点分两次或三次分发。这就导致了数据更新时间长、运维成本高、资源占用大等问题。

通过对检索系统架构的分析，可以看出当前的关键问题都是由计算和存储的耦合引起的。只有引入计算和存储分离的架构，才能从根本上解决复杂的问题。新的解决方案应该具有以下功能:

存储读取的稳定性应和本地持平；存储读取的性能；存储读取的易用性，最好支持POSIX接口；数据迭代流程的可控性；

数据集的可扩展性。

基于以上要求，在技术选择上，我们选择了Fluid和JindoRuntime的组合。Fluid是开源的Kubernetes原生分布式数据集排列和加速引擎，通过数据排列和应用数据调度，解决了云原生过程中遇到的一些列数据问题，如数据访问延迟高、多数据联合查询困难等。JindoRuntime是Fluid的分布式缓存运行时实现，实现了HDFS和S3协议的访问和缓存加速。

检索系统——云原生架构

通过云原生改造，检索系统变成了一个标准的无状态容器应用，数据应用的过程得到简化。通过云原生改造，检索系统成为标准的无状态容器应用，简化了数据应用的流程。

数据输出服务将数据传输到对象存储，Fluid驱动JindoRuntime加载数据。检索过程通过Fluid挂载的PVC访问fuse，fuse将POSIX协议转换为RPC访问远程JindoRuntime。

架构改造后，对检索系统的瓶颈进行了分析，发现性能无法提升的原因在于整个NUMA内存访问带宽的上限。

通过添加调度器，将进程绑定到NUMA，CPU和内存的访问不跨NUMA，可以很好的解决这个问题。

资源调度层降本增效资源调度层的降本增效

资源调度层降本增效的核心是解决前面提到的在线集群负载低、资源空和时间分配不均等一系列问题。

自定义计划程序

容器转换显著提高了机器的平均负载，但不同机器之间的差异很大。有些机器在业务高峰期需要额外的运维工作，比如手动封锁高负荷机器，手动驱逐不平衡Pod。为什么会出现这样的问题？

主要原因在于Kubernetes原生调度器的调度依据以request为主，只考虑简单的指标，没有考虑未来的变化。于是我们通过自定义调度器来解决此问题：主要原因是Kubernetes原生调度器的调度依据主要是request，只考虑简单的指标，没有考虑未来的变化。因此，我们通过定制调度程序来解决这个问题:

底层数据依赖Prometheus采集资源的真实使用情况；结合历史信息进行预测；

除了以CPU和内存为指标，加入更多的因素进行多维度的考量。

离线混合

互联网服务有明显的波峰和波谷，波谷期间大量过剩资源闲置。考虑到大数据的离线计算需要大量的计算资源，对实时性的要求较弱，我们可以将大数据的离线任务运行在在线集群的山谷中，从而节省计算资源，实现双赢。但在实际实施中，存在资源隔离无法避免干扰、隔离效果不佳等问题。

对此，我们使用腾讯TLinux的新特性，在内核的CFS之间，添加一个新的调度器Offline，实现CPU避让，并对空闲资源做预测调度。在这方面，我们利用腾讯TLinux的新特性，在内核中的CFS之间离线添加新的调度器，实现CPU回避，对空空闲资源进行预测和调度。

无服务器应用广泛。

无服务器一直是作业帮技术架构探索的核心方向之一，用来解决资源分布不均的问题。无服务器的运行方案主要有两种，一种是函数计算，一种是K8s虚拟节点。K8s虚拟节点具有对现有服务使用无差别、用户体验好、对业务服务无感知的特点，可以基于现有基础设施进行迁移。

Serverless技术挑战——调度

无服务器有很强的成本优势。将在线服务的高峰期灵活地安排到无服务器上，可以节省大量的资源成本。在推进无服务的过程中存在许多挑战，并且在调度级别需要解决两个主要问题:

扩容时创建的Pod基于何种策略调度到虚拟节点；

收缩时间时如何优先收缩虚拟节点上的Pod？

有三种方案可以解决上述两个问题。

方案一:原生标注能力。虚拟节点资源通过节点选择器、节点相似性等来利用。，但是这种方式是碎片化的，同样的服务不能在两种类型的节点上运行。

选项2:云厂商调度扩展。用户不需要指定选择器，当固定节点的资源不足时，会被调度到虚拟节点。但当集群资源满时，虚拟节点调度会导致Pod部署过于密集，节点负载过高，影响业务稳定性。

方案三:自行开发调度程序。将超过阈值的Pod调度到虚拟节点，其中阈值基于预测推荐和人工调整。这种方法可以有效地平衡稳定性和成本。

Serverless技术挑战——观测

日志采集方面，采用CRD配置日志采集，将日志发送到统一的Kafka，通过资源的日志消费服务，消费云厂商的自有节点日志，实现虚拟节点和正常节点上的日志统一。在日志收集方面，使用CRD配置日志收集，并将日志发送到unified Kafka。通过资源的日志消费服务，消费云厂商自有节点的日志，实现虚拟节点和普通节点上日志的统一。

在监控方面，云厂商虚拟节点实现的Metrics接口完全兼容Kubelet，可以无缝接入Prometheus监控Pod的实时CPU、内存、磁盘和网络流量。

在分布式跟踪方面，由于我们不能以Daemonset的形式部署jeager-agent，所以我们在jeager-client端做了一个改造，通过环境变量来标识Pod的运行环境。如果它运行在虚拟节点上，我们跳过jeager-agent，直接将分布式跟踪数据推送到jeager-collector。

总结摘要

作业帮基于云原生进行了一系列改造，最终实现降本增效，整体降本服务达到40%。未来将继续探索更具成本效益的降本增效之路。此外，目前作业帮的运营已经实现了从靠人到靠平台的转变，并将进一步向BI和AI演进。