对于在 ALB 后面的 AWS ECS 上运行的 asp.net 核心网站，Kestrel 是否足够？答案

【问题标题】：Is Kestrel sufficient for an asp.net core website running on AWS ECS behind an ALB?对于在 ALB 后面的 AWS ECS 上运行的 asp.net 核心网站，Kestrel 是否足够？
【发布时间】：2017-07-23 01:17:48
【问题描述】：

我正准备将 ASP.NET Core MVC 网站部署到生产环境。该应用程序将部署到 AWS ECS（EC2 容器服务）。不建议将 Kestrel 用于服务来自 Internet 的流量，并且建议将反向代理放在前面。我的问题是，AWS ALB 足够好吗？它执行 SSL 终止、负载平衡，并支持 HTTP/2 和 WebSocket。

我相信我正在放弃压缩（据我所知，ALB 或 Kestrel 都不支持它）。此设置缺少什么？我应该看一个额外的反向代理（haproxy/nginx）吗？额外的复杂性足以让我在没有必要的情况下不想走那条路。

【问题讨论】：

使用此解决方案需要考虑的一件事是您将如何管理 kestrel 流程。推荐的 Windows 解决方案（在 IIS 之后运行）通过 IIS 核心模块执行此操作。它会在第一次请求时启动 kestrel，如果失败则重新启动
对于 ECS，ALB/ECS 负责启动足够多的实例。
啊，好吧，我错过了容器服务部分，我没用过。听起来那样会很好。我刚刚从 ELB 切换到 NGINX，因为我们需要对负载平衡进行更精细的控制，但如果您的需求是基本的，ELB 可以正常工作。
我觉得红隼做不到 http/2 github.com/aspnet/KestrelHttpServer/issues/73

标签： asp.net amazon-web-services asp.net-core amazon-ecs kestrel-http-server

【解决方案1】：

如果您不需要压缩（它具有较小的 SEO 优势），那么您就可以开始了。

关于您的红隼应用程序有几点需要注意，当您将其放置在引用代理之后时，我确定您知道这些：

请求 url 的概念已经消失：因为代理转发请求，所以请求 url 始终是代理本身。
此外，协议将始终是 http 而不是 https。
负载平衡器每次都会在应用程序之间切换，因此使用 static 属性可以正常工作（但您没有意识到）的事情现在可能会崩溃。

我可以想象的 ALB 的缺点可能是您无法控制负载平衡的发生方式。如果这对您来说不是问题，那么我认为几乎任何反向代理都应该适合您。（如果你愿意，你甚至可以在 nodejs 中做一个简单的反向代理）。

【讨论】：

谢谢。虽然压缩很好，但它当然不是硬性要求。我现在使用 haproxy（用于本地 IIS），它确实需要一些时间来适应。至于最后一点，在某些方面它是有好处的——如果你的网站是有状态的，最好早点知道。