背景介绍

HAProxy是一个高可靠、高性能的反向代理。和他类似功能的软件还有LVS，Nginx，他们的功能各有侧重，网上有大量介绍对比资料。本次收到的任务，主要目的是验证HAProxy在鲲鹏环境下的部署，并通过HAProxy实现微服务网关和GaussDB的负载均衡。

收到任务先看任务书，任务书要求在开源演示项目Demo的基础上，引入Haproxy实现两个反向代理。一是代理微服务网关的web访问，二是代理GuassDB的数据库访问。

磨刀不误砍柴工，先上网搜下Haproxy，了解下负载均衡和HAProxy的基本信息。熟悉这块的小伙伴就可以跳过了。

什么是负载均衡

负载均衡，英文名称为Load Balance，简写LB，是指建立在现有网络结构之上，并提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。其原理就是数据流量分摊到多个服务器上执行，减轻每台服务器的压力，多台服务器共同完成工作任务，从而提高了数据的吞吐量。

常见的负载均衡功能实现有软件方案和硬件方案。软件通常使用开源的LVS，Haproxy，Nginx，硬件一般使用较多的有F5，Array等设备。

HAProxy主要功能：

负载均衡：可以根据多种算法（如轮询、最少连接数、源 IP 哈希等）将客户端请求分配到不同的后端服务器，均衡负载以提高整体性能。

高可用性：能够监控后端服务器的健康状态，并在检测到某台服务器故障时，自动将流量转移到健康的服务器上，确保服务的连续性。

反向代理：作为反向代理，将客户端的请求转发到后端服务器，同时隐藏后端服务器的实际 IP 地址。

访问控制和安全性：通过 ACL（访问控制列表），可以对请求进行精细的控制，如基于源 IP、HTTP 头信息、URL 路径等进行过滤或重定向。

性能优化：软件非常轻量级，能够处理数十万甚至上百万的并发连接，且对系统资源的消耗非常低。

日志记录和监控：提供详细的日志记录功能，能够记录请求的详细信息，并通过集成监控工具来实时查看服务器的健康状态和流量情况。

部署Demo项目

基于任务书，先了解开源演示项目Demo。这是一个体验项目，基于Apache ServiceComb Fence  , 并针对For Huawei场景进行了少量优化。它可以帮助开发者快速构建包含微服务后端、微服务前端和基础原子服务的项目工程。项目有详细的介绍和部署指导，这里就不赘述了。其部署示意图如下：

先fork这个Demo项目的工程 ，在自己的gitcode账号下复制了这个项目的代码。华为云给开发者提供了整套的开发指导，其中就包括这个Demo项目的支撑文档，里面详细介绍了项目情况，还有具体部署的过程指导。

按项目指导，在华为云购买CodeArts（软件开发生产线）服务，创建开发项目，引入gitcode上fork的工程，创建编译构建任务，编译出edge-service，admin-service，admin-website，authentication-service，resource-service 这5个程序，并直接打包成容器镜像，推送到SWR容器镜像仓库中。

在华为云购买CCE集群，将上面打包的5个镜像都作为无状态负载，部署到集群中。并为edge-service增加负载均衡服务，确保其可以通过ELB被公网访问。同时部署zookeeper和GuassDB，支撑整个服务的运行。

部署后整体架构如下:

用户直接访问应用网关上绑定的ELB公网地址124.243.151.208，在浏览器中输入http: //124.243.151.208:9090/ui/admin/ 就可以进入到demo的显示页面。至此，Demo部署就完成了。

通过Haproxy代理微服务网关

部署完成，我们可以考虑这种场景，如系统性能不足，需要扩容再增加一套集群；或者系统需要为多租户服务，每个租户要用不同集群；又或者想要更高的可靠性，在不同region部署多个集群。这时多个集群就有多个入口IP，这就给用户访问带来不便，此时，就需要引入我们这个任务的主角HAProxy，作为web反向代理，给用户提供统一入口，并通过配置各种负载均衡策略，将用户流量引入到正确的集群中处理。这就是本次验证的第一个任务，用HAProxy代理微服务网关的web访问。我设想的架构就变成下面这个样子。

通过在ECS中安装HAProxy，作为两个CCE集群的反向web代理，绑定公网EIP124.243.172.157，用户访问此IP后，HAProxy按照配置的负载均衡策略，将流量分发到对应的CCE集群中。

正式操作开始。先购买ECS，规格选择鲲鹏服务器，部署华为Euler操作系统。然后登陆ECS安装HAProxy。

安装HAProxy依赖包

yum  install -y gcc openssl-devel pcre-devel systemd-devel

源码安装Haproxy，直接到官网下载最新3.0.6版本。

cd /opt
wget https//www.haproxy.org/download/3.0/src/haproxy-3.0.6.tar.gz
tar zxf haproxy-3.0.6.tar.gz
cd /opt/haproxy-3.0.6

进行编译构建。

make clean
make -j 4 TARGET=linux-glibc USE_THREAD=1  USE_LIBCRYPT=1  USE_PCRE2=1 USE_PCRE2_JIT=1 
make install PREFIX=/usr/local/haproxy

将编译好的程序拷贝到运行目录中

cp /usr/local/haproxy/sbin/haproxy /usr/sbin

编辑Haproxy启动脚本

cp /opt/haproxy-3.0.6/examples/haproxy.init /etc/init.d/haproxy
chmod 755 /etc/init.d/haproxy

针对配置文件的路径创建以下用户和文件目录

useradd -r haproxy
mkdir /etc/haproxy
mkdir /var/lib/haproxy
mkdir /var/run/haproxy

编辑haproxy配置文件

vim /etc/haproxy/haproxy.cfg

配置文件内容如下：:

global
    log 127.0.0.1 local3 info
    chroot /var/lib/haproxy
    user haproxy
    group haproxy
    daemon

defaults
    log global
    mode http
    option dontlognull
    timeout connect 5000
    timeout client 50000
    timeout server 50000

frontend haproxy_for_deom
    option httplog
    mode http
    bind *:80
    stats uri /haproxy?stats
    default_backend opensourcedemo

backend opensourcedemo
    option httpchk GET /ui/admin/ HTTP/1.1
    http-check send hdr Host 1.2.3.4
    balance roundrobin
    server demo1 192.168.0.11:9090 check inter 2000 rise 3 fall 3 weight 5
    server demo2 192.168.0.187:9090 check inter 2000 rise 3 fall 3 weight 5

启动HAProxy

/etc/init.d/haproxy start

访问haproxy的统计信息页面，说明HAProxy已经正确运行。

直接访问haproxy的地址，haproxy会将流量分担到不同的集群中。配置中将Demo的首页访问地址作为检测集群是否可用的接口，并采用轮选的负荷均衡策略，实际项目中，会规划不同集群的访问路径，Haproxy根据访问的URL地址进行合理的流量分发。Haproxy丰富强大的7层负载均衡配置策略，可以支撑多种多样的业务诉求。

至此，第一阶段的验证就结束了。

通过Haproxy代理GuassDB

现在考虑第二个场景，如果业务压力过大，会导致数据库性能跟不上，这时，除了提升数据库本身能力（换更高配置规格，分布式数据库加更多节点等）之外，还可以通过增加多个数据库的方式来扩充数据库的性能。但微服务访问数据库的流量如何被正确分配到多个数据库中，此时就需要HAProxy登场，做数据库的反向代理。这就是本次验证的第二个任务，通过Haproxy代理GuassDB。目前业务通过TCP连接GuassDB数据库，HAProxy通过TCP代理来实现在多个数据库之间的负载均衡。

设想的部署架构改造是下图这样：

为实现如上效果，需要修改HAProxy的配置文件。

vim /etc/haproxy/haproxy.cfg

在文件中增加如下配置：

listen sebfortcp
    option tcplog
    bind *:8000
    mode tcp
    balance roundrobin
    server guassdb 192.168.0.63:8000 check inter 2000 rise 3 fall 3 weight 5
    server guassdb 192.168.0.149:8000 check inter 2000 rise 3 fall 3 weight 5

完成配置后重启HAProxy服务。

/etc/init.d/haproxy restart

还需要修改演示项目中访问的数据库地址，将数据库的ip地址修改为Haproxy的地址。

访问业务网址，显示正常。关闭一个数据库后，仍能正常访问。至此，验证任务的第二个结束。

当然，上面的验证只解决了微服务访问数据库的路径问题，实际项目中还需要考虑数据库读写分离，数据库之间的数据同步等问题。

本验证中，通过TCP联通检测来检查数据库是否可用，当GuassDB采用集中式部署时存在主备节点，默认配置下主备都有IP地址，并且都可以建立TCP连接，备节点可支持读操作，但进行写操作会失败。如果数据库作为读库，只需要把主备节点IP都配置到Haproxy上进行负荷分担即可。如果数据库是写库，这样配置会导致分流到备节点的写操作执行失败，而如果Haproxy上只配置主节点IP，当数据库主备切换时主IP地址发生变化，会导致Haproxy的检测出现问题，此时比较简单的策略就是设置数据库使用浮动IP，这样数据库在主备切换时IP地址不会发生变化。GuassDB的浮动IP的配置需要在购买数据库时，选择“单浮动IP策略”，注意这个选项只有创建数据库时才可以设置。如果GuassDB采用分布式部署，就只要把每个节点都配置到Haproxy上进行负荷均衡即可。

如果认为数据库的TCP连通性检测不能代表数据库是否正常运行，此时可以通过在Haproxy上增加external-check选项，直接调用脚本连接数据库，检查数据库的可用性，具体实现要根据实际项目需求来确定，这里不再赘述。

Haproxy的高可用部署

系统部署好后，从部署架构上可以明显看出承载HAProxy的ECS存在单点故障的风险，达不到高可用的要求。此时就需要考虑对HAProxy进行集群部署。最常见的方案，可以采用购买ELB服务实现，设想方案如下：

从图中可以看出，由Haproxy的ECS集群组成的负载均衡设备，前面又加了一层负载均衡设备，感觉很搞笑，但实际项目中，这种使用情况还是比较普遍的。一般功能分层上会让第一层做L4负载均衡（简单转发，支持海量并发访问），第二层Haproxy做L7负载均衡（实现丰富的负载均衡功能，通过多实例支持海量并发）。虽然目前华为云的ELB负载均衡服务能力涵盖了L4和L7层能力，但客户可能会在L7负载均衡上有特殊要求，要通过定制Haproxy来实现，或者客户上云前就已经有了Haproxy的负载均衡，搬到云上不愿改动。

实际华为云ELB的配置如下：

对于代理GuassDB的Haproxy的高可用，虽然可以采用类似上面的方案，但此时两者都是L4负载均衡，放置两套负载均衡就完全没必要的。要么购买华为云的内网ELB服务，要么为Haproxy增加高可用。前一个方案和Haproxy无关，只关注后一个方案怎么实现。目前比较常见的实现方式，就是通过haproxy+keepalived实现高可用集群。

Keepalived软件可以通过vrrp协议，将两台机器组成主备模式，并对外呈现一个浮动ip供外部访问。主设备绑定浮动IP，主设备故障，备设备自动升主，绑定浮动IP，开始处理业务。

设想的架构如下：

Keepalived的配置过程可参考网上案例。这在本验证中不是重点，不再描述。

如果觉得备ECS不干活浪费资源，可以创建两个虚拟路由，同时存在两个浮动IP，让两台ECS设备互为主备。并且基于这种扩展方式，还可以创建更多台ECS来分担流量，只要多配置浮动IP即可。当然有了多个浮动IP之后，又会遇到如何在多个浮动IP之前加负载均衡的问题，这就要根据具体情况分析了。很多时候，当用开源软件设计的方案覆盖很多可能场景后，会发现已经和公有云已有的负载均衡服务类似了，所以根据业务诉求找到性能、成本、可靠性等都适合的技术方案，才是做技术研究的乐趣所在吧。

总结

最后，整个演示项目是部署在一个VPC内部的，虽然演示起来方便，但实际项目中为了安全，不同安全层级的网络实体应该通过VPC隔离开，VPC之间通过对等连接或云连接互通，并通过配置ACL等手段只放通需要连接的IP，安全要求更高的项目还会在网络分区间放置防火墙等安全设备。整个项目设想的整体方案图如下：

整个验证项目做下来花了一周，期间不仅感觉到华为云上各种云服务的丰富功能，也体会到鲲鹏服务器，华为欧拉操作系统，以及GuassDB的使用便捷性，和以前用过的同类软件差不多，学习成本不高，喜欢技术研究的小伙伴都可以来试试。