.NET Core 2.0在Azure WebApp中的具体运行机制探究

嘿，这个问题我之前折腾Azure WebApp部署.NET Core的时候也纠结过，刚好能给你掰扯清楚！

首先得明确那个Stack Overflow的结论是对的——在Azure WebApp里确实没法绕过IIS直接让Kestrel暴露给公网，但这并不意味着你的.NET Core 2.0应用是跑在IIS上的，实际的运行机制是「IIS做反向代理，Kestrel负责处理应用逻辑」，具体流程是这样的：

• Azure WebApp的底层环境是Windows Server + IIS，所有外部请求的入口都是IIS，这是平台层面的限制，没法改。
• 对于.NET Core应用，IIS会通过一个专门的模块（.NET Core 2.x里叫AspNetCoreModule，后来3.0+升级成AspNetCoreModuleV2）来对接Kestrel：
  1. 当第一个请求进来时，这个模块会检查你的.NET Core应用进程是否已经启动，如果没启动，就自动执行dotnet your-app.dll来启动Kestrel服务器。
  2. 启动成功后，模块会和Kestrel建立本地的通信连接（通常是用命名管道或者localhost端口），把所有来自IIS的请求转发给Kestrel处理。
  3. Kestrel处理完请求后，再把响应返回给这个模块，模块再传给IIS，最后返回给客户端。
• 另外，这个模块还负责进程监控：如果Kestrel进程意外挂了，它会自动重启你的应用，保证服务的可用性——这也是IIS托管带来的好处之一。

你可以去看看你部署后的应用根目录里的web.config文件，里面就有这个模块的配置，比如典型的配置片段是这样的：

<system.webServer>
  <handlers>
    <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
  </handlers>
  <aspNetCore processPath="dotnet" arguments=".\YourApp.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />
</system.webServer>

这里的processPath和arguments就是告诉IIS怎么启动你的.NET Core应用，modules指定了要用的代理模块。

简单总结就是：Azure WebApp里的IIS是「门面」，负责接请求、转发请求和监控进程；你的.NET Core应用的核心逻辑还是跑在Kestrel上，只是不能直接对外而已。

内容的提问来源于stack exchange，提问作者sstchur