Asp.Net Core中的反向代理和进程内HTTP服务器

1 回答

• 5

  根据official documentation：

  ASP.NET Core旨在在其自己的进程中运行，以便它可以跨平台一致地运行 . IIS，Nginx和Apache决定了他们自己的启动过程和环境;要直接使用它们，ASP.NET Core必须适应每个人的需求 . 使用Kestrel等Web服务器实现可以对启动过程和环境进行ASP.NET Core控制 . 因此，您只需设置这些Web服务器以代理对Kestrel的请求，而不是尝试将ASP.NET Core调整为IIS，Nginx或Apache . 无论您在何处部署，这种安排都允许您的Program.Main和Startup类基本相同 .

  除了拥有进程内http服务器使开发人员更容易使用东西 . 他们只是下载框架，安装它，无论他们使用什么操作系统（Windows，Linux或MacOS）或他们想要在以后使用什么Web服务器，它都可以开箱即用 . 他们只是启动 dotnet run 命令，启动http服务器，并在其上托管一个Web应用程序 .

  虽然在应用程序准备好 生产环境 时可以在开发环境中运行它，但开发人员应该记住安全性 . Kestrel Web服务器是一个非常新的Web服务器，因此它不具备IIS，Apache或Nginx在其长寿期间获得的所有安全性和其他有用功能 . 这是MS建议在 生产环境 环境中使用反向代理的唯一原因 . 反向代理的目标不仅是对进程内http服务器的转发请求，还负责安全性，压缩和良好的Web服务器可能提供的其他功能 .

  至于容器部署，它实际上取决于您想要实现的目标 . 有不同的场景：

  • 在同一容器中运行ASP.NET Core应用程序和反向代理 . 在这种情况下，ASP.NET核心应用程序通常配置为在本地端口上运行，例如5000，而反向代理绑定到端口80.通常不推荐这种方法，因为最佳实践说"Each container should have only one concern"

  • 在2个不同的容器中运行反向代理和ASP.NET Core应用程序 . 在这种情况下，您必须将这些容器相互链接，以便将请求从反向代理转发到Web应用程序 .

  • 在一个容器上运行反向代理，并将其配置为多个ASP.NET核心应用程序容器的反向代理 .

  回复于 2024-05-04T03:27:45+08:00