jessie筱姜
2018-12-17
2257浏览量
作者|阿里资源管理技术专家杨仪
刚刚过去的 2018 年天猫“双11”,创下了全天 2135 亿 GMV 的数字奇迹,零点交易峰值比往年提升 50%,各项指标均创下历史新高。
2018 年是“双11”的第十年,也是阿里系统软件事业部参与的第二个“双11”,系统软件是介于业务应用和 IDC、网络、服务器之间的核心关键层,为阿里巴巴集团在线业务提供基础的操作系统、资源调度、SRE、JVM 等领域重要的基础设施。
经过两年“双11”的精心淬炼,系统软件事业部与其他兄弟 BU 并肩作战,逐步提升了阿里巴巴在基础软件领域的技术深度。阿里系统软件是如何应对“双11”流量峰值的呢?以下为大家一一揭晓。
双11的核心是稳定压倒一切,如何确保各个系统在峰值流量下的稳定性成为重中之重,系统软件作为阿里巴巴的基础设施底盘,今年主要面临如下挑战:
众所周知,阿里巴巴的交易系统采用了异地多活的灾容架构,当大促来临前,需要在多个地域快速交付多个站点,通过全链路压测平台进行站点能力验证。借助于阿里巴巴资源快速弹性的能力,从交付使用到站点压测,需要在短短10多天时间内完成多个站点的快速交付,无疑是一个巨大的挑战。
为了提升整体建站的效率,确保站点高质量交付,系统软件建站团队对建站链路进行了全面的方案优化和升级如下:
根据准确测算,2018年大促每万笔交易成本比去年下降20%;这里面除了混部技术的大规模运用、云化等因素外,还需要在资源运营层面进行一系列优化,其中的重点就是打造一套资源全生命周期管理的资源运营平台,实现资源快速交付和资源最大化利用。
基于系统化的资源运营方式,集团资源运营的效率和利用率大幅提升,有效地防止了资源泄露和资源闲置,真正实现了大促成本不增加,为阿里集团节省了亿级别采购成本。
2017年双11,阿里巴巴的混部技术在大促零点成功得到验证,今年双11混部的量级扩大到去年的3倍;在这个大目标下,混部团队对现有架构进行了升级,在离线调度器伏羲和在线调度器sigma之上演化出一个总体的资源协调者0层,主要承载离线和在线资源记账、区分优先级的资源分配和总体协调的作用,可以把它形象的看成是一个大的账本,上面的每一条记录便是某台机器上cpu/mem/io资源如何划分给在线和离线业务,从而解决混部环境在线和离混资源的资源分配问题。
在混部业务稳定性保障方面,通过对两类资源(CPU和MEM)按优先级划分的策略进行使用,其中以CPU资源为例划分为三个级别,分别为金牌,CPU采用绑核模式具有最高优调度抢占优先级;银牌,在线和离线高优先级任务使用,离线银牌资源不会被在线任务驱赶,保障调度优先级和稳定性;铜牌,离线大部分worker申请铜牌资源使用。在线S10和S20需要使用CPU时可以驱赶离线铜牌对CPU核的占用,实现资源充足时离线成分用满,资源紧张时在线能及时抢占的效果。
得益于前文所述的新混部调度框架,0层和1层调度间的资源配合有了一个明显提升,去年的混部方案中,0层只保留静态的集群或单机资源配比,并且比例生效都是通过外部人为设置,而今年0层精细化单机账本之后,每台单机的配比则交给fuxi和sigma自动调整,按照容器所需资源比例进行设置。借助于资源配比的按需调整功能,快上快下也实现了完全自动化的流程驱动。
混部快上快下是指在大促过程中,离线快速地资源释放给在线或在线快速给归还资源给离线的过程;自动化流程完美的实现了规模化混部目标,通过完整链路优化,最终实现了快上2小时,快下1小时的时间目标,也正是如此快速的资源伸缩操作保障了离线业务在资源相对紧缺的情况下安全顺滑支持规模性压测及双11大促的完整支持。
今年双11,有超过50%的流量运行在混部集群;其中离在线混部(即离线提供资源给在线交易使用)支撑了40%的交易流量;在离线混部(即在线出让部分资源用于离线任务运行)一共部署约了数千台机器资源,为离线业务团队减少数千台机器采购。
sigma是阿里巴巴自研的资源调度器,调度引擎是Sigma调度的核心,调度引擎的优劣,直接决定了其调度的业务的稳定性。今年调度能力升级主要做了以下几方面工作:
大促云化是指大促时通过短时间使用阿里云的计算能力,大促峰值过后将资源释放归还给公共云继续售卖的一种资源使用方式。
大促云化的本质是资源的云化,包括计算资源、网络、IDC、服务器全部基于阿里云的底层技术,从2014年提出大促云化后,大促云化方案经过了多次升级改进,通过vpc网络打通云上云下互访,实现大促过后直接释放资源即可直接售卖,从而减少资源占用时长和改造成本。
2018年是计算存储分离破局之年,基于盘古远程盘,部署了数千台在线宿主机,超过50%的集群使用了存储计算分离技术,这项技术有望大幅减少未来阿里集团在服务器SSD盘的硬件成本投入。
内核是系统运行的基础,今年内核团队的备战主要集中在以下两个方面:
补丁前:MIN=8G, LOW=10G, HIGH=12G,LOW与MIN之间只有2G,当应用分配大量内存时,kswap还没来得及后台回收,系统内存就低于8G,这时应用只能进入direct reclaim,直接去回收。
补丁后:MIN=8G,LOW=25G,HIGH=27G
JVM协程今年部署范围交易核心应用扩大到导购,大促期间整体某导购核心应用水位从去年30%提升到今年的60%,业务没有新增机器。
部分核心应用默认开启ZenGC,GC暂停改善50%;
核心应用部署GCIH2.0,在安全性和性能上进行了改进,GC暂停时间最多改进20+%。
双十一0点之前低流量时降低Java进程内存20%+,双十一0点迅速恢复Java堆全量使用,峰值过后,继续缩小Java堆,减少进程内存20%+,99%和最大暂停大幅好于CMS,CMS为G1的150%~5X。
在Lindorm Velocity证,大幅减少Concurrent GC从1天30+次,减少为1天1次,推算堆增长率减少95%以上。
系统软件为打造阿里巴巴高性能、低成本的基础设施,在赋能业务发展、降低阿里巴巴资源运行成本方面实现了初步的技术积累,展望未来,系统软件仍有巨大的发展空间,欢迎各路技术牛人加入系统软件,一起打造阿里巴巴商业操作系统的核心软件。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
关注云原生中间件、微服务、Serverless、容器、Service Mesh等技术领域、聚焦云原生技术趋势、云原生大规模的落地实践