3

【.NET 8】ASP.NET Core计划 - 支持更完善的AOT发布 - InCerry

 1 year ago
source link: https://www.cnblogs.com/InCerry/p/Support-publishing-ASP-NET-Core-API-apps-with-Native-AOT.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

【.NET 8】ASP.NET Core计划 - 支持更完善的AOT发布

.NET7.0刚发布不久,.NET社区开始了.NET8.0的开发,重心重新回到了新功能的迭代。

我们知道在.NET7.0中一个令人激动的特新就是支持了NativeAOT,我们可以通过NativeAOT生成本机程序,由于无需JIT编译,所以无需安装.NET Runtime,也进一步的提升了.程序的启动速度,降低了程序的体积,在客户端软件开发、ServerLess等场景会有不错的前景。关于NativeAOT发布的详情可以点下方链接:
https://learn.microsoft.com/zh-cn/dotnet/core/deploying/native-aot/

作为地表最强的.NET WEB服务器ASP.NET Core,自然也是支持NativeAOT编译,而今天就是为大家介绍关于.NET8.0中ASP.NET Core中计划的一些NativeAOT改进。

.NET 7引入了对将.NET控制台项目作为本地AOT发布的支持,产生了一个独立的、针对平台的可执行文件,没有任何运行时JIT。本地AOT应用程序启动非常快,而且使用的内存更少。该应用程序可以被部署到没有安装任何.NET运行时的机器或容器中。在.NET 8中,我们将把对本地AOT的支持扩展到ASP.NET Core,首先是以云为重点,用最小的API构建的API应用程序,满足关于发布文件大小、启动时间、工作集和吞吐性能的期望。

如前所述,.NET8.0的主要重点是使用Minimal APIs实现ASP.NET Core API应用程序的本地AOT发布。这里的 "支持本地AOT"是指确保项目能够通过<PublishAOT>项目属性启用本地AOT发布,并且由此产生的开发经验能够引导开发人员制作本地AOT发布的应用程序,而不会出现构建、发布或运行时警告和错误。这意味着ASP.NET Core和.NET的大多数基础功能领域都需要更新,以支持本地AOT,包括:

  • 托管API,包括WebApplication,等等。
  • Kestrel HTTP服务器
  • 配置和选项
  • 依赖性注入
  • 通用中间件
  • 认证和授权
  • 最低限度的API
  • 用ADO.NET进行数据访问(SQLite和PostgreSQL为主要目标)
  • 支持OpenAPI
  • 可观测性和诊断

此外,作为一个次要目标,我们将在实现以下功能领域的NativeAOT发布方面取得进展:

  • SignalR
  • MVC Web APIs
  • Entity Framework

以下功能领域暂时不在NativeAOT支持的范围内:

  • MVC视图和Razor页面
  • Blazor服务器

开发经验原则

本地AOT有一些限制,这意味着在发布本地AOT时不支持.NET中的某些API和代码模式。这些包括依赖运行时JIT的功能,如动态代码生成和编译、汇编加载等,以及导致代码被本地AOT编译过程修剪掉的模式,这些都是执行应用程序所需要的,导致运行时失败。

在为ASP.NET Core增加对本地AOT的支持时,我们必须确保开发体验是这样的:开发人员可以合理地确定他们的应用程序在发布为本地AOT后将如何运行。如果当前的API和功能的设计方式与原生AOT不兼容,我们将利用包括源码生成器、分析器和代码修复器在内的工具,让现有的API与NativeAOT协同工作,或者让开发者以合理的方式更新他们的应用程序与NativeAOT协同工作。

这项工作的第一阶段是使用新的项目模板创建ASP.NET Core API项目,启用本地AOT,可以在没有任何警告或错误的情况下构建、发布和运行,并且满足可执行文件大小、启动时间、工作集和吞吐量的定义指标。

这些指标主要以Linux为重点,因为它是主要的部署目标,但Windows和macOS上的大小仍将被跟踪,并与这些目标保持一致,因为在候选平台调查期间,它往往有助于感知。

  • 10MB的可执行文件大小
  • <50毫秒的启动时间(准备接受第一个请求)。
  • <50 MB的工作集内存足迹(准备接受第一个请求)。
  • <50 MB的工作集内存占用(处理完负载测试)。
  • 在Citrine perf环境下,默认CoreCLR RPS的5%以内

这里的 "默认"是指与基于CoreCLR的应用程序部署的默认配置相比,例如包括分层JIT。

第二阶段建立在第一阶段的基础上,使更多的"真实世界"的ASP.NET Core API应用程序成为本地AOT发布。这些应用程序将使用更多通常与在云环境中运行API应用程序有关的功能,包括AuthN/Z、数据访问、OpenTelemetry等。TrimmedTodo API应用程序将作为这种应用程序的最初例子。

这些主要是以Linux为重点,因为这是主要的部署目标,但在Windows和macOS上的大小仍将被跟踪,并与这些目标保持一致,因为它往往有助于在候选平台调查中的感知。

  • 20MB的可执行文件大小
  • <150毫秒的启动时间(准备接受第一个请求)。
  • <60 MB工作集内存占用(准备接受第一个请求)。
  • <60 MB的工作集内存占用(处理完负载测试)。
  • RPS在Citrine性能环境中的目标待定

我们从.NET社区最新的计划可以看出,ASP.NET Core将继续在云原生场景发力,通过支持NativeAOT来降低可执行文件大小、缩短启动时间降低内存占用,笔者本人是非常期待这样的更新,在之前笔者的文章AOT和单文件发布对程序性能的影响中测试了.NET6.0时代ASP.NET Core AOT的的一些数据,后面.NET8.0发布以后期待它的改进。

以下是.NET6.0 ASP.NET Core AOT的数据:

image-dotNet8.0%e4%b8%adASP.NET+Core+AOT%e6%94%af%e6%8c%81%e8%ae%a1%e5%88%92-230208214511029.png


image-dotNet8.0%e4%b8%adASP.NET+Core+AOT%e6%94%af%e6%8c%81%e8%ae%a1%e5%88%92-230208214543255.png


image-dotNet8.0%e4%b8%adASP.NET+Core+AOT%e6%94%af%e6%8c%81%e8%ae%a1%e5%88%92-230208214552015.png

Github对应链接:https://github.com/dotnet/aspnetcore/issues/45910


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK