负载均衡的6种算法:轮询法、随机法、源地址哈希法、最小链接数

支付网关的负载均衡要从两方面考虑：第一要保证支付网关自身接收报文的负载均衡，通常支付网关是支付系统里压力最大的一个组件，因为所有的交易都要经过支付网关，然后分发给各个支付业务系统，而支付网关承担了所有业务系统交易的压力，所以需要的机器是比较多的，对于接收报文的负载均衡能力就很重要了，不能一部分机器超负荷工作，另一部分机器没有被分配到交易量。第二要考虑对支付业务系统的负载均衡，我们使用Spring Cloud微服务架构，提供的是客户端负载均衡能力，所以需要考虑如何对支付网关下游系统做到负载均衡。我们先来看一下负载均衡算法：

• 轮询法：负载均衡器收到请求之后，按顺序分配到后端的服务器上，不考虑服务器的性能、负载。比如有服务器A和服务器B两个服务器，轮询法的处理逻辑是第一次收到报文后交给服务器A来处理，第二次交给服务器B来处理，依次轮询。
• 随机法：负载均衡器收到请求之后，通过随机算法计算分配给哪台服务器，如果请求量特别大，那么起到的效果和轮询法一样。通常会使用随机函数，比如随机生成0到10的数据，小于5的使用服务器A，大于5的使用服务器B。
• 加权轮询法：不同服务器的配置、性能可能不一样，配置高的服务器可以多分配请求，权重可以配得高一些，配置低的服务器少分配请求，权重可以配得低一些。
• 加权随机法：与加权轮询法一样，加权随机法也根据后端机器的配置与系统的负载分配不同的权重。不同的是，它按照权重随机请求后端服务器，而非顺序。
• 源地址哈希法：源地址哈希法是根据请求的客户端的IP地址，通过哈希函数计算得到一个哈希值，将此哈希值和服务器列表的大小进行取模运算，得到的结果便是要访问的服务器地址的序号。
• 最小链接数法：负载均衡器获取服务器的链接数，根据链接数来决定将请求分配到哪台服务器上，把请求分配给积压链接数最少的服务器。

不同的负载均衡算法各有优缺点，根据实际情况自行选择即可。支付网关实现负载均衡的架构如图2-10所示。

Nginx是一个高性能的HTTP和反向代理Web服务器，提供的负载均衡能力非常成熟，网关可以借助Nginx实现针对网关层的负载均衡。针对支付业务层的负载均衡，Spring Cloud Zuul实现的网关使用Ribbon客户端负载均衡能力实现负载均衡，支付网关从Eureka注册中心获取服务列表，根据配置的负载均衡算法分发请求即可。

内容摘自《支付架构实战》，作者苏博亚，支付领域资深技术专家，在支付行业深耕十余年，先后在随行付支付有限公司、美团、有赞科技从事支付业务的开发、设计、架构工作。获得认证：

PMP（项目管理人士资格认证）

OCP（Oracle数据库认证专家）