浅谈高可用的负载均衡集群实现原理及方案


声明:这是我在大学毕业后进入第一家互联网工作学习的内容


现在很多企业的应用都上云了,利用各种云平台的负载均衡组件,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。下面就来聊聊最常用的互联网高可用的负载均衡集群实现方案。

基本概念

在介绍架构之前,为了避免部分读者对架构设计中的一些概念不了解,下面对几个最基础的概念进行介绍。

负载均衡

负载均衡建立在现有网络结构之上,它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。

当请求发送到系统时,通过某些方式把请求均匀分发到多个节点上,使系统中每个节点能够均匀的处理请求负载,则可认为系统是负载均衡的。

高可用

系统中部分节点失效时,其他节点能够接替它继续提供服务,则可认为系统具有高可用性。

集群和分布式

两者很类似,但是却有区别。

  • 集群:将几台服务器集中在一起,实在同一个业务。

  • 分布式:指将不同的业务分布到不同的地方。

分布式的每一个节点,都可以用来做集群。而集群不一定就是分布式了。

例如:zk 1主2从 整体是集群 业务是注册中心 但是主节点和2个从节点是分布式系统 处理不同的问题

实现负载均衡的组件及原理

现在网络中常见的的负载均衡主要分为两种:

  • 硬件:常见的硬件有比较昂贵的NetScaler、F5、Radware和Array等商用的负载均衡器,不过商用负载均衡由于可以建立在四~七层协议之上,因此适用面更广所以有其不可替代性,
    他的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大,
    所以对于规模较小的网络服务来说暂时还没有需要使用。

  • 软件:比较常见的有LVS、Nginx、HAproxy等,
    其中LVS是建立在四层协议上面的,而另外Nginx和HAproxy是建立在七层协议之上的

本文主要讲解如何通过软件实现负载均衡。

组件特点

nginx

  • 工作在网络的7层之上,可以针对http应用做一些分流的策略,比如针对域名、目录结构
  • Nginx对网络的依赖比较小
  • Nginx安装和配置比较简单,测试起来比较方便
  • 也可以承担高的负载压力且稳定,一般能支撑超过1万次的并发
  • Nginx可以通过端口检测到服务器内部的故障,比如根据服务器处理网页返回的状态码、超时等等,并且会把返回错误的请求重新提交到另一个节点,不过其中缺点就是不支持url来检测;
  • Nginx对请求的异步处理可以帮助节点服务器减轻负载;
  • Nginx能支持http和Email,这样就在适用范围上面小很多;
  • 不支持Session的保持、对Big request,header的支持不是很好,另外默认的只有Round-robin和IP-hash两种负载均衡算法。

lvs

  • 抗负载能力强、是工作在网络4层之上仅作分发之用,没有流量的产生;
  • 配置性比较低,这是一个缺点也是一个优点,因为没有可太多配置的东西,所以并不需要太多接触,大大减少了人为出错的几率;
  • 工作稳定,自身有完整的双机热备方案;
  • 无流量,保证了均衡器IO的性能不会收到大流量的影响;
  • 应用范围比较广,可以对所有应用做负载均衡;
  • LVS需要向IDC多申请一个IP来做Visual IP,因此需要一定的网络知识,所以对操作人的要求比较高。

HAProxy

  • HAProxy是工作在网络7层之上。
  • 能够补充Nginx的一些缺点比如Session的保持,Cookie的引导等工作
  • 支持url检测后端的服务器出问题的检测会有很好的帮助。
  • 更多的负载均衡策略比如:动态加权轮循(Dynamic Round Robin),加权源地址哈希(Weighted Source Hash),加权URL哈希和加权参数哈希(Weighted Parameter Hash)已经实现
  • 单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度。
  • HAProxy可以对Mysql进行负载均衡,对后端的DB节点进行检测和负载均衡。

traefik

  • Golang编写,单文件部署,与系统无关,同时也提供小尺寸Docker镜像。
  • 支持Docker/Etcd后端,天然连接我们的微服务集群。
  • 内置Web UI,管理相对方便。
  • 自动配置ACME(Let’s Encrypt)证书功能。
  • 性能尚可,我们也没有到压榨LB性能的阶段,易用性更重要。
  • Restful API支持。
  • 支持后端健康状态检查,根据状态自动配置。
  • 支持WebSocket和HTTP/2。
  • traefik近几年火起来最重要的原因之一就是能够与常见的微服务系统直接整合,可以实现自动化动态配置。

下面用一图说明traefik的特点
浅谈高可用的负载均衡集群实现原理及方案

主流算法

  • 轮询调度(Round Robin 简称’RR’) 就是按依次循环的方式将请求调度到不同的服务器上,该算法最大的特点就是实现简单。轮询算法假设所有的服务器处理请求的能力都一样的,调度器会将所有的请求平均分配给每个真实服务器。
  • 加权轮询(Weight Round Robin 简称’WRR’) 主要是对轮询算法的一种优化与补充,传入的请求按顺序被分配到集群中服务器,但是会考虑提前为每台服务器分配的权重。例如,能力最强的服务器A给的权重是100,同时能力最低的服务器给的权重是50。这意味着在服务器B接收到第一个 请求之前前,服务器A会连续的接受到2个请求,以此类推。
  • 随机(Random)
    通过系统的随机算法,根据后端服务器的列表大小值来随机选取其中的一台服务器进行访问。基于概率统计的理论,吞吐量越大,随机算法的效果越接近于轮询算法的效果。
  • 加权随机(Weight Random)
    与加权轮询法一样,加权随机法也根据后端机器的配置,系统的负载分配不同的权重。不同的是,它是按照权重随机请求后端服务器,而非顺序。
  • 最少连接数(Least Connection)
    以上两种方法都没有考虑的是系统不能识别在给定的时间里保持了多少连接。最小连接数算法比较灵活和智能,由于后端服务器的配置不尽相同,对于请求的处理有快有慢,它是根据后端服务器当前的连接情况,动态地选取其中当前积压连接数最少的一台服务器来处理当前的请求,尽可能地提高后端服务的利用效率,将负责合理地分流到每一台服务器。
  • 源IP哈希(Source IP Hash) 源地址哈希的思想是根据获取客户端的IP地址,通过哈希函数计算得到的一个数值,用该数值对服务器列表的大小进行取模运算,得到的结果便是客户端要访问服务器的序号。

增强负载均衡器可用性(HA)

什么是keepalived

Keepalived是用C语言编写的路由软件。该项目的主要目标是为Linux系统和基于Linux的基础结构提供负载均衡和高可用性的简单而强大的功能。Keepalived实现了一组检查器,以根据其运行状况动态,自适应地维护和管理负载平衡的服务器池。另一方面,VRRP实现了高可用性协议。VRRP是路由器故障转移的基础砖。此外,Keepalived还实现了一组VRRP有限状态机的挂钩,从而提供了低级和高速协议交互。

VRRP协议

虚拟路由器冗余协议(Virtual Router Redundancy Protocol )

VRRP是一种选择协议,它可以把一个虚拟路由器的责任动态分配到局域网上的 VRRP 路由器中的一台。控制虚拟路由器 IP 地址的 VRRP 路由器称为主路由器,它负责转发数据包到这些虚拟 IP 地址。

原理

keepalived也是模块化设计,不同模块复杂不同的功能,下面是keepalived的组件

core check vrrp libipfwc libipvs-2.4 libipvs-2.6

  • core:是keepalived的核心,复杂主进程的启动和维护,全局配置文件的加载解析等
  • check:负责healthchecker(健康检查),包括了各种健康检查方式,以及对应的配置的解析包括LVS的配置解析
  • vrrp:VRRPD子进程,VRRPD子进程就是来实现VRRP协议的
  • libipfwc:iptables(ipchains)库,配置LVS会用到
  • libipvs*:配置LVS会用到

keepalived启动后会有三个进程
父进程:内存管理,子进程管理等等
子进程:VRRP子进程
子进程:healthcheckers子进程

设计nginx+keepalived+nacos+mysql实现配置及注册中心高可用框架

本文设计的框架是基于nacos官方文档针对生产环境的nacos搭建的补充。

naocs框架为
http://nacos.com:port/openAPI 域名 + VIP模式,可读性好,而且换ip方便

nginx作为负载均衡器,keepalived保证nginx的高可用

具体实现如图
浅谈高可用的负载均衡集群实现原理及方案

本期不做部署说明,下期具体说明如何在实战中部署此架构。

参考资料

分布式共识算法图解

网络7层协议图解

淘宝双11,亿级流量高并发是怎么抗住的?看完这篇你就明白了!

几种常见负载均衡比较

keepalived官网

nacos官网


版权声明:

原创不易,洗文可耻。除非注明,本博文章均为原创,转载请以链接形式标明本文地址。