随着云计算和云原生技术的发展，各大云计算厂商都在布局云计算数据中心，为用户提供更加安全高效的计算、存储、网络资源以及应用服务资源。一些大型企业尤其是金融业需要建立自己的私有数据中心，保证数据的安全可控。目前各数据中心都在由传统数据中心向云计算数据中心转型，以满足新兴技术的发展和业务快速迭代的需求。G行作为金融行业数字化转型的探索者与实践者，提出“123+N”的数字化特色发展体系，即一个智慧大脑，两大技术平台——云计算和大数据，三项服务能力——移动化、开放化、生态化服务能力。根据数字化发展战略要求，传统数据中心的应用系统要逐步迁移到云平台，实现服务云化，满足业务快速迭代的需要，同时云平台可提供快速便捷的资源交付和资源扩容能力，提升资源利用率，达到降本增效的目标。
针对应用上云，G行制定了相关的上云策略，强调优先容器化部署，对于无法容器化改造的产品组件可通过虚拟机或裸金属方式上云，以多种部署形式满足应用上云要求。针对传统环境和云上应用，所使用业务流量负载方式是不同的。传统环境主要使用硬件F5负载均衡，优点是性能好、功能强大，缺点是成本高、扩展性差、不符合信创要求。云环境使用云平台提供的服务组件弹性负载均衡服务，优点是成本低、扩展性好、符合信创要求，缺点是相比硬件负载均衡性能略有下降。本文主要对云上负载均衡的实践进行总结介绍。
一、负载均衡定义
负载均衡技术是通过硬件或者软件定义的方法，来扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。其主要作用如下。
1、高并发性
负载均衡通过负载算法将应用请求尽力均匀的分配到后端负载各节点，以此提高应用集群的并发处理能力。
2、高可用性
负载均衡可以通过健康检查机制监控后端负载节点，当负载节点不可用时，自动隔离故障节点，并将请求分发给可用的负载节点，使得应用集群具备高可用的特性。
3、弹性伸缩性
通过动态添加或减少负载节点数量，然后由负载均衡进行分发控制，使得应用集群具备弹性及伸缩性。
二、负载均衡算法
负载均衡的功能是流量分发，即将接受的流量请求按照一定的算法规则转发给后端的负载节点，实现高并发的同时，能够最大限度地利用后端负载服务器的资源。常用的主要有以下几种算法。
负载均衡算法 | 描述 | 使用场景 |
rr轮询算法 | rr 算法就是将外部请求按顺序轮流分配到集群中的负载节点上，但不考虑每台负载节点的负载情况。 | 该算法适合后端负载节点配置一致，算力均等的场景。 |
wrr加权 轮询算法 | wrr 算法在rr 算法的基础上会考察每台负载节点的负载情况，并尝试让负载较轻的节点承担更多请求。 | 该算法适合后端负载节点算力配置不均等的场景。 |
lc最少连接数算法 | lc算法可以让负载均衡设备尝试把新的请求交给当前连接数最少的负载节点 ，直到此负载节点连接数不再属于最少标准。 | 常用于长连接服务场景。 |
源 IP 算法 | 将请求的源 IP 地址进行 Hash 运算，得到一个具体的数值，同时对后端服务器进行编号，按照运算结果将请求分发到对应编号的服务器上。这可以使得对不同源 IP 的访问进行负载分发，同时使得同一个客户端 IP 的请求始终被派发至某特定的服务器。 | 该方式适合负载均衡无 cookie 功能的TCP 协议。 |
三、负载均衡健康检查
负载均衡通过健康检查来判断后端负载实例的业务可用性，当后端负载实例的服务异常时，负载均衡根据健康状态判断自动隔离异常节点，不进行流量分发，待后端负载节点服务恢复后，根据健康状态判断自动上线该节点，从而提高前端业务整体可用性。健康检查常用的两种检查机制如下。
1、七层HTTP监听健康检查机制
针对七层HTTP监听，健康检查通过HTTP HEAD探测来获取状态信息。
图1 HTTP监听健康检查机制
负载均衡服务器根据监听的健康检查配置，向后端负载节点发送“IP+健康检查端口+检查路径”的HTTP HEAD请求。后端负载收到请求后，根据相应服务的运行情况，返回HTTP状态码。
如果在响应超时时间之内，负载均衡服务器没有收到后端负载节点返回的信息，则认为服务无响应，判定健康检查失败；如果负载均衡服务器成功接收到后端负载节点返回的状态码，且状态码与配置的状态码一致，则判定健康检查成功，反之则判定健康检查失败。
2、TCP监听健康检查机制
图2 TCP监听监控检查机制
针对四层TCP监听，负载均衡服务器通过TCP的3次握手机制对后端负载节点进行TCP探测，根据监听的健康检查配置，向后端负载节点发送“IP+健康检查端口”的TCP SYN数据包。后端负载节点收到请求后，如果相应端口正在正常监听，则会返回SYN+ACK数据包。
如果在响应超时时间之内，负载均衡服务器接收到后端负载节点返回的数据包，则发送ACK数据包判定健康检查成功，建立TCP连接；如果没有收到后端负载节点返回的数据包，则认为服务无响应，判定健康检查失败并向后端负载节点发送RST数据包中断TCP连接。
四、健康检查周期
健康检查机制有效提高了业务服务的可用性。但是频繁的健康检查一方面会增加后端负载节点的负载压力，另一方面健康检查失败引起的频繁切换对系统可用性也有一定的冲击。因此需要对健康检查周期进行设置，避免频繁检查和频繁切换。健康检查周期由下几个因素决定。
1、检查间隔
每隔多久进行一次健康检查。
2、超时时间
等待健康检查请求返回的时间，返回超时将会被判定为一次检查失败。
3、不健康阈值
健康检查连续失败的次数，达到阈值后端服务将被屏蔽。
4、健康阈值
健康检查连续成功的次数，达到阈值后端服务将被恢复。
健康检查周期的计算方法如下：
健康检查失败周期=超时时间×不健康阈值+检查间隔×（不健康阈值-1）
健康检查成功周期=（健康检查成功响应时间x健康阈值）+检查间隔x（健康阈值-1）
举例：假设健康检查间隔为2s，超时时间为5s，不健康阈值和健康阈值都为3。那么从从健康检查状态成功到到失败需要19s（如图3所示）。健康检查失败到状态检查成功耗时最短为7s（如图3，健康检查OK时间假设为1s）。其中健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时，由于仅探测端口是否存活，因此该时间非常短，几乎可以忽略不计。当采用HTTP方式健康检查时，该时间取决于应用服务器的性能、负载以及相应服务接口的响应时间，但通常都在秒级以内。
图3 健康检查周期计算方法
G行全栈云应用上云分为虚拟机上云和容器化上云。针对不同的上云方式，负载均衡均可提供流量负载均衡服务。应用通过负载均衡ELB将负载流量转发给后端的多个虚拟机或者容器应用，通过TCP和HTTP两种健康检查方式对后端负载的存活状态进行探查。TCP健康检查只探测对应的应用端口是否存在，配置简单，响应较快。HTTP检查可以根据提供的端口和URL路径准确判断应用的健康状态，检查准确性高，覆盖面更全，具体使用方式根据业务场景进行配置。针对流量转发算法，一般负载均衡后端的负载节点配置相同，可采用轮询算法进行负载流量转发。
图4 G行虚拟机上云与容器化上云的负载均衡示意
五、总结
全栈云负载均衡服务，一方面可以替代传统硬件负载均衡设备提供负载能力；另一方面，云上负载均衡设备已云化，具备敏捷交付和弹性扩容能力，且后端负载节点既可以是虚拟机设备，也可以是容器节点，适用性广，同时也拥有满足信创要求的优势。在全行应用系统上云中，它既可以作为负载均衡架构应用组件的负载能力组件，又作为容器应用的统一入口地址，统一对外暴露固定地址，在云环境中将发挥越来越大的作用。
