负载均衡
负载均衡
负载均衡(Load Balancer)是指把用户访问的流量,通过「负载均衡器」,根据某种转发的策略,均匀的分发到后端多台服务器上,后端的服务器可以独立的响应和处理请求,从而实现分散负载的效果。负载均衡技术提高了系统的服务能力,增强了应用的可用性。
目前市面上最常见的负载均衡技术方案主要有三种:
- 基于DNS负载均衡
- 基于硬件负载均衡
- 基于软件负载均衡
DNS负载均衡可以实现在地域上的流量均衡,硬件负载均衡主要用于大型服务器集群中的负载需求,而软件负载均衡大多是基于机器层面的流量均衡。在实际场景中,这三种是可以组合在一起使用。
基于DNS来做负载均衡其实是一种最简单的实现方案,通过在DNS服务器上做一个简单配置即可。 其原理就是当用户访问域名的时候,会先向DNS服务器去解析域名对应的IP地址,这个时候我们可以让DNS服务器根据不同地理位置的用户返回不同的IP。比如南方的用户就返回我们在广州业务服务器的IP,北方的用户来访问的话,我就返回北京业务服务器所在的IP。
在这个模式下,用户就相当于实现了按照「就近原则」将请求分流了,既减轻了单个集群的负载压力,也提升了用户的访问速度。
使用DNS做负载均衡的方案,天然的优势就是配置简单,实现成本非常低,无需额外的开发和维护工作。 但是也有一个明显的缺点是:当配置修改后,生效不及时。这个是由于DNS的特性导致的,DNS一般会有多级缓存,所以当我们修改了DNS配置之后,由于缓存的原因,会导致IP变更不及时,从而影响负载均衡的效果。
基于硬件:F5 Network Big-IP
优点:能够直接通过智能交换机实现,处理能力更强,而且与系统无关,负载性能强更适用于一大堆设备、大访问量、简单应用。
缺点:成本高
基于软件负载均衡:软件负载均衡是指使用软件的方式来分发和均衡流量。软件负载均衡,分为7层协议 和 4层协议。 网络协议有七层,基于第四层传输层来做流量分发的方案称为4层负载均衡,例如 LVS,而基于第七层应用层来做流量分发的称为7层负载均衡,例如 Nginx
算法:
- 轮询策略
- 负载度策略
- 响应策略
- 哈希策略
轮询有多种方式,有按顺序轮询的、有随机轮询的、还有按照权重来轮询的。前两种比较好理解,第三种按照权重来轮询,是指给每台后端服务设定一个权重值,比如性能高的服务器权重高一些,性能低的服务器给的权重低一些,这样设置的话,分配流量的时候,给权重高的更多流量,可以充分的发挥出后端机器的性能。
负载度策略是指当「负载均衡器」往后端转发流量的时候,会先去评估后端每台服务器的负载压力情况,对于压力比较大的后端服务器转发的请求就少一些,对于压力比较小的后端服务器可以多转发一些请求给它。
这种方式就充分的结合了后端服务器的运行状态,来动态的分配流量了,比轮询的方式更为科学一些。
但是这种方式也带来了一些弊端,因为需要动态的评估后端服务器的负载压力,那这个「负载均衡器」除了转发请求以外,还要做很多额外的工作,比如采集 连接数、请求数、CPU负载指标、IO负载指标等等,通过对这些指标进行计算和对比,判断出哪一台后端服务器的负载压力较大。
响应策略是指,当用户请求过来的时候,「负载均衡器」会优先将请求转发给当前时刻响应最快的后端服务器。 也就是说,不管后端服务器负载高不高,也不管配置如何,只要觉得这个服务器在当前时刻能最快的响应用户的请求,那么就优先把请求转发给它,这样的话,对于用户而言,体验也最好。
那「负载均衡器」是怎么知道哪一台后端服务在当前时刻响应能力最佳呢? 这就需要「负载均衡器」不停的去统计每一台后端服务器对请求的处理速度了,比如一分钟统计一次,生成一个后端服务器处理速度的排行榜。然后「负载均衡器」根据这个排行榜去转发服务。
Hash策略也比较好理解,就是将请求中的某个信息进行hash计算,然后根据后端服务器台数取模,得到一个值,算出相同值的请求就被转发到同一台后端服务器中。常见的用法是对用户的IP或者ID进行这个策略,然后「负载均衡器」就能保证同一个IP来源或者同一个用户永远会被送到同一个后端服务器上了,一般用于处理缓存、会话等功能的时候特别好用。