Native AOT trong .NET 10 2026 - Kiến trúc Ahead-of-Time, Trimming và Startup Siêu Nhanh cho Cloud-Native

Posted on: 4/16/2026 5:14:50 PM

1. Vì sao Native AOT trở thành chuẩn triển khai mới của .NET 10

Trong suốt hai thập kỷ, .NET được xây dựng xung quanh một triết lý tưởng chừng bất di bất dịch: biên dịch mã nguồn thành IL (Intermediate Language), gói vào assembly, rồi để CLR tải lên và để RyuJIT biên dịch just-in-time thành mã máy ngay lúc chạy. Mô hình này cho .NET sự linh hoạt tuyệt vời - reflection, dynamic loading, plugin, expression tree, emit IL tại runtime - nhưng đồng thời cũng để lại ba gánh nặng mà hệ sinh thái cloud-native hiện đại ngày càng khó dung thứ: cold start vài trăm mili-giây tới vài giây, working set vài chục tới vài trăm MB cho cả những service nhỏ nhất, và kích thước container vượt mốc 200 MB ngay cả khi đã chọn alpine.

Với .NET 10 LTS phát hành cuối 2025, Native AOT chính thức bước ra khỏi phạm vi "thử nghiệm cho console app" và trở thành một kênh triển khai production-grade bao phủ hầu hết ứng dụng ASP.NET Core, gRPC, Worker Service, Minimal API và System.CommandLine. Native AOT không còn là lựa chọn dành riêng cho người viết CLI hay SDK; nó là công cụ đầu tiên mà một kiến trúc sư hệ thống cần cân nhắc khi thiết kế service phải khởi động trong vài chục mili-giây để scale-to-zero, phải chạy trong memory hạn chế trên edge node, hoặc phải đi qua kiểm duyệt image với kích thước dưới 50 MB.

2. Hành trình từ JIT tới Native AOT - bản đồ tiến hóa của .NET code generation

Để hiểu vì sao Native AOT có kiến trúc như hiện tại, cần nhìn lại hơn hai thập kỷ .NET đã thử nghiệm những mô hình biên dịch nào. Mỗi bước tiến đều là một mảnh ghép được gom lại vào ILCompiler của hôm nay.

3. Kiến trúc Native AOT - ILCompiler và cách mã máy được sinh ra

Native AOT không chỉ là một flag MSBuild. Nó là một đường ống biên dịch dài, thay thế CLR JIT bằng một chuỗi công đoạn chạy ngay lúc publish. Hiểu đường ống này là điều kiện tiên quyết để chẩn đoán lỗi trimming, phân tích kích thước binary, và tối ưu cold start.

flowchart LR
    A[C# Source] --> B[Roslyn Compiler]
    B --> C[Source Generators]
    C --> D[IL Assembly .dll]
    D --> E[ILLink Trimmer]
    E --> F[ILCompiler ILC]
    F --> G[RyuJIT AOT]
    G --> H[Object File .o/.obj]
    H --> I[Native Linker ld/link.exe]
    I --> J[Native Executable]
    J --> K[Minimal Runtime Library]
    K --> L[OS Kernel]

Hình 1: Đường ống biên dịch Native AOT từ mã nguồn C# tới binary có thể chạy

3.1. Roslyn Compiler và Source Generators

Công đoạn đầu tiên giống hệt build thường: Roslyn biên dịch C# thành IL. Điểm khác biệt nằm ở việc Source Generators chạy sớm và đóng vai trò quyết định với AOT. Mọi nơi mà code runtime cần reflection (binding JSON, bind configuration, expression tree của LINQ to SQL, route matching của Minimal API) đều được thay bằng code được sinh tự động tại compile-time. Ví dụ System.Text.Json sinh ra JsonTypeInfo<T> cho từng kiểu cần serialize; Minimal API sinh ra delegate đã bind sẵn từng parameter; EF Core sinh ra compiled model cho từng DbContext.

3.2. ILLink - trimmer cắt toàn bộ code không dùng tới

Sau khi có IL đầy đủ, ILLink đi từ entry point (Main) theo đồ thị call, đánh dấu mọi type, method, field được tham chiếu, rồi xóa phần còn lại. Đây là công đoạn giảm kích thước dữ liệu mạnh mẽ nhất - với một Minimal API điển hình, trimmer cắt từ 70 MB IL xuống còn 8-12 MB IL. Trimmer cũng rewrite một số bytecode: thay typeof(T).GetProperty(...) bằng direct access khi chứng minh được type không dùng reflection động.

3.3. ILCompiler (ILC) - dịch IL sang native

ILC là trái tim của Native AOT. Nó được viết bằng C# (nằm trong dotnet/runtime), nhận IL đã trim và sinh ra object file dưới dạng ELF (Linux), Mach-O (macOS), hoặc COFF (Windows). ILC sử dụng chính RyuJIT nhưng chạy ở chế độ AOT - không emit JIT helper runtime, không sinh stub patch-on-call, thay vào đó sinh toàn bộ method có thể gọi được. ILC quản lý cả type layout, vtable, generic instantiation (đi theo danh sách generic cụ thể trong trimming đồ thị), và đặc biệt là universal generic expansion cho những case vtable đa hình qua nhiều kiểu.

3.4. Native linker và runtime tối giản

Kết thúc ILC, chuỗi build chuyển sang linker hệ thống - ld trên Linux/macOS, link.exe trên Windows. Linker ghép object file với một runtime cực kỳ gọn (System.Private.CoreLib được AOT cùng với app, cộng một thư viện libSystem.Native và libSystem.IO.Compression.Native nếu dùng tới). Không còn CLR full, không còn JIT, không còn metadata loader. Kết quả là một file nhị phân duy nhất, gọi thẳng syscall.

4. Trimming - nghệ thuật cắt code chết mà không làm sập ứng dụng

Trimming là phần khó nhất của AOT và cũng là nguồn gốc của phần lớn lỗi production. Về bản chất, trimmer phải chứng minh một method/type có chắc chắn được dùng hay không. Nếu code dùng reflection hoặc dynamic load, chứng minh này trở thành bài toán không giải được, và trimmer buộc phải suy đoán bảo thủ hoặc cảnh báo lập trình viên.

4.1. Mô hình đồ thị roots và reachability

Trimmer bắt đầu từ tập roots: Main, các public API nếu build thư viện, các entry thông qua [DynamicDependency]. Từ đó nó duyệt đồ thị call theo MSIL instruction: call, callvirt, newobj, ldtoken, ldstr đi qua một Type.GetType(string). Mỗi cạnh đi qua đánh dấu node đích là reachable. Sau khi duyệt xong, mọi type/method không được đánh dấu sẽ bị xóa.

flowchart TD
    A[Entry: Program.Main] --> B[WebApplicationBuilder.Build]
    B --> C[ServiceCollection.AddScoped]
    C --> D[UserService]
    D --> E[DbContext]
    E --> F[EF Compiled Model]
    B --> G[RouteEndpointBuilder]
    G --> H[RequestDelegateGenerator - source gen]
    H --> I[UserEndpoints.Map]
    I --> D
    J[Reflection: Activator.CreateInstance] -.-> K[Unknown Type]
    J -.-> L[TRIMMER WARN IL2072]
    style J stroke:#ff9800
    style K stroke:#ff9800
    style L stroke:#e94560

Hình 2: Trimmer đi theo đồ thị tĩnh; reflection động tạo cảnh báo IL20xx buộc lập trình viên cung cấp chứng cớ

4.2. Annotation chứng minh an toàn

Khi mã của bạn buộc phải dùng reflection (ví dụ một IoC container, một serializer tùy biến), bạn phải thông báo cho trimmer đối tượng nào cần giữ. Bộ attribute chuẩn gồm:

• [DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicConstructors | PublicProperties)] - áp lên tham số kiểu Type hoặc generic T, báo rằng code sẽ truy cập các member loại đó qua reflection. Trimmer sẽ giữ chúng.
• [RequiresUnreferencedCode("reason")] - đánh dấu một API không AOT-safe; mọi gọi tới nó sẽ cảnh báo người dùng phía trên.
• [RequiresDynamicCode("reason")] - mạnh hơn, báo rằng runtime sẽ sinh IL tại chỗ (ví dụ Expression.Compile()) - không AOT-safe hoàn toàn.
• [DynamicDependency("MethodName", typeof(Target))] - buộc trimmer giữ một method cụ thể, dùng khi reflection chắc chắn sẽ gọi nó.

4.3. Các cảnh báo IL2xxx thường gặp

5. Source Generators - vũ khí chống reflection

Source Generators là đôi cánh cho Native AOT. Thay vì sinh IL dynamic tại runtime (vốn bị [RequiresDynamicCode] cấm), các generator chạy bên trong Roslyn, đọc cú pháp và attribute của người dùng, rồi sinh ra C# source bình thường được compile cùng project. Runtime không còn cần reflection nữa - mã đã có sẵn cho mọi trường hợp cần thiết.

5.1. System.Text.Json source generator

Thay vì dùng JsonSerializer.Serialize(obj) mà bên trong dùng reflection, bạn khai báo một JsonSerializerContext với các kiểu cụ thể:

[JsonSerializable(typeof(WeatherForecast))]
[JsonSerializable(typeof(List<WeatherForecast>))]
[JsonSerializable(typeof(ApiError))]
public partial class AppJsonContext : JsonSerializerContext;

// Sử dụng:
var json = JsonSerializer.Serialize(forecast, AppJsonContext.Default.WeatherForecast);
var obj = JsonSerializer.Deserialize(json, AppJsonContext.Default.WeatherForecast);

Generator sinh ra partial class AppJsonContext với các static JsonTypeInfo<T> chứa sẵn reader/writer được unroll cho từng property. Runtime chỉ đọc struct, không dùng reflection. Hiệu năng serialize trung bình nhanh hơn reflection mode khoảng 30% và tuyệt đối AOT-safe.

5.2. Request Delegate Generator (RDG) cho Minimal API

Với Minimal API, bạn viết app.MapGet("/users/{id}", (int id, UserService svc) => svc.Get(id));. Trong mô hình cổ điển, runtime dùng reflection để đọc delegate, bind parameter, invoke method. RDG làm điều đó tại compile-time: nó phát hiện pattern app.MapXxx và sinh ra code đã bind sẵn từng kiểu tham số, trả về IResult. Bật cơ chế này bằng <PropertyGroup><EnableRequestDelegateGenerator>true</EnableRequestDelegateGenerator></PropertyGroup> (tự bật khi PublishAot=true).

5.3. Configuration Binding Source Generator

IConfiguration.Get<T>() bình thường dùng reflection để duyệt property và set từng giá trị. Configuration Binding Source Generator sinh ra method binding tĩnh cho mỗi kiểu T được gọi. Bật bằng <EnableConfigurationBindingGenerator>true</EnableConfigurationBindingGenerator>. Trong .NET 10 cơ chế này được bật mặc định khi AOT.

5.4. Logging Source Generator

Logging API kinh điển logger.LogInformation("User {Id} logged in", userId) gọi tới string.Format và reflection để tạo structured log. Generator LoggerMessage thay thế:

public static partial class Log
{
    [LoggerMessage(EventId = 100, Level = LogLevel.Information,
        Message = "User {UserId} logged in from {Ip}")]
    public static partial void UserLoggedIn(ILogger logger, int userId, string ip);
}

// Sử dụng: Log.UserLoggedIn(logger, 42, "10.0.0.1");

Generator sinh ra code zero-allocation: không box int, không tạo object[], structured fields được emit trực tiếp. Đây là pattern mặc định cho mọi log trong AOT project.

5.5. Regex Source Generator

new Regex(pattern) mặc định compile pattern tại runtime - không AOT-safe khi dùng RegexOptions.Compiled. Generator giải quyết:

public partial class Validators
{
    [GeneratedRegex(@"^[a-z0-9]+@[a-z0-9.-]+\.[a-z]{2,}$", RegexOptions.IgnoreCase)]
    public static partial Regex Email();
}

Generator sinh ra một Regex-subclass với state machine đã expand thành IL tĩnh, nhanh hơn RegexOptions.Compiled và AOT-safe 100%.

6. Hiệu năng - đo đạc định lượng JIT vs R2R vs Native AOT

Phân tích hiệu năng phải đi vào ba chiều: startup time (thời gian tính từ lúc gọi binary tới lúc request đầu tiên được trả lời), steady-state throughput (số request per second khi đã warm), và working set (RAM thực tế chiếm trên target host). Cả ba đều có đặc điểm trade-off riêng.

6.1. Bảng so sánh định lượng

6.2. Vì sao steady-state chậm hơn 5-15%?

RyuJIT tại runtime có thể nhìn thấy đặc điểm thực tế của code (ví dụ một virtual call 99% đi vào cùng một override, branch 99% đi một nhánh) và thực hiện Dynamic PGO: de-virtualize, inline heuristic, instrument counters. AOT compile không có dữ liệu runtime, buộc phải sinh code bảo thủ hơn. Khoảng cách này được rút ngắn nhờ Static PGO - .NET 10 hỗ trợ sinh profile từ chạy thử rồi feed vào ILC (<PublishAot>true</PublishAot><OptimizationPreference>Speed</OptimizationPreference> kết hợp với dotnet pgo). Trên workload ASP.NET Core TechEmpower, khoảng cách còn dưới 5%.

flowchart LR
    A[Request 1] --> B{JIT Tier 0}
    B --> C[Run unoptimized]
    C --> D[Counter++]
    D --> E{hot?}
    E -->|yes| F[Tier 1 PGO Compile]
    F --> G[Replace on-stack]
    G --> H[Fast path]
    I[AOT Compile] --> J[Static PGO profile]
    J --> K[Sinh native đã tối ưu]
    K --> L[Request 1 fast path]
    style I stroke:#4CAF50
    style L stroke:#4CAF50

Hình 3: JIT đạt tối ưu qua tier warm; AOT phải đạt tối ưu ngay lần đầu bằng Static PGO từ profile thu thập trước

6.3. Trade-off thực tế theo mô hình triển khai

Quyết định JIT hay AOT không phải "cái nào nhanh hơn" mà phụ thuộc vào mô hình tải thực tế:

• Service luôn on, tải đều, ít restart (K8s Deployment replicaSet cố định): JIT tiered có lợi thế steady-state 5-10%, cold start 500 ms hiếm khi là vấn đề. Dùng JIT + R2R là lựa chọn mặc định.
• Function/Job scale-to-zero (AWS Lambda, Cloud Run, Azure Container Apps Jobs): mỗi invocation có thể là cold. AOT tiết kiệm 70-90% cold start, đủ để đạt P99 dưới 200 ms thay vì 1.5-2 s.
• Edge compute, IoT, device: working set là ràng buộc. AOT giảm 50% RAM và 70% binary size, trực tiếp ảnh hưởng chi phí phần cứng.
• CLI tool phân phối: AOT cho single binary không cần cài runtime, cải thiện DX đáng kể. Dùng AOT là mặc định.

7. Mô hình ứng dụng hỗ trợ đầy đủ trong .NET 10

.NET 10 mở rộng đáng kể danh sách workload có thể AOT mà không phải hack. Danh sách dưới đây là các mô hình đã được Microsoft test chính thức với cảnh báo trimming bằng 0.

7.1. ASP.NET Core Minimal API + gRPC

Template dotnet new webapi -aot dựng project với PublishAot=true, JsonSerializerOptions.TypeInfoResolver nối tới context được generate, và middleware tối giản. gRPC server hỗ trợ đầy đủ qua Grpc.AspNetCore 2.65+, dùng Source Generator cho protobuf C# class. gRPC client cũng AOT-safe với GrpcClientFactory.

7.2. EF Core 10 với Compiled Model

EF Core historically dùng reflection để xây model từ DbContext. EF Core 10 giải quyết bằng dotnet ef dbcontext optimize sinh ra compiled model dưới dạng C# source:

public class AppDbContext : DbContext
{
    protected override void OnConfiguring(DbContextOptionsBuilder options)
    {
        options.UseSqlServer(connString)
               .UseModel(AppDbContextModel.Instance); // model đã compiled
    }
}

Compiled model xóa mọi reflection runtime. LINQ query vẫn dùng expression tree, nhưng đã được pre-compile qua Source Generator EF.CompileQuery cho các query hot-path. Với query động không pre-compile được, app vẫn chạy nhưng cần [RequiresDynamicCode] được Microsoft chấp nhận trong .NET 10.

7.3. Worker Service và System.CommandLine

Worker Service (background service đơn thuần) luôn là sân chơi sạch nhất của AOT - không HTTP, không DI phức tạp. Mẫu dotnet new worker -aot publish ra binary < 10 MB. System.CommandLine 2.0 là CLI framework chính thức AOT-first, sinh parser source-gen từ attribute [Command].

7.4. SignalR, OpenTelemetry, Polly

SignalR .NET 10 có JsonHubProtocol AOT-safe khi khai báo HubJsonContext. OpenTelemetry SDK 1.10+ bỏ mọi reflection, dùng Meter API trực tiếp. Polly v8 là class-based, không còn delegate reflection nên AOT-safe mặc định.

8. Native AOT trong triển khai cloud-native

Giá trị lớn nhất của Native AOT không nằm ở việc tiết kiệm vài trăm MB RAM. Nó nằm ở khả năng thay đổi mô hình triển khai: từ "vài service luôn on" sang "nhiều function scale-to-zero, spin-up theo request". Điều này kéo theo một loạt thay đổi kiến trúc hạ tầng.

8.1. Container image distroless và Chisel

Binary AOT không cần .NET runtime, không cần libc đầy đủ. Image base có thể là mcr.microsoft.com/dotnet/nightly/runtime-deps:10.0-noble-chiseled (dưới 6 MB uncompressed), hoặc Chisel (Canonical) với tập file tối thiểu cho glibc/musl. Dockerfile mẫu:

FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /src
COPY . .
RUN dotnet publish -c Release -o /app /p:PublishAot=true

FROM mcr.microsoft.com/dotnet/runtime-deps:10.0-noble-chiseled
WORKDIR /app
COPY --from=build /app .
USER app
ENTRYPOINT ["./MyApi"]

Image production kết quả khoảng 35-60 MB (tùy endpoint), so với 210 MB của build self-contained thông thường. Pull time và cold scale trên K8s cải thiện 4-6 lần.

8.2. AWS Lambda - Custom Runtime và SnapStart

Lambda runtime mặc định cho .NET là provided (Lambda sẽ warm một JIT runtime). Với AOT, bạn dùng provided.al2023 và upload binary self-contained. Cold start một Lambda .NET 10 AOT điển hình đạt 80-180 ms, so với 1.5-3 s của .NET 8 JIT. SnapStart (Lambda pre-warm snapshot) trở nên ít cần thiết khi AOT đạt dưới 200 ms tự thân.

8.3. Kubernetes scale-to-zero với KEDA

KEDA (Kubernetes Event-Driven Autoscaler) scale một Deployment xuống 0 pod khi không có event, rồi scale lên 1+ khi event xuất hiện. Ràng buộc duy nhất là pod mới phải sẵn sàng phục vụ trong vài trăm mili-giây để không timeout event. AOT biến điều kiện này khả thi cho service .NET - JIT truyền thống đơn giản không kịp. Kết hợp với distroless image 40 MB, pull + start pod xong dưới 2 giây tính cả network.

8.4. Edge runtime - Azure Container Apps Jobs, Cloudflare Containers

Azure Container Apps Jobs cho phép chạy one-shot job với billing per-second, cold start trên 10 s thường bị khách hàng phàn nàn. AOT đưa cold start .NET xuống mức có thể chấp nhận. Cloudflare Containers (2025+) yêu cầu container khởi động trong 400 ms; đây là ngưỡng chỉ AOT mới đạt.

9. Publish pipeline - từ csproj tới binary

Cấu hình tối thiểu cho một project AOT production-ready:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <PublishAot>true</PublishAot>
    <InvariantGlobalization>true</InvariantGlobalization>
    <StripSymbols>true</StripSymbols>
    <TrimMode>full</TrimMode>
    <OptimizationPreference>Speed</OptimizationPreference>
    <IlcGenerateStackTraceData>true</IlcGenerateStackTraceData>
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
    <EnableConfigurationBindingGenerator>true</EnableConfigurationBindingGenerator>
    <EnableRequestDelegateGenerator>true</EnableRequestDelegateGenerator>
  </PropertyGroup>
</Project>

9.1. Ý nghĩa từng thuộc tính

• PublishAot=true: bật toàn bộ đường ống Native AOT.
• InvariantGlobalization=true: bỏ ICU data khoảng 40 MB. Bắt buộc khi binary không cần culture-specific collation/parsing.
• StripSymbols=true: tách debug symbol ra file riêng, giảm binary 30-40%.
• TrimMode=full: trim tất cả assembly, kể cả framework. Ngược lại partial chỉ trim user code.
• OptimizationPreference=Speed: ILC ưu tiên tốc độ hơn kích thước. Đổi sang Size nếu target edge.
• IlcGenerateStackTraceData=true: giữ metadata cho exception stack trace; tắt đi cắt thêm 10-15% size nhưng stack trace sẽ chỉ còn địa chỉ.

9.2. Cross-compile linux-musl-x64 và linux-arm64

Publish cho Alpine/musl: dotnet publish -r linux-musl-x64 --self-contained. Cần cài clang và musl-tools trên build agent. Cho ARM64 (Graviton, Raspberry Pi): -r linux-arm64, cần qemu-user hoặc build runner ARM thật. CI/CD phổ biến GitHub Actions có runner ubuntu-24.04-arm native ARM từ 2025.

9.3. Pipeline GitHub Actions mẫu

name: build-aot
on: [push]
jobs:
  build:
    strategy:
      matrix:
        runtime: [linux-x64, linux-arm64, linux-musl-x64]
        include:
          - runtime: linux-x64
            runner: ubuntu-24.04
          - runtime: linux-arm64
            runner: ubuntu-24.04-arm
          - runtime: linux-musl-x64
            runner: ubuntu-24.04
    runs-on: ${{ matrix.runner }}
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-dotnet@v4
        with: { dotnet-version: '10.0.x' }
      - run: |
          sudo apt-get update
          sudo apt-get install -y clang zlib1g-dev
      - run: dotnet publish src/MyApi -c Release -r ${{ matrix.runtime }} -o out
      - uses: actions/upload-artifact@v4
        with:
          name: binary-${{ matrix.runtime }}
          path: out/MyApi

10. Debug, profile và observability trong runtime AOT

Một trong những mất mát lớn của AOT là hot reload và nhiều công cụ profiling dựa vào CLR. Bù lại, hệ sinh thái native debugger (gdb, lldb, WinDbg) làm việc trực tiếp với binary.

10.1. Debug với Visual Studio và lldb

VS 2026 hỗ trợ attach debugger vào binary AOT (cần build với StripSymbols=false). Trên Linux/macOS, lldb đi kèm dotnet-sos plugin vẫn hiển thị managed stack trace nếu IlcGenerateStackTraceData=true. Tuy nhiên không có hot reload, không có Edit & Continue - thay đổi phải build lại.

10.2. Profiling với dotnet-trace và perf

dotnet-trace vẫn hoạt động qua EventPipe vì AOT runtime cũng emit event. dotnet-counters đọc metric GC, threadpool, contention bình thường. Trên Linux, perf record đi thẳng vào binary, flame graph nhìn thấy method C# nếu giữ symbol.

10.3. OpenTelemetry integration

OpenTelemetry .NET 1.10+ hoàn toàn AOT-safe qua System.Diagnostics.Metrics. Exporter OTLP dùng HTTP/gRPC từ OpenTelemetry.Exporter.OpenTelemetryProtocol, không cần reflection. Cấu hình tối giản:

builder.Services.AddOpenTelemetry()
    .ConfigureResource(r => r.AddService("my-api"))
    .WithMetrics(m => m.AddAspNetCoreInstrumentation()
                       .AddRuntimeInstrumentation()
                       .AddOtlpExporter())
    .WithTracing(t => t.AddAspNetCoreInstrumentation()
                       .AddHttpClientInstrumentation()
                       .AddOtlpExporter());

11. Cạm bẫy thường gặp và cách tránh

Đưa dự án thật lên AOT luôn vấp phải vài vấn đề không ghi trong tài liệu. Dưới đây là những điều hầu như team nào cũng vấp phải trong 2-3 tuần đầu.

11.1. Assembly thứ ba không có annotation

Nhiều gói NuGet cũ (đặc biệt các gói năm 2019-2021) không có attribute trimming-friendly. Khi reference, trimmer sẽ cảnh báo hàng loạt IL2xxx từ assembly đó. Cách xử lý: kiểm tra phiên bản mới nhất trên NuGet.org; nếu không có, sử dụng [UnconditionalSuppressMessage] khoanh vùng và giám sát bằng unit test; cuối cùng là thay thế bằng thư viện khác.

11.2. Generic virtual method qua nhiều kiểu

Pattern public virtual T Get<T>(string key) nếu bị override trong nhiều class và gọi qua interface với nhiều kiểu T, ILC có thể không instantiate đủ. Giải pháp: hoặc đặt [DynamicDependency] liệt kê các cặp type cần hỗ trợ, hoặc refactor thành Get(Type t, string key) trả về object.

11.3. JSON polymorphism

Serialize kiểu base class với runtime type animal (derived) cần attribute [JsonDerivedType] hoặc JsonPolymorphism. Generator phải biết trước tập các derived type. Polymorphism "đóng" (known set) là AOT-safe; polymorphism "mở" (discover plugin) không AOT-safe.

11.4. Dependency Injection với Factory lambda

ASP.NET DI services.AddScoped<IFoo>(sp => new Foo(sp.GetRequiredService<IBar>())) là AOT-safe vì lambda được compile tĩnh. Nhưng services.AddScoped(typeof(IFoo<>), typeof(Foo<>)) (open generic) có thể gặp vấn đề với kiểu T không dự đoán trước - cần instantiate đầy đủ qua call-site tĩnh hoặc [DynamicDependency].

11.5. Culture-specific parsing khi bật InvariantGlobalization

Khi InvariantGlobalization=true, DateTime.Parse("12/04/2026") sẽ luôn dùng invariant culture, bất kể CultureInfo.CurrentCulture. Nếu app của bạn phụ thuộc định dạng theo locale, hoặc tắt invariant (và chấp nhận 40 MB ICU), hoặc refactor sang parse rõ ràng với CultureInfo cụ thể truyền vào.

12. Chiến lược di chuyển dự án hiện tại sang Native AOT

Migration không nên là "bật flag và build lại". Hãy làm theo 6 bước có thể đo lường được:

flowchart TD
    A[Bước 1: Audit assembly thứ ba] --> B[Bước 2: Bật IsTrimmable và đo cảnh báo]
    B --> C[Bước 3: Chuyển serializer sang source-gen]
    C --> D[Bước 4: Chuyển config/logging/regex sang source-gen]
    D --> E[Bước 5: Bật PublishAot và fix từng warning]
    E --> F[Bước 6: Benchmark + canary trên 10% traffic]
    F --> G{Stable?}
    G -->|yes| H[Rollout full]
    G -->|no| I[Rollback JIT, log incident]
    I --> J[Sửa issue, quay lại bước 5]

Hình 4: Quy trình migration JIT sang AOT theo 6 bước có check-point đo lường được

12.1. Bước 1 - Audit assembly thứ ba

Dùng công cụ dotnet list package --vulnerable và kiểm tra từng gói xem có metadata <IsTrimmable>true</IsTrimmable> không (xem file .nuspec). Gói không trimmable cần thay thế hoặc isolate.

12.2. Bước 2 - Bật trimming warning trước AOT

Thêm vào csproj <IsTrimmable>true</IsTrimmable> và <EnableTrimAnalyzer>true</EnableTrimAnalyzer>. Build. Fix tất cả warning IL2xxx trước khi bật AOT. Giai đoạn này không thay đổi runtime behavior, chỉ thu thập cảnh báo.

12.3. Bước 3-4 - Thay thế reflection bằng source generator

Serializer → JsonSerializerContext; Logging → LoggerMessage attribute; Regex → GeneratedRegex; Configuration → tự động sinh khi EnableConfigurationBindingGenerator=true. Chạy benchmark trước/sau để đảm bảo không regress.

12.4. Bước 5 - Bật PublishAot và fix warning IL3xxx

IL3050 (RequiresDynamicCode) không fix được bằng annotation. Nếu gặp trong code của bạn, refactor bỏ Expression.Compile, Reflection.Emit, Assembly.LoadFrom. Nếu gặp trong gói thứ ba, đợi update hoặc thay thế.

12.5. Bước 6 - Benchmark và canary rollout

Chạy song song JIT và AOT trên cùng load test; so sánh P50/P95/P99 latency, throughput, memory. Nếu AOT chậm hơn >10% ở steady-state, thu thập Static PGO profile từ JIT build rồi feed vào AOT. Canary 10% traffic ít nhất 48 giờ trước khi rollout 100%.

13. Checklist production - 12 điểm trước khi đưa AOT lên cloud

1. TreatWarningsAsErrors=true ngay từ ngày đầu - mọi IL2xxx/IL3xxx phải được xử lý, không bỏ qua.
2. CI build AOT trên 3 runtime - linux-x64, linux-arm64, linux-musl-x64. Nhiều bug xuất hiện chỉ trên một trong ba.
3. Unit test chạy trên cả JIT và AOT binary. Test JIT nhanh hơn và debug dễ hơn; test AOT bảo đảm trimmer không cắt nhầm.
4. Fuzz test JSON và config binding với các schema cận biên - generator có thể lỗi trên nested generic hiếm gặp.
5. Static PGO trên benchmark thực tế, check-in file profile vào Git cùng code - AOT build dùng profile này để đạt steady-state gần JIT.
6. Container image distroless hoặc Chisel - không dùng debian:slim nếu mục tiêu là size tối thiểu. Quét Trivy/Grype và chỉ mở port cần thiết.
7. Giám sát working set qua dotnet-counters hoặc OpenTelemetry. AOT binary ít memory hơn nhưng leak vẫn xảy ra - GC vẫn chạy.
8. Dự phòng JIT image cho rollback nhanh. Giữ hai pipeline song song trong 1-2 quý đầu, switch trong Helm values.
9. Log stack trace có ý nghĩa - bật IlcGenerateStackTraceData=true ngay cả khi tốn thêm 10% size; exception không có method name là ác mộng incident.
10. Cập nhật gói NuGet hàng quý - hệ sinh thái AOT đang tiến hóa nhanh, bug trimmer hôm nay thường được fix trong 1-2 release.
11. Training đội về cảnh báo IL, Source Generator pattern, và cách đọc báo cáo trimming. Native AOT yêu cầu kiến thức khác JIT; một senior không được cập nhật sẽ là điểm nghẽn.
12. Runbook cho incident AOT-specific - MissingMethodException trên method mà IDE báo exist là dấu hiệu trimmer, không phải bug logic. Incident response phải biết phân biệt.

14. Kết luận - Native AOT là cú thay đổi kiến trúc, không phải flag build

Native AOT trong .NET 10 không đơn thuần là một tối ưu. Nó đại diện cho sự thay đổi triết lý biên dịch đã được .NET hướng tới hơn một thập kỷ: từ "runtime thông minh, code đơn giản" sang "compile time thông minh, runtime tối giản". Với gần 90% workload ASP.NET Core phổ biến giờ đây AOT-ready, rào cản kỹ thuật đã được hạ xuống mức một kỹ sư .NET trung cấp có thể xử lý trong vòng một sprint. Rào cản còn lại chủ yếu là văn hóa và quy trình - đưa kỷ luật trimming warning vào CI, đào tạo đội về Source Generator, thiết kế observability phù hợp với binary không có JIT.

Giá trị thực sự không nằm ở con số "cold start 30 ms" hay "image 40 MB", mà ở việc mô hình triển khai mới trở nên khả thi. Khi service .NET có thể scale-to-zero và spin-up trong 200 ms, bạn có quyền đặt câu hỏi: còn service nào trong hệ thống đang trả phí 24/7 dù chỉ có tải 2 giờ mỗi ngày? Câu trả lời thường là nhiều hơn bạn nghĩ. Đây mới là nơi Native AOT mang lại ROI thực, vượt xa con số nano-giây trong benchmark.

Năm 2026, câu hỏi cho một team .NET không còn là "có nên dùng AOT không?" mà là "service nào trong hệ thống còn lý do hợp lý để không dùng AOT?". Với service mới, default nên là AOT-first cho tới khi có lý do ngược lại (hot reload dev, Razor view, Blazor Server, plugin động). Với service cũ, migration theo 6 bước ở mục 12 là con đường an toàn và có đo lường.

Kiến trúc sư hệ thống hiện đại không cần biết từng dòng trong ILCompiler, nhưng cần hiểu ranh giới - Native AOT cắt được gì, không cắt được gì, trade-off ở đâu. Hiểu được điều đó, bạn không chỉ tiết kiệm chi phí hạ tầng; bạn mở khóa những mô hình triển khai mà đội JIT không thể với tới.

15. Nguồn tham khảo

• Microsoft Learn - Native AOT deployment
• ASP.NET Core and Native AOT
• dotnet/runtime - ILCompiler source
• Microsoft DevBlogs - Performance Improvements in .NET
• Microsoft Learn - Prepare libraries for trimming
• System.Text.Json source generation
• EF Core - Compiled Models
• Trimming options reference
• Native AOT feature switches design doc
• Canonical - .NET on Ubuntu Chiseled Containers