谈一谈使用 HAProxy 构建 API 网关服务的思路

Posted 代码写诗

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了谈一谈使用 HAProxy 构建 API 网关服务的思路相关的知识,希望对你有一定的参考价值。

HAProxy 作为一个优秀的反向代理 ( Reverse Proxy ) 和负载均衡器 ( Load balancer ) ,有着广泛的应用场景,本文将主要介绍使用 HAProxy 构建 API 网关和 Service Router 的思路以及相关 HAProxy 特性,希望对读者有所启发~

在开始之前,我们先回顾并想一想,为什么我们需要 API 网关和 Service Router 呢,它的背景是什么?

背景

我们知道,当项目变大,开发人员变多,项目复杂度增加,任何一个人都很难清楚每一个细节,沟通协作成为开发效率的瓶颈,任何一个改动都可能牵一发而动全身,项目风险变大,迭代缓慢,导致开发速度跟不上企业发展需要。

为了解决这个问题,聪明的人们提出 SOA 的思想,把一个大的项目拆分成一个个独立的服务,服务与服务之间通过统一的方式进行通信,实现了服务的解藕,各个服务可以独立开发部署,近两年流行微服务则更进一步,拆的更细更激进。当然,需要明确的是,SOA 还解决了其他问题,但这不是本文的重点。

服务拆分解决了协作与开发效率的瓶颈,但也带来了新的问题,那就是服务管理的复杂度,具体涉及服务发现和服务网关(或者说 API 网关),API 网关正是本文的主题,进一步的服务发现也需要 API 网关支撑才行。

有了这样的背景,我们来看如何利用 HAProxy 构建 API 网关吧~

HAProxy 基本配置

工欲善其事,必先利其器,首先让我们先了解一下 HAProxy 的基本配置~

配置文件结构

HAProxy 的配置文件一般名为 haproxy.cfg,默认位于 /etc/haproxy 目录下,HAProxy 的配置文件有多个 Section 组成,总共有4种类型的 Section,它们分别是:

  • global - 进程级别的参数,比如设定日志路径和用户组

  • defaults - HAProxy 作为代理默认的一些参数,比如连接超时时间

  • frontend - 定义如何接收和转发请求

  • backend - 定义后端处理请求的服务器列表

ACL(Access Control Lists)

作为一个反向代理,我们需要根据请求内容,比如 Host 或者 Http Header 动态的选择请求转发的后端服务器,而 ACL 则是实现该需求的手段。

ACL 一般使用形式如下:

acl is_rethinkphp hdr(Host) -i rethinkphp.com

这里的 is_rethinkphp 是 acl 的名称,hdr(Host) 表示从 Header 中提取 Host 用于比较,-i 表示忽略大小写,整条 acl 的含义是判断一个请求的 Host 是否是 rethinkphp.com。

这条 ACL 规则可以写成这样:

acl is_rethinkphp hdr(Host),lower rethinkphp.com

其中 lower 是一个 converter,可以理解为一个函数,把 Host 转成小写再用于比较。

监听网络请求

有了上面的基础,我们就可以定义一个 frontend 来监听网络请求了:

frontend http_in
    bind *:80
    mode http # 代理服务器模式
    timeout http-keep-alive 1000
    acl is_rethinkphp hdr(Host) -i rethinkphp.com
    use_backend bk_rethinkphp if is_rethinkphp

这里我们监听了所有 80 端口的网络请求,并设置代理服务器模式为 http,然后判断如果请求的 Host 是 rethinkphp.com,就使用 bk_rethinkphp 这个 backend,表示匹配的请求都会转发到 bk_rethinkphp 所定义的后端服务器。

定义后端服务

网络监听和转发规则都设定好了,我们直接看后端 backend 的定义吧:

backend bk_rethinkphp
    mode http
    option forwardfor
    http-request set-header X-Forwarded-Port %[dst_port]
    http-request add-header X-Forwarded-Proto https if { ssl_fc }
    option httpchk GET /
    server server01  172.16.1.101:7789 check
    server server02  172.16.1.102:7789 check 

这里我们是 backend 关键字定义了名为 bk_rethinkphp 的后端服务器组,里面包含了 server01 和 server02 两台服务器,并通过 check 参数开启了健康检查,到这里一个 HAProxy 基本配置基本完成了,server01 和 server02 会接收来自 rethinkphp.com 的 http 请求。

路由功能实现

在上文中,我们实现了简单的按照域名进行请求转发的功能,但在真实的场景中,一个 API 网关可能需要处理成百上千的服务,也需要根据 URL 进行更灵活的转发配置,如果都一条条的编写 ACL 规则,难免过于繁杂,不好维护。这个时候我们可以使用 HAProxy 提供的 map 及强大的正则功能改造 frontend,从而实现基于 URL 的路由转发。核心配置如下:

frontend http-in
    bind *:80
    mode http
    timeout http-keep-alive 1000
    acl is_found base,map_reg(routes.map) -m found
    use_backend %[base,map_reg(routes.map)] if is_found

其中 routes.map 是一个包含两列的 key value 格式文件,内容如下:

docs.rethinkphp.com/.*   bk_docs
www.rethinkphp.com/.*    bk_main

这样我们就可以直接在 routes.map 通过正则表达式建立 URL 与具体后端服务器的对应关系,维护变得简单许多。

在这个例子中,base 是包含 host 和 path 的一个字符串,然后我们使用 map_reg 这个 converter,它的作用就是读取指定 key value 格式文件,并使用正在表达式对 key 进行匹配,如果匹配成功,则返回对应的 value,然后再进行下一步的比较。

Socket Commands

HAProxy 有一个非常独特的功能,那就是它的 Socket Commands,我们可以在 global section 中开启该功能: 

 stats socket /run/haproxy.sock mode 660 level admin

有了该功能,我们可以通过 Socket 的方式动态控制 HAProxy 的行为,包括如下几个方面:

  • 查询服务器运行状态以及各种统计信息

  • 开启与禁用 frontend

  • 修改 map 和 acl 信息,可实现动态修改路由

有了这些功能,我们可以在不 reload HAProxy 服务器的情况下,修改部分配置。

遗憾的是,目前 HAProxy 还不支持 backend 和 server 的动态添加,涉及相关的修改只能修改配置文件并 reload 服务器。

服务化

利用好上文介绍的功能,我们就已经能够配置好一台 HAProxy 作为 API 网关,但配置都需要手动操作,容易出错不说也不方便业务方使用。

所有,更好的方式是把 API 网关作为一个独立的服务,该服务通过对外提供 API 接口来进行管理控制,更进一步,我们还能够与 CI/CD 集成,做到无缝的持续交付,提高协作效率,降低人为操作风险。

HAproxy Router 是我正在尝试开发的一个 HAProxy 服务化管理工具,目前(2017年5月30日)还处于起步阶段,感兴趣的读者可以点击「阅读原文」关注,我会在后续的文章中分享进展,也欢迎提出你的想法和建议~



以上是关于谈一谈使用 HAProxy 构建 API 网关服务的思路的主要内容,如果未能解决你的问题,请参考以下文章

谈一谈正向代理和反向代理

谈一谈正向代理和反向代理

谈一谈分布式会话

谈一谈Http Request 与 Http Response

谈一谈EasyUI的TreeGrid的过滤功能

从源码的角度来谈一谈HashMap的内部实现原理