反向代理 haproxy_将HAProxy用作AWS微服务的反向代理

反向代理 haproxy

亚马逊的EC2微型实例为托管基于Docker的微型服务架构提供了一个非常实惠的选择。 每个微型实例可以托管多个Docker容器。 例如，您可能有一个简单的基于Node.js的Web应用程序，您希望将其显示为subdomain1.myhost.com，而另一个Java / Tomcat Webapp则应显示在subdomain2.myhost.com中。 每个容器都可以通过单独的（也许是集群的）Docker容器托管，并带有用于公开API服务的其他容器。 该体系结构可能类似于：

请注意，在此实例中将HAProxy用作负载平衡器和反向代理。 它被放置在其自己的micro-EC2实例中，并将入站流量定向到基于子域路由规则的目标（HAProxy支持各种各样的常规规则，与Apache mod_proxy不同）。 子域1和子域2的DNS条目都将流量定向到相同的公共IP地址，在这种情况下，HAProxy会拦截该公共IP地址。 然后，配置路由规则会将入站请求转发到托管该网站的相应Docker容器。

配置HAProxy非常简单，这可以解释它在开源社区中的流行程度（在http://www.haproxy.org/上了解有关HAProxy的更多信息）。 让我们看一个支持以上架构的示例HAProxy配置文件（haproxy.cfg通常位于/ etc / haproxy中）。 我们将从两个全局部分和默认部分开始，在大多数情况下，您可能都可以按原样保留它们：

global
        maxconn 4096
        user haproxy
        group haproxy
        daemon
        log 127.0.0.1 local0 debug

defaults
        log     global
        mode    http
        option  httplog
        option  dontlognull
        retries 3
        option redispatch
        option http-server-close
        option forwardfor
        maxconn 2000
        timeout connect 5s
        timeout client  15min
        timeout server  15min

接下来，我们将转到“前端”部分，该部分用于描述一组接受客户端连接的侦听套接字，并用于配置IP /端口转发的规则，该规则会将流量重定向到适当的主机进行处理。

frontend public
        bind *:80

        # Define hosts
        acl host_subdomain1 hdr(host) -i subdomain1.myhost.com
        acl host_subdomain2 hdr(host) -i subdomain2.myhost.com

        ## figure out which one to use
        use_backend subdomain1 if host_subdomain1
        use_backend subdomain2 if host_subdomain2

“ bind”伪指令用于指示HAProxy将监听哪个端口（在本例中为端口80）。 “ acl”指令定义了如何路由入站流量的标准。 指令后的第一个参数只是内部名称，以供将来参考，其余参数定义用于匹配入站请求中某些元素的方法，该入站请求中的某些元素被用作路由的基础（HAProxy文档提供了更多详细信息）。 在这种情况下，第一个“ acl”指令只是说明如果入站请求的主机名是“ subdomain1.myhost.com”，则将匹配项分配给名为“ host_subdomain1”的acl标识符。 基本上，我们只是在定义匹配入站请求的条件。

本节的下一部分是“ use_backend”指令，该指令将匹配的“ acl”规则分配给特定主机进行处理。 因此，在第一个示例中，就是说，如果将入站请求的“ acl”匹配名称分配给“ host_subdomain1”，则使用“ subdomain1”标识的后端。 这些“后端”在以下部分中定义：

backend subdomain1
        option httpclose
        option forwardfor
        cookie JSESSIONID prefix
        server subdomain-1 someawshost.amazonaws.com:8080 check

backend subdomain2
        option httpclose
        option forwardfor
        cookie JSESSIONID prefix
        server subdomain-2 localhost:8080 check

在第一个“后端”指令中，我们定义了用于处理的服务器后端，该服务器后端通过分配的名称“ subdomain1”（这些名称是任意名称–请确保与前端​​指令中的名称匹配）来标识。 然后，使用“服务器”指令（使用任意名称分配作为第一个参数）来标识哪个主机/端口转发请求，在这种情况下，该主机/端口是主机someawshost.amazonaws.com:8080（check参数为实际上仅在使用负载平衡时才有意义）。 如果使用负载平衡/集群，则可以定义多个服务器指令。

HAProxy有许多配置选项可用，但是这个简单的示例说明了如何轻松地将其用作反向代理，将入站流量重定向到其最终目的地。

API和微服务

设计使用微服务运行的API解决方案的挑战之一是如何“分担”各种服务调用，以便它们可以托管在单独的Docker容器中。 当您想向开发社区传达统一的API时，使用前面介绍的针对标准Web应用程序的基于子域的方法（即subdomain.myhost.com）并不实际。 但是，仍然可以使用基于URL路径的反向代理规则以几乎相同的方式完成此操作。 例如，考虑以下两个虚拟API调用：

GET api.mycompany.com/contracts/{contractId}
GET api.mycompany.com/customers/{customerId}

在第一个示例中，这是一个RESTful GET调用，该调用基于指定的contractId检索给定的合同JSON对象。 示例2中使用了类似的模式来获取客户记录。 如您所见，第一个路径元素实际上是与Web服务调用关联的“域”。 这可以用作将这些域调用分离到各自独立的微服务Docker容器中的基础。 这样做的一个好处是，这些域中的一个通常可能比另一个域承受更多的流量。 通过将它们分成单独的服务，可以执行目标扩展。

如果您喜欢这篇文章，请相应地链接到它。

翻译自: https://www.javacodegeeks.com/2015/07/using-haproxy-as-a-reverse-proxy-for-aws-microservices.html

反向代理 haproxy