• 什么样的项目适合AOT模式开发?
  • 发布于 2个月前
  • 93 热度
    0 评论
  • 心已凉
  • 8 粉丝 32 篇博客
  •   
 什么项目适合AOT呢?那要先看AOT项目的优缺点有哪些,根据这些优缺点,我们就能判断自己的项目适合不适合用AOT模式开发。

下面是官方提供的一个.NET服务原生发布与AOT的比较,我们看到,在Linux下,大小几乎是原来的1/10,启动后工作内存,不到原来的一半,启动时间更是原来的1/4,而带来的RPS损失只有1/10;还是在Windows下,发布的大小更进一步,只有8.87M,不过内存是原来的一半以上,首次启动时间也要长一些,也是原来的1/4左右,损失的RPS只有5%左右,可以AOT项目带来的改善还是很明显示的,特别是当把应用发布到容器里时,占用资源明显降低,这对于容器的缩放很有利处。

从上可知,AOT的项目更小,即打包发布的程序包,或发布的Image都更小一些;第二就是更少,运行时占用内存更少,这为多副本应用节省了宝贵的内存资源(相当于省钱呀);第三就是首次启动更快,也就是冷启动更快,这为开发一些Funcation服务提供了可能。

说完了优点,现在说说缺点吧。首先AOT项目对反射,序列化,与原来的开发有较大的差别,所以不是一键切换。再就是,在调试模式,软件的表现,与AOT发布后的表现有可能不一样,毕竟调试模式,并不是在运行机器码。这两点是使用AOT开发最大的障碍,几乎所有功能都要以AOT发布后的结果为准,这就使开发效率没有原来那么高。再有一点就是现在的一次发布,可以用龟速来形容,所需的时间用来冲一杯咖啡都还有剩余。

缩合上面的分析,我们可以得出下面三类应用适合用AOT方式开发发布:
1.FaaS类服务,对于一些复杂算法,独立计算类小服务,可以用AOT来发布。
2.对于一些基础服务,调用频率高,要求更高的性价比:占用资源少,产出高,比如上图的Linux下,如果采用AOT发布,我们启动两个Pod,资源用不到原来的一半,RPS却有大幅增加,这是很划算的性价。

3.再有就是一些简单,功能单一的业务服务也可以考虑用AOT发布,因为业务复杂的服务,所需的技术就会复杂,这对现阶段的AOT开发有一定的开发代价。等一等,有可能VS对AOT项目开发,调试,发布有很大改进,毕竟第一个吃螃蟹的人,有可能被夹嘴。
用户评论