快速理解高性能HTTP服务端的负载均衡技术原理

本文涉及的产品
传统型负载均衡 CLB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
EMR Serverless StarRocks,5000CU*H 48000GB*H
简介:

1、前言

在一个典型的高并发、大用户量的Web互联网系统的架构设计中,对HTTP集群的负载均衡设计是作为高性能系统优化环节中必不可少的方案。HTTP负载均衡的本质上是将Web用户流量进行均衡减压,因此在互联网的大流量项目中,其重要性不言而喻。

本文将以简洁通俗的文字,为你讲解主流的HTTP服务端实现负载均衡的常见方案,以及具体到方案中的负载均衡算法的实现原理。理解和掌握这些方案、算法原理,有助于您今后的互联网项的技术选型和架构设计,因为没有哪一种方案和算法能解决所有问题,只有针对特定的场景使用合适的方案和算法才是最明智的选择。

即时通讯网注:本文中所提及的HTTP负载均衡方案和算法,并不完全适用IM即时通讯Socket长连接的负载均衡,因为IM长连接、有状态的特性,跟HTTP这种短连接、无状态的特征是矛盾的,所以请勿盲目套用。但,一个完整的IM系统是由HTTP短连接+IM长连接组成,因而本文内容虽不能套用于IM长连接的负载均衡方案,但可以用于您IM的高并发、大用户量的HTTP短连接的方案设计。

(本文同步发布于:http://www.52im.net/thread-1950-1-1.html

2、相关文章

深入阅读以下文章,有助于您更好地理解本篇内容:

腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面

以微博类应用场景为例,总结海量社交系统的架构设计步骤

IM开发基础知识补课(四):正确理解HTTP短连接中的Cookie、Session和Token

3、什么是负载均衡?

早期的互联网应用,由于用户流量比较小,业务逻辑也比较简单,往往一个单服务器就能满足负载需求。随着现在互联网的流量越来越大,稍微好一点的系统,访问量就非常大了,并且系统功能也越来越复杂,那么单台服务器就算将性能优化得再好,也不能支撑这么大用户量的访问压力了,这个时候就需要使用多台机器,设计高性能的集群来应对。

那么,多台服务器是如何去均衡流量、如何组成高性能的集群的呢?

此时就需要请出 「负载均衡器」 入场了。

负载均衡(Load Balancer)是指把用户访问的流量,通过「负载均衡器」,根据某种转发的策略,均匀的分发到后端多台服务器上,后端的服务器可以独立的响应和处理请求,从而实现分散负载的效果。负载均衡技术提高了系统的服务能力,增强了应用的可用性。

负载均衡的基本原理就像下图这样:

webp

4、主流负载均衡方案有几种?

目前市面上最常见的负载均衡技术方案主要有三种:

1)基于DNS负载均衡;

2)基于硬件负载均衡:比如F5

3)基于软件负载均衡:比如Nginx、Squid。

三种方案各有优劣,DNS负载均衡可以实现在地域上的流量均衡,硬件负载均衡主要用于大型服务器集群中的负载需求,而软件负载均衡大多是基于机器层面的流量均衡。在实际场景中,这三种是可以组合在一起使用。

下面分别来详细讲讲这些方案。

4.1 基于DNS负载均衡

webp

基于DNS来做负载均衡其实是一种最简单的实现方案,通过在DNS服务器上做一个简单配置即可。

其原理就是:当用户访问域名的时候,会先向DNS服务器去解析域名对应的IP地址,这个时候我们可以让DNS服务器根据不同地理位置的用户返回不同的IP。比如南方的用户就返回我们在广州业务服务器的IP,北方的用户来访问的话,我就返回北京业务服务器所在的IP。

在这个模式下,用户就相当于实现了按照「就近原则」将请求分流了,既减轻了单个集群的负载压力,也提升了用户的访问速度。

使用DNS做负载均衡的方案,天然的优势就是配置简单,实现成本非常低,无需额外的开发和维护工作。

但是它也有一个明显的缺点:当配置修改后,生效不及时。这个是由于DNS的特性导致的,DNS一般会有多级缓存,所以当我们修改了DNS配置之后,由于缓存的原因,会导致IP变更不及时,从而影响负载均衡的效果。

另外,使用DNS做负载均衡的话,大多是基于地域或者干脆直接做IP轮询,没有更高级的路由策略,所以这也是DNS方案的局限所在。

4.2 基于硬件负载均衡

webp

硬件的负载均衡那就比较牛逼了,比如大名鼎鼎的 F5 Network Big-IP,也就是我们常说的 F5,它是一个网络设备,你可以简单的理解成类似于网络交换机的东西,完全通过硬件来抗压力,性能是非常的好,每秒能处理的请求数达到百万级,即 几百万/秒 的负载,当然价格也就非常非常贵了,十几万到上百万人民币都有。

因为这类设备一般用在大型互联网公司的流量入口最前端,以及政府、国企等不缺钱企业会去使用。一般的中小公司是不舍得用的。

采用 F5 这类硬件做负载均衡的话,主要就是省心省事,买一台就搞定,性能强大,一般的业务不在话下。而且在负载均衡的算法方面还支持很多灵活的策略,同时还具有一些防火墙等安全功能。但是缺点也很明显,一个字:贵。

4.3 基于软件负载均衡

webp

软件负载均衡是指使用软件的方式来分发和均衡流量。软件负载均衡分为7层协议 和 4层协议。

网络协议有七层,基于第四层传输层来做流量分发的方案称为4层负载均衡,例如 LVS;而基于第七层应用层来做流量分发的称为7层负载均衡,例如 Nginx。这两种在性能和灵活性上是有些区别的。

基于4层的负载均衡性能要高一些,一般能达到 几十万/秒 的处理量,而基于7层的负载均衡处理量一般只在 几万/秒 。

基于软件的负载均衡的特点也很明显,便宜。在正常的服务器上部署即可,无需额外采购,就是投入一点技术去优化优化即可,因此这种方式是互联网公司中用得最多的一种方式。

5、常用的均衡算法有哪些?

上面讲完了常见的负载均衡技术方案,那么接下来咱们看一下,在实际方案应用中,一般可以使用哪些均衡算法?

主要的均衡算法有:

1)轮询策略;

2)负载度策略;

3)响应策略;

4)哈希策略。

下面来分别介绍一下这几种均衡算法/策略的特点。

5.1 轮询策略

轮询策略其实很好理解,就是当用户请求来了之后,「负载均衡器」将请求轮流的转发到后端不同的业务服务器上。这个策略在DNS方案中用的比较多,无需关注后端服务的状态,只药有请求,就往后端轮流转发,非常的简单、实用。

在实际应用中,轮询也会有多种方式,有按顺序轮询的、有随机轮询的、还有按照权重来轮询的。前两种比较好理解,第三种按照权重来轮询,是指给每台后端服务设定一个权重值,比如性能高的服务器权重高一些,性能低的服务器给的权重低一些,这样设置的话,分配流量的时候,给权重高的更多流量,可以充分的发挥出后端机器的性能。

5.2 负载度策略

负载度策略是指当「负载均衡器」往后端转发流量的时候,会先去评估后端每台服务器的负载压力情况,对于压力比较大的后端服务器转发的请求就少一些,对于压力比较小的后端服务器可以多转发一些请求给它。

这种方式就充分的结合了后端服务器的运行状态,来动态的分配流量了,比轮询的方式更为科学一些。

但是这种方式也带来了一些弊端,因为需要动态的评估后端服务器的负载压力,那这个「负载均衡器」除了转发请求以外,还要做很多额外的工作,比如采集 连接数、请求数、CPU负载指标、IO负载指标等等,通过对这些指标进行计算和对比,判断出哪一台后端服务器的负载压力较大。

因此这种方式带来了效果优势的同时,也增加了「负载均衡器」的实现难度和维护成本。

5.3 响应策略

响应策略是指,当用户请求过来的时候,「负载均衡器」会优先将请求转发给当前时刻响应最快的后端服务器。

也就是说,不管后端服务器负载高不高,也不管配置如何,只要觉得这个服务器在当前时刻能最快的响应用户的请求,那么就优先把请求转发给它,这样的话,对于用户而言,体验也最好。

那「负载均衡器」是怎么知道哪一台后端服务在当前时刻响应能力最佳呢?

这就需要「负载均衡器」不停的去统计每一台后端服务器对请求的处理速度了,比如一分钟统计一次,生成一个后端服务器处理速度的排行榜。然后「负载均衡器」根据这个排行榜去转发服务。

那么这里的问题就是统计的成本了,不停的做这些统计运算本身也会消耗一些性能,同时也会增加「负载均衡器」的实现难度和维护成本。

5.4 哈希策略

Hash策略也比较好理解,就是将请求中的某个信息进行hash计算,然后根据后端服务器台数取模,得到一个值,算出相同值的请求就被转发到同一台后端服务器中。

常见的用法是对用户的IP或者ID进行这个策略,然后「负载均衡器」就能保证同一个IP来源或者同一个用户永远会被送到同一个后端服务器上了,一般用于处理缓存、会话等功能的时候特别好用。

6、本文小结

基于运营成本的考虑,目前在互联网项目中,HTTP服务端的负载均衡的具体解决方案,用的最多的还是Nginx(及其分支,比如淘宝的Tengin),如果有时间,建议可以把Nginx下载下来,仔细研究研究它的负载均衡原理,以及它所提供的几种负载均衡算法,理论联系实际来学习就更能促进你对相关知识的理解和掌握了。

得益于Nginx这种开源免费的高性能方案,它们间接地促进了互联网的繁荣,感谢这些伟大开源方案背后的无私贡献者们!

附录:更多架构设计方案的文章精选

浅谈IM系统的架构设计

简述移动端IM开发的那些坑:架构设计、通信协议和客户端

一套海量在线用户的移动端IM架构设计实践分享(含详细图文)

一套原创分布式即时通讯(IM)系统理论架构方案

从零到卓越:京东客服即时通讯系统的技术架构演进历程

蘑菇街即时通讯/IM服务器开发之架构选择

腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT

微信后台基于时间序的海量数据冷热分级架构设计实践

微信技术总监谈架构:微信之道——大道至简(演讲全文)

如何解读《微信技术总监谈架构:微信之道——大道至简》

快速裂变:见证微信强大后台架构从0到1的演进历程(一)

17年的实践:腾讯海量产品的技术方法论

移动端IM中大规模群消息的推送如何保证效率、实时性?

现代IM系统中聊天消息的同步和存储方案探讨

IM开发基础知识补课(二):如何设计大量图片文件的服务端存储架构?

IM开发基础知识补课(三):快速理解服务端数据库读写分离原理及实践建议

IM开发基础知识补课(四):正确理解HTTP短连接中的Cookie、Session和Token

WhatsApp技术实践分享:32人工程团队创造的技术神话

微信朋友圈千亿访问量背后的技术挑战和实践总结

王者荣耀2亿用户量的背后:产品定位、技术架构、网络方案等

IM系统的MQ消息中间件选型:Kafka还是RabbitMQ?

腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面

以微博类应用场景为例,总结海量社交系统的架构设计步骤

快速理解高性能HTTP服务端的负载均衡技术原理

>> 更多同类文章 ……

(本文同步发布于:http://www.52im.net/thread-1950-1-1.html

相关实践学习
SLB负载均衡实践
本场景通过使用阿里云负载均衡 SLB 以及对负载均衡 SLB 后端服务器 ECS 的权重进行修改,快速解决服务器响应速度慢的问题
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
目录
相关文章
|
6天前
|
缓存 移动开发 前端开发
HTTP请求走私漏洞原理与利用手段分析
HTTP请求走私漏洞原理与利用手段分析
15 1
|
29天前
|
安全 网络安全 数据安全/隐私保护
http原理
http原理
24 3
|
29天前
|
安全 网络安全 数据安全/隐私保护
https的原理
https的原理
26 2
|
2月前
|
存储 网络协议 安全
HTTP协议和运行原理
HTTP协议和运行原理
|
2月前
|
安全 算法 网络协议
【在Linux世界中追寻伟大的One Piece】HTTPS协议原理
【在Linux世界中追寻伟大的One Piece】HTTPS协议原理
42 2
|
3月前
|
缓存 网络协议 算法
(二)Java网络编程之爆肝HTTP、HTTPS、TLS协议及对称与非对称加密原理!
作为一名程序员,尤其是Java程序员,那必须得了解并掌握HTTP/HTTPS相关知识。因为在如今计算机网络通信中,HTTP协议的作用功不可没,无论是日常上网追剧、冲���、亦或是接口开发、调用等,必然存在HTTP的“影子”在内。尤其对于WEB开发者而言,HTTP几乎是每天会打交道的东西。
72 10
|
3月前
|
数据采集 缓存 安全
http proxy 协议的工作原理与常见用途
在这篇博客文章中,我们将深入探讨HTTP代理协议的工作原理,揭示它如何在客户端和服务器之间传递HTTP请求和响应,并讨论它在各种应用场景中的常见用途。
http proxy 协议的工作原理与常见用途
|
2月前
|
安全 Nacos 数据安全/隐私保护
【技术干货】破解Nacos安全隐患:连接用户名与密码明文传输!掌握HTTPS、JWT与OAuth2.0加密秘籍,打造坚不可摧的微服务注册与配置中心!从原理到实践,全方位解析如何构建安全防护体系,让您从此告别数据泄露风险!
【8月更文挑战第15天】Nacos是一款广受好评的微服务注册与配置中心,但其连接用户名和密码的明文传输成为安全隐患。本文探讨加密策略提升安全性。首先介绍明文传输风险,随后对比三种加密方案:HTTPS简化数据保护;JWT令牌减少凭证传输,适配分布式环境;OAuth2.0增强安全,支持多授权模式。每种方案各有千秋,开发者需根据具体需求选择最佳实践,确保服务安全稳定运行。
163 0
|
2月前
|
负载均衡 网络协议 应用服务中间件
nginx-http反向代理与负载均衡
nginx-http反向代理与负载均衡
|
3月前
|
负载均衡 安全 Cloud Native
云上负载均衡:构建高可用、高性能的网络应用架构
与云原生技术深度融合:随着云原生技术的普及和发展未来的云上负载均衡将更加紧密地与云原生技术相结合。例如与Kubernetes等容器编排平台集成实现自动化的服务发现和路由管理;与Serverless架构结合提供无缝的流量接入和请求处理能力。 安全性能提升:面对日益严峻的网络安全威胁云上负载均衡将更加注重安全性能的提升。通过引入加密传输、访问控制、DDoS防护等安全措施确保网络流量的安全性和隐私性;同时还将建立完善的安全监控和应急响应机制以应对各种安全事件和突发事件。 支持多协议和多场景:未来的云上负载均衡将支持更多种类的网络协议和应用场景以满足不同用户和业务的需求。例如支持HTTP/2、
171 0