大数据

阿里系统软件迎战“双11”超高流量峰值全纪录

广告
广告

微信扫一扫,分享到朋友圈

阿里系统软件迎战“双11”超高流量峰值全纪录
0 0

刚刚过去的 2018 年天猫“双11”,创下了全天 2135 亿 GMV 的数字奇迹,零点交易峰值比往年提升 50%,各项指标均创下历史新高。

2018 年是“双11”的第十年,也是阿里系统软件事业部参与的第二个“双11”,系统软件是介于业务应用和 IDC、网络、服务器之间的核心关键层,为阿里巴巴集团在线业务提供基础的操作系统、资源调度、SRE、JVM 等领域重要的基础设施。

经过两年“双11”的精心淬炼,系统软件事业部与其他兄弟 BU 并肩作战,逐步提升了阿里巴巴在基础软件领域的技术深度。阿里系统软件是如何应对“双11”流量峰值的呢?以下为大家一一揭晓。

“双11” 面临的挑战

“双11” 的核心是稳定压倒一切,如何确保各个系统在峰值流量下的稳定性成为重中之重,系统软件作为阿里巴巴的基础设施底盘,今年主要面临如下挑战

  • 在去年“双11”的完美表现的基础上,今年“双11”的稳定性不容有失,从内核到业务层保障,所有基础设施必须保障绝对稳定;
  • 大量新技术如规模化混部演进给集团带来技术进步的同时,给系统和业务带来不确定的技术风险;
  • 如何在保障业务稳定性的同时,确保成本最低,是业务给系统软件提出的更高要求。

系统软件“双11”备战回顾

“双11”备战之资源交付备战

1. 面向终态的站点交付

众所周知,阿里巴巴的交易系统采用了异地多活的灾容架构,当大促来临前,需要在多个地域快速交付多个站点,通过全链路压测平台进行站点能力验证。借助于阿里巴巴资源快速弹性的能力,从交付使用到站点压测,需要在短短 10 多天时间内完成多个站点的快速交付,无疑是一个巨大的挑战。

为了提升整体建站的效率,确保站点高质量交付,系统软件建站团队对建站链路进行了全面的方案优化和升级如下:

  • 全生命周期业务集群管控
    包括 0->1(建站)、1->N/N->1(弹性伸缩/快上快下)、1->0(站点下线);弹性伸缩范围包括接入层、中间件、Tair 及应用全链路。
  • 无缝对接容量模型
    单元化应用分组自动识别,应用弹性结合预算产出容量模型,对接中间件等容量模型,交易笔数->建站范围及资源需求。
  • 规模化资源编排
    基于 Sigma 的规模化场景资源编排,最小化资源碎片,节省资源,通过实际验证,资源分配率达到 98%。
  • 自动化业务回归
    各 BU 自动化业务回归,例如基于天启/doom、全链路压测、军刀等。

2. 资源运营降低大促成本

根据准确测算,2018 年大促每万笔交易成本比去年下降 20%;这里面除了混部技术的大规模运用、云化等因素外,还需要在资源运营层面进行一系列优化,其中的重点就是打造一套资源全生命周期管理的资源运营平台,实现资源快速交付和资源最大化利用。

  • 资源交付体系建设在资源交付链路上,资源运营团队对额度系统进行重构升级,将面向时间的额度系统升级为面向当前账户的额度体系,应用负责人可以自由地在应用之间进行额度转移,极大地提升了资源交付效率;此外,我们基于一系列的容量规划和算法预测,实现了大量业务的分时复用,将大量不参与大促的业务的资源提前释放,用于支撑大促需求。

基于系统化的资源运营方式,集团资源运营的效率和利用率大幅提升,有效地防止了资源泄露和资源闲置,真正实现了大促成本不增加,为阿里集团节省了亿级别采购成本。

“双11”备战之调度备战

1. 大规模混部技术应用

2017 年“双11”,阿里巴巴的混部技术在大促零点成功得到验证,今年“双11”混部的量级扩大到去年的 3 倍。在这个大目标下,混部团队对现有架构进行了升级。

在离线调度器伏羲和在线调度器 Sigma 之上演化出一个总体的资源协调者 0 层,主要承载离线和在线资源记账、区分优先级的资源分配和总体协调的作用,可以把它形象的看成是一个大的账本,上面的每一条记录便是某台机器上 cpu/mem/io 资源如何划分给在线和离线业务,从而解决混部环境在线和离混资源的资源分配问题。

在混部业务稳定性保障方面,通过对两类资源(CPU 和 MEM)按优先级划分的策略进行使用,其中以 CPU 资源为例划分为三个级别:

  • 金牌,CPU 采用绑核模式具有最高优调度抢占优先级;
  • 银牌,在线和离线高优先级任务使用,离线银牌资源不会被在线任务驱赶,保障调度优先级和稳定性;
  • 铜牌,离线大部分 worker 申请铜牌资源使用。在线 S10 和 S20 需要使用 CPU 时可以驱赶离线铜牌对 CPU 核的占用,实现资源充足时离线成分用满,资源紧张时在线能及时抢占的效果。

得益于前文所述的新混部调度框架,0 层和 1 层调度间的资源配合有了一个明显提升,去年的混部方案中,0 层只保留静态的集群或单机资源配比,并且比例生效都是通过外部人为设置。

而今年 0 层精细化单机账本之后,每台单机的配比则交给伏羲和 Sigma 自动调整,按照容器所需资源比例进行设置。借助于资源配比的按需调整功能,快上快下也实现了完全自动化的流程驱动。

混部快上快下是指在大促过程中,离线快速地资源释放给在线或在线快速给归还资源给离线的过程。

自动化流程完美的实现了规模化混部目标,通过完整链路优化,最终实现了快上 2 小时,快下 1 小时的时间目标,也正是如此快速的资源伸缩操作保障了离线业务在资源相对紧缺的情况下安全顺滑支持规模性压测及“双11”大促的完整支持。

今年“双11”,有超过 50% 的流量运行在混部集群;其中离在线混部(即离线提供资源给在线交易使用)支撑了 40% 的交易流量;在离线混部(即在线出让部分资源用于离线任务运行)一共部署约了数千台机器资源,为离线业务团队减少数千台机器采购。

2. Sigma 调度能力升级

Sigma 是阿里巴巴自研的资源调度器,调度引擎是 Sigma 调度的核心,调度引擎的优劣,直接决定了其调度的业务的稳定性。今年调度能力升级主要做了以下几方面工作:

  • 业务运行时保障
    今年调度引擎团队首次提出了资源确定性的 SLO 目标,将业务方关心的资源争抢、超卖、CPU 核重叠等容器运行时的稳定作为第一优先级任务解决,在确保核心应用 CPU 逻辑核不堆叠的前提下,满足了同应用不同容器和同容器对端核争抢的需求,从而提升了资源稳定性。
  • 引擎升级
    新版 Sigma 调度器在原有基础上进行了重新设计和架构升级,兼容开源 Kubernetes 框架,在数万笔交易容量集群上得到了大规模验证。
  • Pouch 容器
    今年“双11”,超过 10% 的物理机上线了 Pouch 开源回迁版本,为探索阿里内外使用同一个容器打下基础。同时,容器团队还在 Containerd-1.0 方面做了大量的性能优化/锁优化/定时任务 CPU 优化,确保容器运行时稳定。
  • CpuShare 精细化资源分配
    CpuShare 是一种基于 linux cgroup 对应用的 CPU 和内存进行精细化的控制和使用的技术,“双11”前在线资源池整体 share 容器数占比 10%,其中核⼼应⽤ 5%,次核⼼应⽤ 10%,非核⼼应⽤ 20%+。

3. 大促云化

大促云化是指大促时通过短时间使用阿里云的计算能力,大促峰值过后将资源释放归还给公共云继续售卖的一种资源使用方式。

大促云化的本质是资源的云化,包括计算资源、网络、IDC、服务器全部基于阿里云的底层技术,从 2014 年提出大促云化后,大促云化方案经过了多次升级改进,通过 VPC 网络打通云上云下互访,实现大促过后直接释放资源即可直接售卖,从而减少资源占用时长和改造成本。

  • 全量使用公共云方案,网络层通过 VPC 方案实现公共云环境与弹内环境互通;通过使用阿里云的 ECS buffer,减少交易的资源采购;
  • 计算存储分离,使用阿里云的盘古做为远程盘存储,大大减小物理机本盘,降低了大促资源成本;
  • 此外,在应用、中间件、数据库层面大规模部署神龙云服务器,总体效果良好。

4. 大规模计算存储分离

2018 年是计算存储分离破局之年,基于盘古远程盘,部署了数千台在线宿主机,超过 50% 的集群使用了存储计算分离技术,这项技术有望大幅减少未来阿里集团在服务器 SSD 盘的硬件成本投入。

“双11”备战之内核备战

内核是系统运行的基础,今年内核团队的备战主要集中在以下两个方面:

1. 版本内核部署 

Linus Torvalds 在 2016 年 12 月 11 日发布了 Linux 内核 4.9 的正式版本,由于 4.9 新内核修复了大量老内核已知 bug,4.9 版本的操作系统比目前版本相比稳定性更高,宕机率也有明显下降;目前装机量达到数十万台级别,“双11”交易集群约 90% 的交易部署在 4.9 内核环境,未来将继续扩大新内核的升级。

2. 混部环境内核调优

离线和在线混部的集群中,由于宿主机整体资源有限,如何避免离线任务的运行对在线任务造成影响,成为业界难。今年混部实施以来,发现混部任务调度到在线宿主机后在线业务频繁反馈容器及宿主机 load 高或 CPU sys 高的情况。

经过内核团队介入排查,发布宿主机内存文件缓存过大,申请新内存时触发整机内存直接回收,导致系统开销大。以下是优化思路:调整整机内存后台回收值(调整内存水线,提高内存 Normal Zone 的 LOW/HIGH 水线),提前回收文件缓存页面,避免内核进入直接回收流程。 

补丁前:MIN=8G, LOW=10G, HIGH=12G,LOW 与 MIN 之间只有 2G,当应用分配大量内存时,kswap 还没来得及后台回收,系统内存就低于 8G,这时应用只能进入 direct reclaim,直接去回收。

补丁后:MIN=8G,LOW=25G,HIGH=27G 

“双11”备战之 JVM 备战

1. JVM 协程(wisp)

JVM 协程今年部署范围交易核心应用扩大到导购,大促期间整体某导购核心应用水位从去年 30% 提升到今年的 60%,业务没有新增机器。

2. ZenGC

  • TenureAlloc部分核心应用默认开启 ZenGC,GC 暂停改善 50%;
  • GCIH2.0核心应用部署 GCIH2.0,在安全性和性能上进行了改进,GC 暂停时间最多改进 20+%。
  • ElasticHeap 动态堆内存“双11”0 点之前低流量时降低 Java 进程内存 20%+,”双11“0 点迅速恢复 Java 堆全量使用,峰值过后,继续缩小 Java 堆,减少进程内存 20%+,99%和最大暂停大幅好于 CMS,CMS 为 G1 的 150%~5X。
  • EarlyOldScavenge在 Lindorm Velocity 证,大幅减少 Concurrent GC 从 1 天 30+ 次,减少为 1 天 1 次,推算堆增长率减少 95% 以上。

未来展望

系统软件为打造阿里巴巴高性能、低成本的基础设施,在赋能业务发展、降低阿里巴巴资源运行成本方面实现了初步的技术积累,展望未来,系统软件仍有巨大的发展空间。

我还没有学会写个人说明!

2019 年,容器技术生态会发生些什么?

上一篇

微服务架构之「 服务注册 」

下一篇

你也可能喜欢

阿里系统软件迎战“双11”超高流量峰值全纪录

长按储存图像,分享给朋友

ITPUB 每周精要将以邮件的形式发放至您的邮箱


微信扫一扫

微信扫一扫