.NET Core 应用部署深度解析：从 IIS 到 Docker+Kestrel 的迁移与性能优化实战
引言
在云原生时代，.NET Core 应用的部署方式面临着战略性的选择。传统的 Windows IIS 方案稳定强大，而现代的 Linux Docker Kestrel 方案则轻量敏捷。本文将深入剖析两种架构的差异，提供详细的迁移指南，并重点探讨如何避免迁移过程中最危险的性能陷阱——线程池饥饿，助力您的应用顺利完成现代化转型。
第一部分：架构深度对比——理解根本差异
1.1 核心架构与请求流程
Windows IIS 方案采用成熟的分层架构：
- 请求流水线：
HTTP.Sys（内核驱动）→IIS→ASP.NET Core Module（ANCM）→Kestrel→ 应用程序 - 进程管理：由 IIS 应用池工作进程 (
w3wp.exe) 严格管理生命周期（启动、回收、关闭） - 角色定位：IIS 作为功能完备的应用服务器和反向代理，提供大量开箱即用的企业级功能
Linux Docker Kestrel 方案采用云原生架构：
- 请求流水线：客户端 → Nginx/Apache（反向代理，强烈推荐）→
Kestrel→ 应用程序 - 进程管理：由 Docker 引擎或 Kubernetes 等编排系统管理容器生命周期，实现极致弹性
- 角色定位：Kestrel 是专为.NET Core 设计的高性能、跨平台 web 服务器，专注于处理动态请求
1.2 功能与生态特性对比
| 特性维度 | Windows IIS | Linux + Docker + Kestrel |
|---|---|---|
| 管理方式 | 图形化IIS管理器，易于上手 | 配置文件、命令行、Infrastructure as Code |
| 功能集成 | 丰富：Windows认证、高级URL重写、动态IP限制、压缩等 | 精简：依赖反向代理（如Nginx）实现同类功能 |
| 安全模型 | 与Active Directory深度集成 | 基于Linux权限模型和容器隔离 |
| 日志系统 | Windows事件日志、IIS高级日志 | 标准输出（StdOut/Err），由Docker日志驱动收集 |
1.3 总结：如何选择？
- 选择 IIS 当：深度依赖Windows生态、团队技能匹配、需要利用特定IIS模块、现有Windows许可投资。
- 选择 Docker+Kestrel 当：追求云原生、微服务架构、成本优化、环境一致性、DevOps自动化流程。
第二部分：迁移实战——代码与配置指南
迁移的核心目标是：在环境变更后，保持或提升应用的并发性能与稳定性。
2.1 配置与基础设施代码迁移
1. 应用程序配置迁移：
将IIS中配置的连接字符串、API密钥等，全部迁移到 appsettings.Production.json 或通过Docker环境变量注入。
# 通过环境变量覆盖配置
docker run -e ConnectionStrings:DefaultConnection="Server=db;..." -e ASPNETCORE_ENVIRONMENT=Production my-app
2. 日志配置重构：
确保日志输出到控制台，并由Docker收集。
{
"Logging": {
"Console"