技术分享 | 云原生算力时代-倚天实例技术架构与最佳实践解析

本文涉及的产品
云服务器 ECS,每月免费额度200元 3个月
云服务器ECS,u1 2核4GB 1个月
简介: 阿里云倚天实例基于平头哥半导体自研倚天710云原生处理器,倚天710使用ARMv9架构,采用业界领先的工艺设计,单芯片容纳高达600亿晶体管,内含128核CPU核心,主频2.75GHz,能同时兼顾性能和功耗。同时得益于阿里云自研的CIPU处理器以及飞天云计算操作系统,倚天实例实现了芯片、计算架构及操作系统的协同优化,显著提升了算力性价比。目前阿里云倚天实例已经在视频编解码、科学计算、电商等领域得到了广泛的应用。

技术圈-1.jpg

2023年8月23日,阿里云弹性计算团队与智东西公开课联合出品的系列课程【阿里云弹性计算技术公开课】第六节正式播出,阿里云弹性计算产品专家庞雄伟带来了主题为《云原生算力时代——倚天实例技术架构与最佳实践解析》的课程分享,本期课程在阿里云官网、智东西官网、钉钉视频号、阿里云微信视频号、阿里云开发者微信视频号、阿里云创新中心直播平台&视频号等多平台同步播出。

阿里云倚天实例基于平头哥半导体自研倚天710云原生处理器,倚天710使用ARMv9架构,采用业界领先的工艺设计,单芯片容纳高达600亿晶体管,内含128核CPU核心,主频2.75GHz,能同时兼顾性能和功耗。同时得益于阿里云自研的CIPU处理器以及飞天云计算操作系统,倚天实例实现了芯片、计算架构及操作系统的协同优化,显著提升了算力性价比。目前阿里云倚天实例已经在视频编解码、科学计算、电商等领域得到了广泛的应用。


云原生算力时代——倚天实例技术架构与最佳实践解析 | 课程回放


本篇文章根据庞雄伟的课程整理而成,供大家阅览:

一、云原生算力需求的爆发及挑战

随着云计算移动互联网技术的飞速发展,当前数据的产生与存储已经呈现了爆发式的增长。这些数据包括社交媒体和个人信息以及物联网的数据。以上海量数据的分析与处理,对算力的并发以及实时处理的能力也提出了更高的要求。

幻灯片4.JPG

随着AI技术的不断发展,当前对于算力的要求也非常高。如果大家有刷视频、玩淘宝购物等习惯,我们的行为都会被这些APP抓取,并为我们推荐更加感兴趣的产品、购物链接等等,在这个过程中充斥着推理算法的加持。当然这些算法也极大的消耗了CPU和GPU的算力。

在数据中心维度,我们作为能耗大户,目前在全球各国的数据中心对于整个能耗的指标也做出了比较硬性的要求。比如一个数据中心有6000个机柜,一年就要消耗6亿度电。如果一个互联网公司在一个城市建三个数据中心(当前云计算公司在一个Region里部署三个ECS还是比较普遍的),一年就要消耗18亿度电。预计到2025年,全球数据中心的耗电量能达到接近4000亿kwh。整个耗电量占所有电量的4%,所以它的能耗还是非常高的。

因此,AI、机器学习、大规模的视频处理、编解码等高负载的应用,提高了整个计算的要求,以及算力强度、并发、应用的复杂程度,同时对于云厂商也提出了前所未有的极高挑战,这里也在迫使服务器芯片厂商不断改变,不断加速发展。

幻灯片5.JPG

目前我们业务的发展,对算力的挑战也比较大。但在算力需求暴涨的同时,摩尔定律演进速度却在减慢。现在大家经常看到的一句话就是,摩尔定律对于CPU代谢的演进已经失效了,也就是说硬件技术进步的红利见底,CPU性能提升遭遇瓶颈,传统服务器无法满足算力需求。目前大家会通过解压高这个词描述当前CPU的演进。

CPU算力的提升大部分还是通过提升基频或者CPU单核算力,这个算力往往也需要更高的功耗。随着CPU功耗的增加或者核数的降低,来提升算力水平,硬件和芯片的成本也在呈现上涨的趋势。

云计算它是一个多租户的场景,在面对一些高密的计算任务时,比如高性能计算、大数据计算、视频转码等,因为CPU线程之间的资源争抢,以及共享CPU Cache等机制导致租户之间处理需要相互排队,导致性能波动。这也是目前在云领域或者在计算领域需要解决的问题。

幻灯片6.JPG

大家最早接触ARM应该是移动手机。从2008年开始,Android+ARM的组合已经就被大家所了解。现在移动互联网的领域,不论大家用的是安卓还是苹果,ARM已经发展的非常成熟了,而且它的占有量已经占据了主导地位。

因为ARM的功耗和性价比较低,所以在服务器市场里,ARM架构也对x86进行相应的挑战。主要总结了三点:

第一,体积小。ARM的RISC指令长度32bit固定,不需要额外的指令变长处理单元,消耗少量内存,节省芯片面积。同时因为RISC处理器结构简单,布局紧凑,设计周期短,易于采用先进工艺,M芯片能够采用目前最先进的5nm工艺。

第二,效率高。ARM处理器使用更多寄存器,执行速度更快;大部分数据操作都可在寄存器内完成。其次,寻址方式更简单,寻址种类少,执行效率高;x86寻址方式复杂,内部也会转换成类似risc的多条简单操作,执行效率低。

第三,能耗低。RISC单元电路小,所以面积小,功耗低,带来了M处理器更多的核数和较低的功耗。这样它的性价比不管在移动领域还是在服务器领域都能带来更大的收益。

ARM整体采用的是一个比较开放的授权策略,也就是说在X86领域主要的玩家还是Intel和AMD。因为ARM架构采用的是开源IP授权的方式,这也给更多的服器厂商通过芯片自研的开放的机会。

幻灯片7.JPG

上图是全球服务器市场出货的量化图。从全球的服务器出货量来看,当前X86的服务器还是占据了主导的地位。在2019年,X86服务器主要包含Intel和AMD,整体的出货量超过了99%,而ARM CPU的整体占比只有0.7%。但到了2022年, ARM CPU的出货量达到了7.1%,虽然这个数字与Intel和AMD的99%相比还是低很多的,但它在短短三年的时间增长了接近10倍。所以从目前客户的需求来看,企业级市场对ARM的认可度也在逐步提升。

目前全球范围的主流的互联网公司也都参与到ARM产品的研发中来,推出了基于ARM架构的产品。以云服务为例,2019年就发布了基于ARM架构的自研的CPU产品,并在数据中心使用它自研的产品逐步替代传统的芯片,而且取得了比较大规模的售卖。

所以从国内外的这些公司来看,对于ARM这条赛道大家还是比较认可的,所以才投入了这么大的人力、物力以及资源。

幻灯片8.JPG

从生态这个维度,比如X86从80-90年代开始,就已经在PC领域以及后来的服务器领域有长足的发展了,所以ARM对标X86还是有较大的差距的。但通过这几年的时间,ARM持续致力于开源软件开发和支持,已经支持100多个开源项目。

如上图所示,从下到上依次是网络、操作系统、虚拟化、容器、编程所需要的主流的编程语言,上层的应用负载。在语言层面,目前针对解题的语言有Java、OpenJDK等是可以在ARM平台上直接运行的。在压缩方面,一些主流的计算库ARM也能给一些比较强烈的支撑。

上层的应用负载,大家在业务领域比较常见的有数据库、web、大数据、存储等主流的应用在ARM上都能比较完善的支持。目前大家比较经常提到的像CTD的流程,ARM在这里面支撑的也比较完善,比较传统有Github等原生支持ARM系统,也都是非常方便开发者在ARM上开发和构建。在操作系统领域,目前主流的有CentOS、Ubuntu,社区版OS有阿里云的龙蜥、自研的Alix3都支持ARM系统。

综上可以看到,从底层到上层,各个关键组件对ARM都有比较完善的支持了,所以当前的生态虽然对标X86还有一定的差距,但从我们整体的应用角度来看,是没有任何瓶颈的。而且目前ARM以及开源社区以及原厂也在持续的投入当中。

二、倚天软硬一体架构解析

如下图所示,我们把倚天710定义成一个以云为中心的云原生处理器。这里大家经常会提到云原生的概念,那么这到底是不是一个噱头呢?

其实不是。在传统IT时代,以Intel和AMD为例,在云计算架构来看,我们的业务、软件、应用更多的是去适配当前的IT架构来发挥其性能、性价比的使能。

对于第三方芯片公司来说,它整体芯片能力上的迭代,是面向所有业务场景的,比如云和传统的业务。但从云公司的角度,以阿里云为例,我们拥有着几百万个客户以及各种复杂的应用和业务。最熟悉云计算或者云业务的肯定是云计算厂商,因为只有云计算厂商自己才知道我们的业务需要什么样差异化的需求,或者具备什么样的痛点需要去解决,以及什么样的芯片才能够特定性的把性能效率提升到最大化。

基于此,我们就提出了以云为中心的云原生处理器。下面将从三个维度分享:

第一,面向多租户。在传统的服务器领域,我们将售卖物理机,这个物理机可能面向私有云,这个私有云也可能面向单一的客户,所以这里跑的租户可能是比较单一的。从云业务方面来看,我们针对一台物理上进行虚拟化或者容器化之后,它可以跑很多租户的负载,这里面比较核心的点是我们不能让这些租户之间产生任何的性能争抢,要保证性能的可预期性。

此外,相同物理机可能会开不同规格的VM,针对单一组,可能会开2核/4核/8核,最大开到32核。但不同规格的性能是否可以和规格量化的线性度匹配性能值,这个也是很重要,因为只有这样才能够有效的规划云业务的负载,达到成本的最优。

第二,以CIPU为核心。阿里云做CIPU已经有七年的时间了,我们把它定义为一个云数据中心的专用处理器,它的目标是实现CPU、网络、存储能力的卸载,以实现IO能力的加速。

从传统的芯片来看,追求整体性能以及产品的性价比是比较大的目标,为了追求这个目标,往往需要尽最大的努力去提升单颗CPU的核数或者密度,同时去提升单核的性能。如果我们纯粹的去提升单颗CPU和密度的话,会遭遇摩尔定律的瓶颈。但如果我们从云的角度或者资源池的角度,通过CIPU云计算中心的处理器把算力资源、网络资源、存储的性能资源进行池化,就可以规避单一算力的瓶颈,实现性价比的提升了,同时也能提升我们云资源产品的稳定性。

第三,垂直场景加速。压缩、解压缩、加解密、AI等垂直场景的加速能力在很多芯片里都具备这个特性。但这个特性很多时候并不是云原生的,也就是说它并没有原生的去支持虚拟化的能力。而倚天710目前已经做到可以原生支持不同大小的vm规格,原生适配各个规格的性能。

幻灯片10.JPG

阿里云作为目前国内云计算的头部玩家,在2021年就推出了首款自研的云原生处理芯片,倚天710芯片,这颗芯片是阿里云第一颗纯粹意义上为云而生的CPU。倚天710芯片的晶体管密度达到600亿个,它也是当时首款基于arm v9架构打造的,有128个物理核心,它的CPU的基准算力测试采用了SPEC CPU2017,得到了440分的成绩,超过业绩标杆的20%。

在发布倚天710这个芯片之后,在去年的云栖大会上,我们同步推出了基于倚天芯片的ECS实例。在这一年中,我们在阿里巴巴集团内部已经完成了大规模的部署,不仅支撑了阿里巴巴内部的核心电商业务,同时在外部的互联网业务,比如生命科学计算、游戏相关的企业也提供了比较好的业务支撑。

此外,还针对一些主流的应用场景,比如数据库、大数据,视频编解码、AI推理等场景,我们的性价比也能提升到30%以上,单位算力的功耗降低了60%以上。

幻灯片11.JPG

从芯片算力的维度有两个比较核心的因素,分别是alu的计算单元,其次是CPU的Cache。CPU的Cache主要分为3层,L1 Cache、L2 Cache、L3 Cache,包括CPU的主频以及针对CPU的垂直场景的加速指令。

从ARM角度来看,倚天芯片没有超线程的概念,所以这也规避了它的性能争抢的问题。举了例子,8核32G的规格中8核代表了它有8个vcpu,如果对标X86实例,就代表它有8个线程,因为X86实例在云上是默认打开HT能力的。但从倚天实例来看,它就是对应8个物理核,而一个物理核PK一个线程,具备天然算力的优势。我们之前以X86的s为例进行过实测,SPEC CPU 2017整体的算力提升能达到30%-40%。

此外,对于倚天实例,它的L1、L2、L3的Cache大小,横向对比X86也有不同程度的提升。Cache容量越大,贡献的CPU算力也会更强劲一些。

我们在整体ECS定价的时候,有2核4G、2核8G、4核8G、4核32G的规格,我们都是按照vcpu的维度定的。所以虽然我们在单核算力上有比较好的提升,但从价格上它还是便宜的。和Intel新一代的ECS实例相比,相同规格的情况下,我们的价格能便宜20%以上,计算型实例可以便宜超过30%。

幻灯片12.JPG

下面介绍一下安全水位的概念。在实际的业务中,集群业务规模部署的时候都有一个安全水位的概念。大家发现当CPU利用率在50%以下的时候,随着应用负载的提升,CPU的算力也会相应的提升,但当CPU利用率超过50%的时候,这个应用的执行效率和服务时间就会变得比较差。所以大家在设置弹性伸缩的扩容阈值的时候,基本会以50%为阈值。超过50%的时候,会去扩容更多的资源来满足业务的均衡。

这里有两个主要的原因。第一个,比如X86实例基本上都有一个睿频的概念,基频可能跑在2.7 GHz或者2.8 GHz,睿频可能就超过3.2 GHz,但当整体CPU的负载或者压力比较低的时候,就可以跑在它的睿频上以达到更好的性能。但如果负载比较高,它的CPU的功耗也会变高,这个时候就会出现降频的现象。

第二个,两个HT之间,它的L1 Cache和L2 Cache是共享的。随着负载压力变大,也会存在线程之间性能争抢的现象,这也会导致整体安全水位的阈值比较低。那么针对倚天的实例来看,因为倚天的CPU是物理核,所以不存在HT之间争抢的问题,同时它也没有睿频,他只有基频,目前基频是3 GHz。这里要重点强调了一下,在倚天实例刚刚推出的时候,基频是2.75 GHz,经过这段时间的物理硬件维度或者CPU维度的性能优化,目前已经达到了3 GHz。

这个3 GHz不会随着业务负载的大小而变化,所以也达到了比较好的性能可预期性。因此我们可以把整体安全水位的阈值提高,可以提高到70%-80。这样随着我们业务不同密度的提升,也从一定程度上节约了我们的成本。

幻灯片13.JPG

如上图所示,我们以编解码场景为例。大家都知道在视频编解码场景里,对CPU算力的压榨是比较厉害的。因为它比较消耗算力资源,也是比较典型的算力密集型的场景。

上图橙色曲线代表倚天710芯片,灰色曲线代表X86实例。横轴代表转码的路数,纵轴代表每个核贡献的fps性能值。可以看到随着转码路数的增加,倚天710芯片核X86芯片的负载压力也逐渐变大。随着CPU负载变高,X86实例有一个比较明显的下降趋势,而倚天710芯片则比较平稳,没有明显的下降趋势。

这也印证了倚天710芯片依托于它的物理核,没有睿频的特性。在算力密集型负载比较高的情况下,它的性能还是比较优异的。但对于低负载或者轻量的场景下,X86的性能相对好一些。这是因为在低负载情况下它可能会跑在睿频上,它睿频的值要比倚天好一些。所以这也是为什么说算力密集型场景,倚天实例有更好的性价比收益。

幻灯片14.JPG

首先,从倚天ECS实例角度评估一款产品的时候,我们不仅要看CPU的算力,还要看存储和网络IO的算力。刚才提到CIPU是把存储、网络和CPU整体纳管起来,相当于在物理队列加上CIPU后,它就是一个云化的虚拟计算资源池。它可以把存储和网络卸载到中央硬件上去处理,这样可以有效提升整体的IO能力。因为只有网络和存储IO能力上的提升,再结合CIPU算力提升,才能实现ECS实例的产品在E to E 或者端到端性能上有更好的表现。

其次,大家知道针对单一芯片,从物理核的角度,128核已经比较高了,但对于1U的服务器,如果采用双路的设计方式,一个服务器里将有256核。如果我们放在云上来看,开2核的规格可以开128个。如果一个规格对应一个租户,就是128个租户。如果其中的一个芯片、关联的内存、主板、其他R6的组件发生故障,这128个实例以及关联的128个租户都会对应的发生业务上的中断,所以我们为了降低它的爆炸半径,目前结合CIPU采用了一种双单路的设计方式,既保证了服务器CPU核数的密度,同时也降低了整体的发展环境,提升了产品的稳定性。

然后,倚天实例从网络IO特性上是支持eRDMA能力的。eRDMA这个术语,在传统的HT场景听的比较多,因为它可以有效提升东西向的网络吞吐,对吞吐消耗比较高,同时对AI、VPC的长尾时延要求也比较高。

目前倚天这款服务器采用的是2×100G的网络,也就是双向的网络达到200G。同时使用eRDMA之后,它的VPC网络时延可以降低到8微秒,有效的提升了算力密集型场景的性能。同时我们也支持NVMe协议的ESSD,IO时延对标之前的VPC的ESSD产品降低了10%。

因此大家可以看到,倚天ECS实例不仅是CPU算力上的提升,我们通过结合最新一代的CIPU也可以整体提升它的存储和网络IO的能力,最终使得这个ECS产品在端到端的表现变得更加优异。

幻灯片15.JPG

站在阿里云的角度,对标同代系的实例是一个较纯粹意义上的端到端的全栈自研。首先倚天710芯片结合了云原生的诉求,其次物理机采用了磐久服务器双单路的设计方式,还包含神龙的自研虚拟化,比如R03的自研操作系统、专门的技术软件。我们通过比较高效的协同优化,提升我们从软件到硬件的算力,同时还提升了产品的性价比,这样也能满足云上用户的多样性的计算需求。

近几年,经过在ARM层面的沉淀,我们也开发了很多软件加速库,典型的基础加速有相应的内存拷贝的提升,还有压缩、解压缩、视频编解码算法维度的优化。

不管是操作系统、编译器还是CPU上的硬件加速算法,我们会针对这些优化能力,从产品维度把它包装成性能。也就是说用户在购买倚天实例的时候,可以针对场景化的维度进行勾选,而不需要复杂的配置或者优化算法上的理解,开箱即用。这样能够更好、更快速的赋能客户自身的业务,享受阿里云在近几年中针对算法优化维度带来的成果。

幻灯片16.JPG

从物理服务器的角度,大家可能对这个产品的稳定性有一定的担忧,因为它比较新。但大家无需多虑,因为从ECS产品的角度,产品商业化之后它的sla是一致的,是三个975。

其次,传统芯片在设计的时候,比如测试、收集、问题的反馈处理,整体的周期是比较长的,链路也比较长。因为涉及多个公司之间的协作,而且芯片厂商也会根据客户的反馈进行重新设计以及改版。但对于云计算公司或者阿里云就不太一样了,因为我们既是客户又是供应商,问题的处理可能就是跨部门的协作。

然后,当前阿里云上已经有百万台服务器的规模,也支撑了各行各业不同的应用场景。这些复杂程度,也是倚天710在产品设计中核产品竞争力打造的绝佳的养料,针对问题的及时反馈,可以提升我们整体端到端产品的稳定性核性能。

三、倚天实例典型应用场景最佳实践

目前倚天实例在阿里巴巴集团内部,尤其是电商、存储、大数据、数据库场景等核心场景都已经有了应用,而且我们已经把电商的核心业务都放到了倚天实例上,通过统一的资源池进行调度,以应对像双十一这种高峰值的流量。

幻灯片18.JPG

此外,倚天实例在阿里巴巴集团,尤其在淘宝电商中,使用后整体带来的收益还是比较大的。对标使用x86实例,它的整体性能可以提升15%以上。而大数据场景,它承载了淘宝、菜鸟业务的数据分析,它使用倚天实例之后,整体的收益提升了20%。针对存储和数据库也有不同程度的性价比的提升,所以倚天实例在阿里巴巴集团内部的业务应用上,性价比的表现还是非常优异的。

同时也释放了一种技术红利,让终端的消费者在购买的时候以及商家在销售的时候,也体现了一把比较丝滑的购物体验。

幻灯片19.JPG

这是一个比较典型的视频编解码的场景,是一个在线教育客户。它对算力资源降本增效的诉求比较高,主要业务场景是视频的转录以及视频的后处理。

从这两个case来看,需要进行针对音视频流的编辑以及转码的处理,需要消耗大量CPU的资源。随着直播业务的上升之后,这些视频处理环节的IT成本也会同步增加。所以如何找到高性价比的替代方案,实现降本增效,是客户比较关注的点。

客户在使用倚天实例后,结合ARM架构以及倚天在算力密集型场景里比较优异的性能表现,整体视频转录模块的性能提升了28%,性价比提升了50%。因为本身倚天的ECS实例也是原封支持弹性伸缩的,所以针对客户波峰波谷的诉求,可以有效的满足客户的诉求。

幻灯片20.JPG

这是一个针对AI高级计算的场景,这个客户用的是一个开源的密度泛函软件叫ABACUS。这款软件主要应用于一项材料、药物以及新能源的开发。这种以AI结合高性能计算的软件,对于算力资源的消耗往往比转码还要高,因为本身它在性能PK测试过程中要关线程纯粹PK物理核。

如上图所示,最右边是倚天实例,它在相同业务负载的情况下,和7代的X86实例、6代的高水平实例的计算时间基本是一致的。但有一点需要大家注意,倚天实例使用的是4X的规格,对标X86的规格小一半。但相同规格的时候,单核CPU对标X86线程便宜20%-30%。

综合来看,相同的业务压力,取得了接近相同的计算时间,但成本解决了近70%,所以对于高性能的计算场景,客户的业务收益是非常巨大的。

幻灯片21.JPG

这是一个游戏场景,这个客户是一个国内比较顶级的移动网络游戏开发商和运营商,拥有多年的移动互联网开发经验。它开发的是一款塔防类的游戏,这款游戏首发的经验服、平台服、战斗服的底层全部采用了倚天实例。

但客户在最初选择倚天实例的时候还是有些担忧的,因为游戏场景对于SLA的稳定性、时延以及在线业务的要求是非常高的。所以选择倚天实例也是对倚天实例整体性价比核性能上的认可。客户在灰度业务的过程中,他发现使用倚天实例对比同价位差位的实例,整体在线的人数以及房间数提升了120%,结合价差,它的综合性价比提升了近2倍。

另外,因为游戏的底层服务都是用Java语言写的,所以它原生支持ARM和x86架构。且不存在生态的差异,也不存在任何的迁移成本。

幻灯片22.JPG

大数据场景也是一个比较典型的算力密集型场景,这个客户的一部分离线业务放在了传统的IT机房里。在选用了倚天实例之后,他采用了一个比较典型的存算分离的架构,就是在初始平替掉它的算力资源,性能提升可以超过30%。

同时,现在我们的大数据产品也支持了PAAS产品的EMR,用户也可以直接选择EMR+倚天ECS的产品组合,享受高性价比带来的红利。

四、X86->Arm迁移最佳实践

幻灯片25.JPG

接下来和大家分享一下X86架构向ARM架构迁移的实践。

X86架构和ARM架构在底层指令集层面存在一定的差异,传统意义上X86业务在一定程度上无法在ARM上无缝运行,但也区分一些场景,上图是我罗列的一些场景,以及从技术维度的一些区分。

大家都知道编程语言分为两种,一种是编译型语言,一种是解释型语言。目前我们运行的这些软件和应用,基本上都是采用高级语言进行编写的。编译型语言基本上是以C/C++为主,解释型语言主要以Java、Python为主。

编译型语言是指通过编译之后才能够在机器上运行;解释型语言,以Java为例,它有一层Java虚拟机,可以屏蔽架构的差异,也具备更好的一致性。也就是说解释型语言的平台屏蔽性是最好的,但执行效率相对比较低。编译型语言在编译成二进制的机器码之后,它的执行效率比较高,但它的架构的差异性或者屏蔽性比较弱。

幻灯片26.JPG

所以编译型语言,这里以C/C++为例,它还是需要进行相应的源代码的修改。上图罗列了比较典型的四步,宏的替换、内联参数、内联函数的替换,在编译的时候也要指定ARM的参数。

此外,在编译器的选择上,我们建议选择GCC10的版本,LLVM建议选择13的版本,Glibc 建议选择2.3.2的版本。

幻灯片27.JPG

Java本身就比较简单,编译之后直接就编译了Java的字节码,之后底层也就屏蔽了X86和ARM架构,可以无缝的去执行,也不需要重新编译,直接部署即可。其中ARM架构的生态,对标X86还是存在一定的劣势的,ARM的企业级生态上的发展是在2019年之后,所以对于新的JDK版本,在ARM性能上的表现是比较好的。

这里我们建议使用JDK 11,当然JDK 8也能用,但它的性能表现可能对标新版本的JDK会差一些。此外,阿里云Dragonwell已经开源,它可以很好地把倚天的性能发挥出来。

幻灯片28.JPG

ARM的架构以及物理核的设计机制,从算力的角度要比X86好一些,所以我们做了软件系统方面的算法优化、算力上的提升以及业务迁移,但更多是减弱了它生态上的劣势,弥补生态的不足,把它的硬件性能发挥出来。

其次,我们在业务迁移的历史沉淀上和经验积累上也是非常丰富的。在阿里集团内部、电商、数据库、大数据、存储等方面,我们有多年的架构迁移经验。同时我们也有相应的工具,比如CodeScan,升级后叫Easy倚天。客户通过这个工具把相应的代码包放上去,之后我们会他一个报告,里面会给出明确的修改建议。这样会非常有效的提升客户迁移的效率,因为老的jar包可能需要升级之后才能支持ARM。

客户业务迁移之后,我们还提供一键式专家调优工具。这个工具可以把我们沉淀下来的调优的经验,通过一键的方式去使能客户的业务。对于一些复杂的业务系统或者客户业务迁移经验比较少,我们也能派出倚天的专业团队去驻场,进行业务赋能或者人员培训。

幻灯片29.JPG

从容器的角度,目前对ARM生态的支持也是非常完善的。

目前整个CSE流程里,如果我们是一个混合的架构,也就是既有X86也有ARM,我们可以通过多版本镜像构建的方式进行相应的CICD。

举个例子,我们有一个容器镜像,既需要在X86上运行,也需要在ARM上运行。我们可以通过wb的x打包两个镜像,但只有唯一的一个镜像ID。所以在业务层不敢多加高镜像,智能通过在拉取镜像的时候指定架构即可。所以对于镜像或者容器的混合部署,也是非常简单的。从业务态来看,客户不需要有过多的担心。

幻灯片30.JPG

阿里云目前主流的PAAS产品,包含EHPC、数据库RDS、大数据EMR、视频云、钉钉等,都已经基于倚天实例进行了相应的构建。如果客户直接使用基于倚天的PAAS产品,是不需要进行相应的局限性的调优的,因为我们已经经历了很长时间的调优和适配,可以直接享受倚天带来的性价比的收益。

幻灯片31.JPG

我们在阿里云开发者社区也上线了倚天的子社区。我们会同步发布一些性能优化的成果、工具以及业务层面的问题,并作出及时性的解答。对于倚天实例定期的运营活动,比如产品的免费试用,我们也会及时的在视频里同步更新。在技术层面,分享业务迁移的成果,这样可以有效的与业务开发者进行良性的互动,扩大我们在倚天以及ARM上的生态。

以上就是本次课程的全部内容,同时想要了解更多精彩直播/观看课程回放的同学,可以扫描下方海报中的二维码/点击回看,均可观看课程。

庞雄伟-含二维码.jpg

相关文章
|
5天前
|
消息中间件 监控 大数据
Kafka消息队列架构与应用场景探讨:面试经验与必备知识点解析
【4月更文挑战第9天】本文详尽探讨了Kafka的消息队列架构,包括Broker、Producer、Consumer、Topic和Partition等核心概念,以及消息生产和消费流程。此外,还介绍了Kafka在微服务、实时数据处理、数据管道和数据仓库等场景的应用。针对面试,文章解析了Kafka与传统消息队列的区别、实际项目挑战及解决方案,并展望了Kafka的未来发展趋势。附带Java Producer和Consumer的代码示例,帮助读者巩固技术理解,为面试做好准备。
31 0
|
4天前
|
资源调度 前端开发 JavaScript
第十章(应用场景篇) Single-SPA微前端架构深度解析与实践教程
第十章(应用场景篇) Single-SPA微前端架构深度解析与实践教程
|
5天前
|
运维 Kubernetes Cloud Native
构建高效云原生运维体系:Kubernetes最佳实践
【5月更文挑战第9天】 在动态和快速演变的云计算环境中,高效的运维是确保应用稳定性与性能的关键。本文将深入探讨在Kubernetes环境下,如何通过一系列最佳实践来构建一个高效且响应灵敏的云原生运维体系。文章不仅涵盖了容器化技术的选择与优化、自动化部署、持续集成/持续交付(CI/CD)流程的整合,还讨论了监控、日志管理以及灾难恢复策略的重要性。这些实践旨在帮助运维团队有效应对微服务架构下的复杂性,确保系统可靠性及业务的连续性。
|
3天前
|
iOS开发 Python
mac:python安装路径,带你全面解析Python框架体系架构view篇
mac:python安装路径,带你全面解析Python框架体系架构view篇
|
5天前
|
监控 持续交付 Docker
使用Docker进行微服务架构的最佳实践
【5月更文挑战第10天】本文探讨了使用Docker实施微服务架构的最佳实践。首先,理解微服务架构是拆分小型独立服务的模式,借助Docker实现快速部署、高可移植性和环境一致性。Docker的优势在于服务扩展、容器编排、自动化构建与部署。最佳实践包括:定义清晰服务边界,使用Dockerfile和Docker Compose自动化构建,利用Docker Swarm或Kubernetes编排,实施服务发现和负载均衡,监控与日志记录,以及持续集成和持续部署。Docker虽重要,但需与其他技术结合以确保系统整体稳定性。
|
5天前
|
消息中间件 数据管理 持续交付
构建高效微服务架构的最佳实践
【5月更文挑战第6天】在动态和快速演变的现代软件开发领域,微服务架构已经成为促进敏捷开发和部署的关键模式。本文将深入探讨构建和维护高效微服务架构的策略,包括服务划分准则、通信机制、数据管理及持续集成与持续交付(CI/CD)的实施。通过分析不同业务场景下的应用案例,本文旨在为开发者提供一套行之有效的指导原则和实践方法,以支持他们构建可扩展、灵活且高效的微服务系统。
100 2
|
5天前
|
消息中间件 数据库 开发者
构建高效微服务架构:后端开发的最佳实践
【4月更文挑战第30天】在现代软件开发中,微服务架构已成为一种流行且有效的方法,它能够提高系统的可扩展性、弹性和维护性。本文将探讨后端开发中构建微服务架构的关键要素,包括服务划分、通信机制、数据一致性和容错处理。通过深入分析这些要素,我们将提供一系列最佳实践,帮助开发者构建一个高性能、可维护的微服务系统。
|
5天前
|
前端开发 测试技术 数据处理
安卓开发中的MVP架构模式深度解析
【4月更文挑战第30天】在移动应用开发领域,模型-视图-呈现器(Model-View-Presenter, MVP)是一种广泛采用的架构模式。它旨在通过解耦组件间的直接交互来提高代码的可维护性和可测试性。本文将深入探讨MVP在安卓开发中的应用,揭示其如何促进代码的模块化,提升用户界面的响应性,并简化单元测试过程。我们将从理论概念出发,逐步过渡到实践案例,为读者提供一套行之有效的MVP实施策略。
|
5天前
|
Dart 测试技术 UED
Dart 和 Flutter 错误处理指南 | 最佳实践全解析
深入探索 Dart 和 Flutter 中的错误处理技术,从编译时错误到运行时异常,带你学习如何优雅地处理应用程序中的各种意外情况。了解最佳实践,让你的应用程序稳如磐石,用户体验持续优化!
Dart 和 Flutter 错误处理指南 | 最佳实践全解析
|
5天前
|
存储 运维 监控

推荐镜像

更多