为什么不鼓励使用 django 在生产中提供静态文件？答案

【问题标题】：Why serving static file in production, using django it's discouraged?为什么不鼓励使用 django 在生产中提供静态文件？
【发布时间】：2019-06-07 01:50:02
【问题描述】：

我开发了一个使用（显然）一些静态文件的 Web 应用程序，为了部署它，我选择使用 WSGI 解释器提供文件，并用于防火墙和反向代理后面的作业 gunicorn。

我的应用程序使用白噪声来服务器静态文件：一切正常，我对性能没有任何问题......但是，真的，我不明白为什么要直接使用 WSGI 解释器来提供这些静态文件的做法不鼓励 (LINK)，说：

这不适合生产使用！对于一些常见的部署策略...

我的意思是，我的服务是微服务的集合：DB-Frontend-Services-Etc...如果我需要扩展它们，我可以毫无问题地做到这一点，此外，使用这种理念，我不担心我的微服务的足迹：对我来说，这似乎是合乎逻辑的，但也许，对于世界其他人来说，这是一个完全不理智的策略。

【问题讨论】：

标签： django docker microservices gunicorn static-files

【解决方案1】：

您误解了该文档。可以使用 Whitenoise 来提供静态文件；这完全是它的用途。使用内部 Django 函数来执行此操作不是一个好主意，因为它效率低下。

【讨论】：

【解决方案2】：

我个人从 CDN 提供静态服务的三个原因，

1- 您正在用尽应用服务器的带宽并浪费时间获取这些静态文件，而不是将负载交给 CDN 来处理所有这些。（WhiteNoise 应该消除它）

2- AWS 等一些托管服务会向您收取额外的进出流量费用，而您可以使用 Cloudfront 和 S3 存储桶等更便宜的服务。

3- 我喜欢将我的应用服务器仅用于应用目的，并仅将每个服务用于其工作，这有助于我调试并减少故障点。

不过，另一方面，使用 WhiteNoise 之类的应用服务器提供静态数据比配置 CDN 容易得多。

希望这会有所帮助！

【讨论】：

“为什么我不从 CDN 提供静态服务”与原因不符。你的意思是相反的？

【解决方案3】：

使用 Whitenoise 没问题，因为：

Whitenoise 正是为此目的而制作的，因此非常高效
它将正确设置 HTTP 响应标头，以便客户端缓存文件。

但是这样想：不是为每个网页提供 1 或 2 个请求，您通常会收到 10 倍以上的请求（通常网页会请求一堆图像、一个或多个 css 文件、几个 js文件...）。这意味着您必须扩展您的应用程序服务器，以平均比将工作交给 CDN 提供 10 倍的流量。

顺便说一句，我已经写了一个关于这个主题的tutorial，这可能会有所帮助。

【讨论】：