ELB可以根据URLredirect请求吗?

我试图在Amazon Elastic Load Balancer后面设置我的应用程序服务器。 我想有一个服务器专用于旧版本,而所有其他服务器专用于新版本。 我想在path参数中使用版本ID实现此

例如

当前版本(3.0): http : //example.com/APPNAME/service

旧版本(2.2): http : //example.com/APPNAME/v2.2/service

我想知道:

  1. ELB是否有能力查看HTTP请求?
  2. ELB可以根据URLpath参数redirect请求吗?

    更新2017-04-05

    在去年夏天启动了基于path路由支持的新的应用程序负载平衡器之后(请参阅前面的更新),AWS现在也为AWS应用程序负载平衡器添加了基于主机的路由支持 :

    […]您现在可以创build应用程序负载均衡器规则,根据Host标头中指定的域名路由传入stream量。 对api.example.com的请求可以发送到一个目标组,请求到另一个mobile.example.com ,所有其他(通过默认规则)可以发送到第三个。 您还可以创build组合基于主机的路由和基于path的路由的规则。 这将允许您将请求路由到api.example.com/productionapi.example.com/sandbox以区分目标组。

    更新2016-08-11

    AWS刚刚(2016年8月11日) 为Elastic Load Balancing服务推出了新的应用程序负载平衡器, 旨在提高实时应用程序,微服务,基于容器的体系结构和stream应用程序的灵活性和性能

    这个新的负载均衡器 ,也支持WebSocket协议和HTTP / 2, 在应用层运行,并提供基于内容的路由支持。 这允许应用程序负载均衡器跨越在一个或多个Amazon Elastic Compute Cloud(Amazon EC2)实例上运行的多个服务或容器发送请求,从而有助于降低成本并简化服务发现。 [强调我的]

    正如在介绍性博客文章中所强调的, ELB的这个新的应用程序负载均衡器选项运行在第7层,并且支持许多高级function[其中]原始选项(现在称为经典负载均衡器)仍可用于您将继续提供第4层和第7层function

    更具体地说,ELB现在支持这种情况,因为每个应用程序负载平衡器允许您定义多达10个基于URL的规则,以将请求路由到目标组 (AWS计划允许您访问其他路由方法 )。


    初始答案

    这是不可能的 – Amazon ELB主要(但见下文)提供了传输层负载均衡( OSI第4层) ,其负载均衡决策仅基于TCP连接,但忽略了应用程序负载。 后者将允许应用层负载平衡( OSI第7层) ,其中应用负载确实考虑负载平衡决定。

    Amazon ELB中的默认configuration实际上为HTTP / HTTPS / SSL提供基本的应用程序级别支持(例如终止SSL连接和插入X-Forwarded-*标头),但不能调整此configuration; 换句话说,ELB的确在这里查看了HTTP请求 ,但是在这方面你无法控制ELB的行为。

    在为您的负载均衡器select监听器中对此进行了更详细的说明,例如:

    使用TCP / SSL(第4层)和Elastic Load Balancing

    当您对前端和后端连接使用TCP时,您的负载均衡器会将请求转发到后端实例,而不用修改标头 。 此configuration也不会为会话粘性或X-Forwarded- *标头插入cookie。

    […]

    使用HTTP / HTTPS(第7层)和Elastic Load Balancing

    当您为前端和后端连接使用HTTP(第7层)时,您的负载均衡器将parsing请求中的标头并终止连接,然后再将请求重新发送到已注册的实例 。 这是Elastic Load Balancing提供的默认configuration。

    [强调我的]

    “ build筑概览”也提供了一个插图和更多的细节。

    你发布你的问题已经有好几年了,但是亚马逊最近宣布了应用程序(第7层)负载平衡function。 这应该支持你在找什么。

    基本上,您可以根据“规则”(例如,URLpath模式)定义stream量路由到的不同目标组。 规则可以按需要优先。

    详情请参阅https://aws.amazon.com/elasticloadbalancing/applicationloadbalancer/

    这是我见过的一个可能的解决scheme。 这不像使用本地Nginx Plus进行负载平衡一样理想,但是如果您需要使用ELB,则它可以工作。

    让我们想象一下这样的架构:

      ELB | Server 1 Server 2 Server... (Current) (Current) (Current) \ | / Server X (Legacy) 

    第一层中的每个服务器都运行“当前”实现。 他们还运行Nginx或Apache作为Web服务器(这通常是任何Web应用程序,IMO之前的最佳实践)在应用程序层之前。

    每个Nginx / Apacheconfiguration文件都包含一个检查URL参数的行,指示这是一个传统调用,它将请求代理到服务器X.如果不是传统调用,它只是将请求继续到“当前”应用程序。

    缺点是您在当前服务器中使用几个周期代理旧服务器,但是您的体系结构非常简单,并且您拥有一个集中式stream程。