我过去的 Web 应用程序经验仅限于一些 Apache+PHP 实验。从这个背景开始，我一直在阅读有关使用 Python 实现 REST 服务的文章，这是我目前对该堆栈的理解。
这张图片“正确”吗？
- TLS 会在我展示的地方发生吗？
- URL 重写和重定向发生在哪里？
- 我是否应该/可以让静态内容在负载平衡层（可能在单独的服务器上）处理，或者应该在 Web 服务器层处理？
我之前发过太宽泛的问题关于这一点。根据我了解到的情况，我会问更具体的问题。
关于图片的一些注释：
- 我知道当没有负载平衡层时，TLS 会发生在 Web 服务器层，但当使用负载平衡层时，在负载平衡器层执行 TLS 似乎更自然 - 这有错吗？
- URL 重定向和重写似乎遍布各处，并在静态内容的提供位置中发挥作用。特别是如果你想将一些静态内容重定向到 CDN，在这种情况下，这可能在整个堆栈之外！
答案1
对于超级用户来说，这不是一个理想的问题。服务器故障可能是这个问题的更好目标。话虽如此...
您的问题没有具体的答案 - 有许多不同的选项可以解决每个问题。我主要会回答我推荐的答案。
- TLS 会在我展示的地方发生吗？
是的，我会使用专用设备（例如负载平衡器）来卸载 TLS。通常，这里有专门设计的专用硬件，用于加速 TLS，而无需使用较慢的通用 CPU 周期。将 TLS 证书集中在这样的设备上也有助于证书管理 - 或者在出现 Heartbleed 或 POODLE 等安全问题时，提供一个需要进行任何必要安全更改的单点 - 而不是多个 Web 服务器。
- 理想情况下，您将拥有 2 个或更多负载均衡器，并在高可用性配置中配置主动/主动或主动/被动，以实现故障转移和冗余。
- 在 Heartbleed 漏洞案例中，市场上至少一些重要的负载均衡器并不受影响 - 因为使用本机 SSL/TLS 堆栈而不是 OpenSSL。
如果安全对您来说至关重要，您可以考虑在新的 TLS 连接中通过隧道传输负载均衡器和 Web 服务器之间的流量。或者，不要终止 TLS，只将 TCP 连接转发到一个或多个 Web 服务器。但是，无论哪种方式，我上面提到的所有优点都会被抵消。此外，我希望您的负载均衡器和 Web 服务器（及其通信）都包含在安全的数据中心内，不需要加密通信。（如果这些设备不安全，那么一切都将不复存在。）
也可以看看：https://security.stackexchange.com/questions/30403/should-ssl-be-terminated-at-a-load-balancer
- URL 重写和重定向发生在哪里？
正如您提到的，CDN 是另一种可能性 - 否则我将在这里忽略它。
您可以在负载均衡器中或在 Web 服务器上执行此操作。我倾向于默认在 Web 服务器中执行大部分操作 - 尤其是在使用 Apache HTTPD 时 - 因为您无法超越它提供的功能和灵活性mod_rewrite。能够将这些规则保存在可以在 SVN 等中进行源代码控制的与设备无关的文本文件中，也是一个额外的好处 - 特别是因为规则往往需要频繁更改（考虑到它们的性质）。
我会始终将任何重写和重定向保留在 Web 服务器中托管的站点/域内部。在托管站点内的 URL 需要重定向到其他地方（且性能是关键问题）的有限情况下，我会考虑在负载平衡器上执行此工作。
- 我是否应该/可以让静态内容在负载平衡层（可能在单独的服务器上）处理，或者应该在 Web 服务器层处理？
除极少数例外，内容由 Web 服务器而不是负载均衡器提供。您可以/应该做的是配置您的 Web 服务器以直接提供此类静态内容 - 而不是将其发送到 PHP / Python / Tomcat / 等，因为这样可能会降低服务速度。如果可能，请使用和配置 CDN 以将所有这些内容卸载到边缘网络，甚至不会到达您的负载均衡器。
这里可能有点棘手的一个方面是身份验证、授权和日志记录。在卸载此类“静态”内容的任何时候，您的下层可能永远不会知道正在提供此类内容 - 无法保护它，甚至无法跟踪其访问。这里的一种可能性（如果这是一个问题）是使用“集中式身份验证”模型 - 其中上层可能缓存了内容，但仍会使用“If-Modified-Since”标头将请求发送回下层/源。然后，源能够检查会话 ID/cookie/等 - 并有机会使用“HTTP 403 Forbidden”或“HTTP 304 Not Modified”（从缓存返回）之类的内容进行响应。