我正在尝试在 Amazon Elastic Load Balancer 后面设置我的应用程序服务器。我正在考虑让一台服务器专用于旧版本，而所有其他服务器专用于新版本。我正在考虑使用路径参数中的版本 ID 来实现这一点
例如
当前版本 (3.0) : http://example.com/APPNAME/service
旧版本（2.2）：http://example.com/APPNAME/v2.2/service
我想知道：
【问题讨论】：
标签： amazon-web-services load-balancing amazon-elb
在去年夏天推出支持基于路径的路由的新 Application Load Balancer 之后（请参阅前面的更新），AWS 现在还添加了Host-Based Routing Support for AWS Application Load Balancers：
[...] 您现在可以创建路由传入的应用程序负载均衡器规则 基于Host 标头中指定的域名的流量。 对 api.example.com 的请求可以发送到一个目标组，请求 到 mobile.example.com 到另一个和所有其他（默认情况下） 规则）可以发送给第三方。您还可以创建组合规则 基于主机的路由和基于路径的路由。这将允许您 将请求路由到 api.example.com/production 和 api.example.com/sandbox 到不同的目标群体。
AWS 刚刚（2016 年 8 月 11 日）推出了新的 Application Load Balancer for the Elastic Load Balancing service，旨在提高实时应用程序、微服务、基于容器的架构和流应用程序的灵活性和性能 ：
这个新的负载均衡器，它还支持 WebSocket 协议和 HTTP/2，运行在应用层，提供基于内容的 路由支持。这允许 Application Load Balancer 路由 跨运行在一个或多个上的多个服务或容器的请求 Amazon Elastic Compute Cloud (Amazon EC2) 实例，有助于减少 成本并简化服务发现。 [强调我的]
正如introductory blog post 中所强调的，这个用于 ELB 的新 Application Load Balancer 选项 [...] 在第 7 层运行并支持许多高级功能 [whereras] 原始选项（现在称为 Classic Load Balancer）仍然可供您使用，并继续提供第 4 层和第 7 层功能。
更具体地说，ELB 现在支持手头的场景，因为每个 Application Load Balancer 允许您定义多达 10 个基于 URL 的规则来将请求路由到目标组（AWS 计划 提供随着时间的推移，您可以访问其他路由方法。
这是不可能的 - Amazon ELB 主要（但见下文）提供传输层负载平衡（OSI 第 4 层），其负载平衡决策仅基于 TCP 连接，但忽略应用程序有效负载。后者将允许应用层负载平衡（OSI 第 7 层），其中应用负载确实被考虑到负载平衡决策中。
Amazon ELB 中的默认配置实际上为 HTTP/HTTPS/SSL 提供了基本的应用程序级别支持（例如终止 SSL 连接和插入 X-Forwarded-* 标头），但您无法调整此配置；换句话说，ELB 确实在此处查看 HTTP 请求，但在这方面您无法控制 ELB 行为。
这在Choosing Listeners for Your Load Balancer 中有更详细的解释，例如：
将 TCP/SSL（第 4 层）与 Elastic Load Balancing 结合使用
当您同时使用 TCP 进行前端和后端连接时，您的 负载平衡器将将请求转发到后端实例 无需修改标题。这种配置也不会 为会话粘性或 X-Forwarded-* 标头插入 cookie。
[...]
将 HTTP/HTTPS（第 7 层）与 Elastic Load Balancing 结合使用
在前端和后端都使用 HTTP（第 7 层）时 连接，您的负载均衡器解析请求中的标头并 在重新发送请求之前终止连接 注册实例。这是由提供的默认配置 弹性负载平衡。
[强调我的]
Architectural Overview 还提供了插图和更多详细信息。
【讨论】：
您发布问题已经有好几年了，但亚马逊最近宣布了应用程序（第 7 层）负载平衡功能。这应该支持您正在寻找的内容。
基本上，您可以根据“规则”（例如 URL 路径模式）定义流量路由到的不同目标组。可以根据需要对规则进行优先级排序。
详情请见https://aws.amazon.com/elasticloadbalancing/applicationloadbalancer/
【讨论】：
这是我见过的一个可能的解决方案。它不如使用原生 Nginx Plus 进行负载均衡那么理想，但如果您需要使用 ELB，它可以工作。
让我们想象一下这样的架构：
ELB
|
Server 1 Server 2 Server...
(Current) (Current) (Current)
\ | /
Server X
(Legacy)
第一层中的每个服务器都运行“当前”实现。他们还在应用层前运行 Nginx 或 Apache 作为 Web 服务器（这通常是任何 Web 应用程序前的最佳实践，IMO）。
每个 Nginx/Apache 配置文件都包含一个检查 URL 参数的行，表明这是一个将请求代理到服务器 X 的旧调用。如果它不是旧调用，它只会继续对“当前”应用程序的请求.
缺点是您在当前服务器中使用了几个周期来代理旧服务器，但您的架构非常简单并且您拥有集中式流程。
【讨论】：