聚合国内IT技术精华文章,分享IT技术精华,帮助IT从业人士成长

作业帮的云原生历程与实践

2021-08-21 14:33 浏览: 3521 次 我要评论(0 条) 字号:

本文源自作业帮基础架构负责人董晓聪的分享。讲述作业帮的云原生历程,并围绕云原生架构和多云架构两大解决方案进行深入延展。
云原生改造重塑技术体系

“之前在传统的互联网公司,大家没法接触到用户,对用户的感知更多的是一个个 UV、PV 数字,但在线教育不一样,我们通过直播等形式面对的是一个个学生,每一次稳定性的事故都可能会影响他们的学业,所以作业帮对稳定性的要求只能更高。”据董晓聪介绍,作业帮在稳定性层面,主要面对以下三大挑战:

  • 当出现单机、单机群、单云故障的时候,架构能否很好的应对这些冲击?

  • 当代码变更导致业务中断的时候,能不能快速止损?

  • 除了稳定性外,如何控制成本以及提升效率?

作业帮选择通过云原生来解决上述问题。用基础设施接管业务当中大量非功能的逻辑,以此来实现弹性、可观测性、韧性、自动化、可持续等一些相关特性,通过云原生的架构解决了部署层面的问题,然后在此之上实现了一套多云间自由迁移的能力。

“即使从今天来看作业帮当时做的这个决定,选择云原生架构,也是很有魄力的,因为它毕竟是一个技术体系重塑。”董晓聪表示,截至目前,作业帮已经完成了 70% 左右业务的云原生改造,处于业内领先水平。同时作业帮在弹性扩缩、Serverless、在离线混部等方面都有广泛的应用,在 CPU 调度、GPU 调度、多云管控等方面也有创新型专利产出,解决了开源社区的诸多问题。

在 CPU 调度方面,2020 年上半年,作业帮在完成了一块核心业务的容器化之后,突然发现运维成本增加了。原来在虚机模式下,运维在晚高峰的时候,只需要去做一些稳定性的巡检,运维动作并不多。但容器化后,在晚高峰下需要不断地对一些资源负载比较高的进行封锁,然后把上面的一些比较重的 Pod 进行驱逐,经分析 Kubernetes 的原生调度器还是以 request 进行调度,会存在一些问题。

互联网业务都会有一个明显的波峰波谷,在线教育的波峰波谷会更加剧烈,可能会有两个数量级的差异。当研发在波谷的时候进行一次发布,这时候就会触发容器的一次重新调度,比如当服务有几十个 Pod,可能会有十多个 Pod 调度到一台机器,因为这时候的机器的使用率很低,服务怎么调度其实都可以。

但是到了晚高峰的时候,每一个 Pod 资源的使用率就上来了,CPU 使用高了,它的吞吐也高了,这十个 Pod 都在同一个机器上,这台机器就会出现一些资源的瓶颈。原生的调度器只考虑了一些简单的指标,同时也没有考虑未来的变化。基于此,作业帮做了自定义的调度器,对晚高峰进行了预测,将 CPU、内存、各种 IO 等指标都作为因子,同时也会定期的把历史数据进行大数据回归更新。

GPU 是一个相对比较贵的资源,通过调研一些方案并和云厂商进行沟通,了解到目前主要推荐的方案是 GPU 虚拟化,但是这会至少带来 15% 的性能损耗,这个是没法接受的。大多数的 GPU 服务使用的各种资源相对比较固定。鉴于此,作业帮基于算力和显存去进行了一些策略的调度,也就是比较经典的背包问题,同时夜间也会进行一下预测再重新调度,如果中间出现一些故障,也会执行转移相关的策略。

当 Web 业务完成容器化改造之后,团队把一些定时任务迁移到容器平台。这时候又出现了新的问题,很多任务会涉及到密集的计算,容器本身其实并不是一个隔离的机制,还是在做 CPU 时间片的分配。这些计算密集的任务多多少少还是会对 Web 任务造成一定的影响。同时它也会占用主机的 IP 资源,node 上的 IP 资源是有限的,定时任务调度上来之后就会分配 IP,任务销毁时 IP 资源也不会立刻销毁。如果频繁地把定时任务的 Pod 调度到主机群的节点上,就会导致主机群的 Web 服务没有足够的 IP 资源。此外,大规模的创建跟回收定时任务,也会触发一些内核的问题,比如有些定时任务的内存使用比较大,大规模回收会导致陷入内核态,hang 住的时间比较长。

这方面作业帮做了一些改造:建立了三个池子,Serverless、任务集群、主机群,优先会把定时任务去调度到 Serverless 上,如果调入失败的话,再依次到任务集群、主集群,Serverless 并不是一种完全可靠的计算模式,而是引入了一种资源预占的方式,比较类似于金融领域为保证事务的两阶段提交,预先去申请相关的资源,当完成预占之后,再把真正的把任务调度过去。

多云架构实现秒级别自动切换

作业帮解决多云架构主要面临两大挑战。首先在云间互通的专线选型上,作业帮没有选择裸纤的方案,而选择了供应商的组网方案。董晓聪表示,选择组网方案,一方面因为有一层供应商的保护能力,另一方面是组网有一定弹性扩缩的能力。而在此之外,公司自身也做了双链路。每条链路选择不同的供应商,从不同地域进行接入。在这两条链路上,通过 BGP+ECMP 实现了链路的负载均衡,以及当单条线路出现故障的时候,可以实现秒级别的自动切换。

“多云还会面临着一个很大的挑战,就是计算资源的管理。”董晓聪说,单个云下就有十几种、几十种机型,多云会直接导致 double、trible 的工作量。作业帮对一些场景进行了建模,标准的负载型机器、专门的大内存、大存储机型,然后再结合网络的安全域,制定具体的业务套餐。

“完成了上面的网络、计算的问题之后,作业帮构建出自己的多云架构”。董晓聪说,用户通过 DNS/DoH 分流,落到不同的机房。常态下的业务应用之间的请求是单云闭环,不会去跨云通信。当从机房或者专线出现故障的时候,可以通过 DNS/DoH 把流量切到主机房上。当主机房出现故障的时候,还是同样的流量调度,除此之外,还要将从机房的数据存储,DB、Redis 等进行提主,以此来实现了多云的稳定。

“完成云原生、多云改造之后,稳定性从之前的 99.95% 提升到了 99.99%,机器故障时间的影响也从分钟级别缩短到秒级。部署的质量也得到大幅度提升。”董晓聪透露,接下来,作业帮的发力重点会在实时音视频的云原生改造,推进无边界云计算,促成云边端应用一体协调。

今日好文推荐
PHP没你想的那么差
微服务需要一场由内至外的变革
被“监控”的打工人:因算法裁定“效率低下”,近150名员工遭解雇
携程试点每周两天居家办公反响热烈,76%的员工主动报名


InfoQ 写作平台欢迎所有热爱技术、热爱创作、热爱分享的内容创作者入驻!

还有更多超值活动等你来!

扫描下方二维码

填写申请,成为作者

开启你的创作之路吧~

点个在看少个 bug 



网友评论已有0条评论, 我也要评论

发表评论

*

* (保密)

Ctrl+Enter 快捷回复