Web 服务器部署模型在业余爱好方面被打破

2026-08 假设您想要制作一个网络事物，并希望其他人在他们自己的服务器上托管。不幸的是，通过这样的想法，您立即将您的代码库锁定在其他打算私下托管的软件可以使用的几种效率技巧之外，并且您现在已经为自己重新发明了其他人已经做得更好的轮子而背负了重担。让我们从一个基线开始，随着需求的变化，我们将添加该基线：在几乎所有情况下，第一个部分也可能是一个功能相对强大的 Web 服务器，其中包括反向代理作为众多功能之一。一项非常常见的功能是提供静态文件，该文件当前由您的应用程序处理。静态文件 将静态文件服务卸载到反向代理并不是一个坏主意。它的实现可能会比您选择的时髦新框架的实现要好得多，即使不是，静态文件也不会再阻塞您的 python 或 Node Web 服务器可以同时处理的平庸的请求量。你尝试这个。如果您的应用程序或反向代理之一是容器化的或以其他方式划分的，则设置您的应用程序的每个管理员现在都必须在这些划分之一或两个划分中戳一个洞，以让反向代理访问随应用程序分发的静态文件。一旦您的应用程序最终发布，您会收到某人的问题报告，该人的反向代理是“云原生”代理之一，除了反向代理之外什么也不做，并且仅作为 kubernetes 的一部分分发。你沮丧地添加了一个选项，让应用程序提供文件，每个人都在意识到它存在时立即打开它。当您意识到自己造成了相当大的低效率，从而降低了目标受众可以使用的低端硬件的潜力时，您会哭泣。 “专业”规模？静态文件完全单独部署，可能部署到 s3 存储桶或类似的存储桶，并以 Actual Cdn™ 为前端，因此永远不会出现此问题。未经身份验证的缓存您认识到您的应用程序将受到大量未经身份验证的访问，无论是来自人类还是机器人。未经身份验证的访问总是得到相同的响应，因此如果没有任何变化，没有真正的理由重新计算这些响应。您确定对于您的上下文中的“陈旧”页面来说，一个小时是足够的时间。你深情地浏览着黑胶缓存网站，尽管你完全了解，但你实际上并不需要它，因为你只是业余爱好者网络服务器中现有的 rube goldberg 机器的一部分。沮丧的是，您向端点添加了必要的缓存控制和变化标头。你发现了 no-vary-search 并意识到它只适用于 chrome。您知道将更改响应的确切查询参数集，但您所在的位置无能为力。如果您可以依赖黑胶唱片，则可以删除未使用的查询参数，因此那些试图复活有关链接预览的死笑话的恼人的人不会尝试通过在链接后添加 ?qweqweawe 来绕过缓存。你发现你的网络服务器库有一个缓存中间件。您仔细阅读了它支持的功能，并意识到它除了缓存控制的 ttl 之外不支持任何其他功能，如果幸运的话，可能会有所不同。你把它加进去，心里只抱有一丝希望，希望没人会尝试任何有趣的事情。您放置了配置开关和文档，希望已经设置良好缓存的管理员能够调整它以获得最佳效率。他们不会，一旦你的应用程序发布，你就会遇到来自 caddy 用户的问题，因为他们信任 caddy 令人难以置信的平庸缓存插件，如果愿意的话，它会很乐意破坏响应。其他人启用了 nginx 的缓存，但他们的安装仍然陷入困境，因为他们忘记启用 proxy_cache_lock 。其他人已将其网站置于 cloudflare 后面，但也启用了您的缓存选项，因为他们没有在自己的计算机上设置缓存。你对浪费的内存量感到畏缩。您还意识到您的内置缓存中间件正在缓存您的静态文件。提供这些服务相对来说是微不足道的，并且可能已经被操作系统的磁盘缓存设施缓存了，所以你只是在徒劳地膨胀你的内存。因为您的中间件只查看缓存控制，所以如果不阻止浏览器在客户端缓存您的最佳实践不可变静态文件，您就无法做任何事情。你哭了。 “专业”规模？他们控制整个机器，因此他们确实可以设置黑胶唱片或类似的东西，并根据他们想要的确切缓存行为进行调整。好吧，他们可能会将其外包给 CDN，而 CDN 的表现很平庸，但他们可以选择精细地控制缓存。经过身份验证的缓存您知道您的应用程序也可能会获得大量经过身份验证的访问。也许您正在做一些联合的事情，其中​​您有远程实例与您进行身份验证。他们获取的数据仍然不会经常改变，