☰

架构问题：添加 SSL

tag-icon • tag-icon apache-2.2 ssl haproxy varnish stunnel
架构问题：添加 SSL

目前我们有一个最高级别的配置，如下所示：

[流量] -> Varnish（缓存） -> HaProxy（负载均衡） -> Apache（内容和服务）

有（显然？）多个 Apache 服务器，并且它们通常提供两种类型的服务...一组服务器提供更传统类型的 Web 内容（大部分是可导航的页面），另一组是服务端点（它们又连接到数据库和其他后端功能）。

服务请求在 Varnish 中很早就被过滤掉（特定域等在 VCL 中被识别并直接传递给 HAProxy——无需缓存任何这些调用）。

“内容”请求确实被 Varnish 缓存。

需要添加 SSL 支持。最初是因为需要添加安全服务请求（和响应），但我预计最终我也需要对内容服务器进行 HTTPS 调用。

目前，我正在尝试使用 stunnel，虽然它可以工作，但我使用的模型实际上只是使用 stunnel 解密传入的请求，然后将它们作为正常的 *:80 流量通过 HAProxy 传递（因此在 Apache 中不使用 mod_ssl 等）。因此，现在的情况实际上如下：

[流量] -> Varnish（缓存） -> HaProxy（负载均衡） -> Apache（内容和服务） -----------> STunnel -----------------------------^

所以它是有效的，但我的直觉告诉我这不是一个长期的解决方案。一种可能性是完全分离流量)：

[流量] -> Varnish（缓存） -> HaProxy（负载平衡） -> Apache（内容和服务）
[流量] -> Pound（或其他？） -------------------------> Apache（SSL 内容和服务）

Apache 服务器可能会共享（SSL 流量只是以不同的方式处理）但将流量路由到内容/服务服务器的系统会有所不同...

四处寻找后，我得到了许多意见/选项（包括 nginx 等），但首要问题是整个架构是否合理（将传入流量转移到单独的子系统），或者是否有一个更统一的模型值得我研究（可能更简单）。如果架构合理，那么接下来的问题就是要使用什么来支持这个小东西的 SSL 方面。

答案1

整个架构是否合理（转移传入流量

你提供的图表没有显示任何分支。我有点困惑，为什么你要将 varnish 放在 HA-Proxy 前面，而不是反过来。

但我的直觉告诉我这不是一个长期的解决方案

SSL 封装应该位于 HTTP 缓存之前（否则内容无法被缓存）。

当然，减少跳数会更好，但将 SSL 合并到现有层之一不会带来太多性能优势（至少假设 stunnel 的至少一端通过 localhost 连接）。这是 Oracle、Cisco、f5 等公司倾向于推荐的架构（即在前端使用 SSL，尽管他们认为您应该在某个地方运行他们的工具包！）。

如果是我的话，我会将可缓存/不可缓存的内容拆分到面向客户的不同 URL 上。（最好对所有可缓存内容使用 CDN！）

您尚未回答的重要问题包括您有多少个 IP 地址、有多少个网络服务器以及可缓存/不可缓存和 http/https 之间的划分。

            +--->(cacheable:80)->--------------+
            |                                  |
            +--->(cacheable:443)---> stunnel->-+->Varnish ->-+
 HAProxy ->-+                                                |
            +-->(non-cacheable:443)--> stunnel->-----+-------+---->Apache
            |                                         |
            +--->(non-cacheable:80)->-----------------+

显然，如果你放弃 varnish，（可以选择在 Apache 中使用 mod_proxy）这会变得简单得多……

            +--->(:80)->------------+
 HAProxy ->-+                       |
            +--->(:443)---> stunnel-+---->Apache

考虑到硬件的价格，我并不认为使用缓存反向代理是性价比的良好折衷 - 除非您有大量流量，并且大部分流量是可缓存的。另一方面，如果您正在实现逻辑（例如 ESI），那么这样做不太实际不是有代理，在这种情况下问题就变成了Varnish 提供所需的负载平衡而不是使用 HAPProxy？

  (:443)-->stunnel--+
                    |
  (:80)-------------+-->varnish-->Apache

答案2

哇，这个堆栈越来越深越来越复杂。复杂性是正常运行时间的敌人，而且通常也是性能的敌人。每个部分都必须管理连接、解析 HTTP 标头等。

我建议你简化事情。使用nginx用于 SSL、负载平衡、缓存，因为它通过内置模块支持所有这三个。您也可以逐步将其部署到您的基础设施中，首先只在前端执行 SSL，然后替换 HAproxy 以平衡服务的负载等。如果您的服务是使用具有不错的 Web 或 FastCGI 服务器的语言编写的，您甚至可以放弃 Apache 并让 nginx 完成几乎所有工作。

我的小型 SaaS 商店在 Tomcat、IIS 和 PHP-fastCGI 后端服务和静态 Web 服务器前使用扁平的 nginx SSL/代理/缓存/静态层。我们每秒的请求峰值为 2000，而 nginx 在这种负载下甚至没有费什么力气，因为前端只有两个单核 VMware 虚拟机。

答案3

您可以尝试“mode tcp”（默认）和“option ssl-hello-chk”。查看HAProxy 配置手册。这样你就无法通过 HAProxy 检查 http 标头，但也许你不需要这样做。

这样，您便将所有资源提供给 HAProxy 以进行负载平衡和 SSL 解密、缓存，并且动态或静态内容的提供都在后端完成，您可以轻松地进行扩展。

HAProxy 可以处理 HTTP/1.1，能够保持许多持久连接，因此您的应用程序中可以使用长轮询或 websockets 等技术。例如，目前 nginx 无法做到这一点。

相关内容