云原生必备知识: 负载均衡

本文涉及的产品
应用型负载均衡 ALB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
云解析 DNS,旗舰版 1个月
简介: 负载均衡,英文名称为Load Balance,其含义就是指将负载(工作任务)进行平衡、分摊到多个操作单元上进行运行,例如FTP服务器、Web服务器、企业核心应用服务器和其它主要任务服务器等,从而协同完成工作任务。负载均衡构建在原有网络结构之上,它提供了一种透明且廉价有效的方法扩展服务器和网络设备的带宽、加强网络数据处理能力、增加吞吐量、提高网络的可用性和灵活性。

所属技术领域:

云原生

| 名词定义 |

负载均衡,英文名称为Load Balance,其含义就是指将负载(工作任务)进行平衡、分摊到多个操作单元上进行运行,例如FTP服务器、Web服务器、企业核心应用服务器和其它主要任务服务器等,从而协同完成工作任务。
负载均衡构建在原有网络结构之上,它提供了一种透明且廉价有效的方法扩展服务器和网络设备的带宽、加强网络数据处理能力、增加吞吐量、提高网络的可用性和灵活性。

| 发展历程 |

一项技术的兴起,就是要看它的应用发展空间是多大的。那么网络负载均衡技术也是随着网络发展而兴起的。现在让我们回首,看看它的发展历史,同时,也是对网络的发展有一个侧面的认识。首先我们要弄清楚负载均衡从何而来,在什么基础上才被研发出来的。
1996-1999年:发现商机:网络负载均衡的起始阶段
2000-2003年:网络泡沫破裂的生存考验将重心锁定企业
2003-2005年:网络流量不断升级TMOS显威力
2006-2008年,负载均衡升级:向应用交付发展
◆1996-1999年:发现商机:网络负载均衡的起始阶段
Foundry最早提出了四层网络负载均衡的概念,当时的负载均衡技术主要实现四层的交换。因为Foundry是传统的交换机设备厂商,它将此项技术集成在了自己的交换机设备里。
◆1996年,由美国华盛顿大学的几个学生创立了F5公司,一个新的网络负载均衡企业诞生了。
据F5总裁JohnMcAdam介绍:F5当时的几位学生创业者,比较热衷于虚拟现实,当时,他们在做这件事情的过程中就发现,负载均衡是一种很有用的技术。如果将这项技术应用在网络上,就一定会有一个大的发展,所以他们就在1996年就创办了这家公司。F5为何会选择网络负载均衡作为创业点呢?JohnMcAdam介绍到:Internet的规模每一百天就会增长一倍,网络应用流量也越来越大。网络的各个核心部分随着业务量的提高、访问量和数据流量的快速增长,其处理能力和计算强度也相应增大,使得单一设备根本无法承担。在此情况下,如果扔掉现有设备去做大量的硬件升级,这样将造成现有资源的浪费,而且如果再面临下一次业务量的提升,这又将导致再一次硬件升级的高额成本投入,甚至性能再卓越的设备也不能满足当前业务量的需求。于是,网络负载均衡机制应运而生,这是一个巨大的市场机会。F5当时的这几个创业者就正好选择了这个机会。因为当时一部叫《龙卷风》的电影非常红,而龙卷风的最高等级就是F5,这代表极限的意思。所以,F5网络的创业者就把公司取名为"F5",代表最高的极限追求。F5的第一个客户是有名的Playboy(花花公子),虽然,在概念上,F5网络负载均衡与"花花公子"一点关系都没有,但Playboy的大名非常有利于F5的推广销售。1999年,F5成功上市。
◆2000-2003年:网络泡沫破裂的生存考验将重心锁定企业
网络负载均衡的机会在于网络应用的扩张,网络流量的增大,所以,它非常依赖于网络的发展。然而,在2000年里,当互联网的泡沫破裂时,所有的网络负载均衡厂商都面临了生存的考验。在这个时期,刚创立不久的F5可谓是生不逢时,同样受到了生存的考验。于是,F5将业务重心从互联网转移到大企业方面,专门针对电信、银行,以及联邦政府等大企业做网络负载均衡。与此同时,F5还开始与微软、甲骨文、DELL等这样大的厂商展开了合作,通过合作厂商,把网络负载均衡解决方案卖到大型企业里面去。例如,F5通过与DELL的合作,在2001年的时候,就把BIGIPBladeServer(F5的早期负载均衡产品,集成在DELL设备里)卖到了大型银行机构中,这保证了F5生存下去。你可能会发现这样一个问题:F5仅仅是一家才几年的新兴网络厂商,微软、DELL等IT巨头为何会跟F5合作呢?F5总裁JohnMcAdam解释到:"F5当时开发了iControl技术,这是一种开放的应用程序接口,通过这种技术,可以控制和优化企业网络,这是当时微软、甲骨文等企业都做不到的,但又是一种非常有用的技术。"在2002年里,F5的发展非常缓慢,其营业额停滞不前,作为一家华尔街的上市公司,每个季度也就2700万美金。正是在这个时候,F5投入250人年展开了新一代网络负载均衡平台TMOS的开发。同期,其实,思科、北电等传统网络设备厂商也注意到了四层网络负载均衡技术,于是,他们各自都收购了相应的负载均衡小厂商,例如思科收购了ArrowPoint等。但是,思科、北电在网络负载均衡这块市场,同样遇到了像F5这样厂商的网络泡沫困难。JohnMcAdam强调到:"因为市场未打开,前景不明,所以思科未在这块做更大的技术投入。但我们却不断的往里面投入,所以,最后思科和F5的距离就这么拉开了。"
◆2003-2005年:网络流量不断升级TMOS显威力
2003年非典爆发,这是一个灾难,然而,却是互联网的发展机会。网上看新闻、网上定餐、电话问候等等,网络应用快速发展起来。在全球市场上,众多的企业也从互联网的泡沫经济中走出来,开始走向理性化的发展方向。在前面一轮的基础设施建设的基础上,开始更加重视增值业务/数据业务的建设工作。此外,互联网泡沫时代所引导的客户经济,也在这个时间开始体现出了真正的经济效益,各种增值业务如网上银行、电信运营商的短信增值业务,也在这个时期开始蓬勃发展,并产生出了巨大的经济效益,接踵而至的就是各种各样的网络应用流量瓶颈问题开始凸显,网络游戏这个典型的互联网经济在这个时候也开始进入爆发式增长阶段。此外,加上国内的电信、网通南北分拆,导致南北互通问题,这导致不少企业的网络流量瓶颈问题更显突出。这种种问题,并不是单纯升级传统的路由、交换设备而能解决的。而网络负载均衡设备正好能解决这些问题。在这个时期,包括F5、Netscaler在内的网络负载均衡设备厂商,都得到了快速的发展。对于F5来说,从2002年开始研发的TOMS平台,于2004年正式投入市场。F5总裁JohnMcAdam表示:TMOS平台是全套的网络流量管理系统,它包括BIG-IP、WANJet、WebAccelerator、FirePass、Trafficshield等系列产品。分别针对网络访问、数据中心同步访问、远程办公、应用防火墙等多种为了提升关键业务访问效率的解决方案。例如,TOM在线部署了F53DNS负载均衡设备,从而有效地解决了南北互通的问题,保证了用户访问TOM网页的速度,这对于保证TOM在线的SP增值业务快速发展,领先竞争对手,起到了至关重要的作用。
◆2006-2008年,负载均衡升级:向应用交付发展
从2006年开始,国内股市开始火爆起来,随着上交所、深交所的股票交易量不断创新高,证券交易的"堵单"现象越来越严重。此外,企业电子商务的网络应用越来越多,而彩信应用的推广,对网络带宽也有了新的要求;此时,国内视频网站开始纷纷出现,流媒体形成的巨大访问量,需要提供更高的网络流量处理能力,对于四层负载均衡交换机的压力会更大。在这种情况下,普通的负载均衡设备已经难以满足网络应用流量增长的需求。此时,以应用为导向的方案越来越明显了,综合多种技术手段的需求越来越强。于是,F5进一步完善了TOMS平台,并开始倡导"应用交付、AdvancedADC"概念,这是网络负载均衡概念的扩充。我们可以这样形象地理解:基于网络二层、三层的是路由交换,而基于网络七层的则是"应用交换",应用交付是完全基于网络应用的系统解决方案,它将关键应用与基础网络设备关联起来。网络负载均衡"L4-7LoadBalance"和应用交付"AdvancedADC"是两个独立的设备市场。其中,网络负载均衡"L4-7LoadBalance"指具有传统的网络负载均衡机制的设备;而"AdvancedADC"则是传统的网络负载均衡的升级、扩展,它是一种综合的交付平台设备,其综合了负载平衡、TCP优化管理、链接管理、SSLVPN、压缩优化、智能网络地址转换、高级路由、智能端口镜像等各种技术手段的综合平台。综合了多种交付手段的应用交付设备(包括有L4-7LoadBalance功能)将是未来的趋势,而仅有L4-7LoadBalance功能的设备的市场将越来越小。到现在为止,F5已经连续几年位居Gartner的应用交付(ADC)神奇像限的领导地位。不过,最近两年来,思科也越来越重视这个应用交付(网络负载均衡)市场了,因为思科有强大的基础网络设备用户群,再加上其销售队伍的庞大,这给F5带来了较大的竞争压力。不过,正是因为更多厂商对应用交付(网络负载均衡)的重视,这个市场才会更大,技术也更成熟。

| 技术特点 |

全局负载均衡有以下特点:

• 解决网络拥塞问题,服务就近提供,实现地理位置无关性。

• 对用户提供更好的访问质量。

• 提高服务器响应速度。

• 提高服务器及其他资源的利用效率。

• 避免了数据中心单点故障。

另外,在负载均衡实现方式上,还有软、硬件之分。软件负载均衡解决方案是指在一台或多台服务器相应的操作系统上,安装一个或多个附加软件来实现负载均衡,如DNS 负载均衡等。它的优点是基于特定环境、配置简单、使用灵活、成本低廉,可以满足一般的负载均衡需求。

硬件负载均衡解决方案是直接在服务器和外部网络间安装负载均衡设备,这种设备我们通常称之为负载均衡器。由于专门的设备完成专门的任务,独立于操作系统,整体性能得到 很大提高,加上多样化的负载均衡策略,智能化的流量管理,可达到簸佳的负载均衡需求。一般而言,硬件负载均衡在功能、性能上优于软件方式,不过成本昂贵。

负载均衡策略

要部署负载均衡,首先要选择适当的均衡策略,也就是依据什么来达到负载均衡的目的, 或者说是依据什么来把负载分配给不同的服务器。

选则合适的负载均衡策略,使多个设备能很好地共同完成任务,消除或避免现有网络负载分布不均、数据流量拥挤反应时间长的瓶颈。在各负载均衡方式中,针对不阔的应用需求。负载均衡策略的优劣及其实现的难易程度有两个关键因素:一、负载均衡算法,二、对网络系统状况的检测方式和能力。

| 相关词 |

1、软/硬件负载均衡
软件负载均衡解决方案是指在一台或多台服务器相应的操作系统上安装一个或多个附加软件来实现负载均衡,如DNS Load Balance,CheckPoint Firewall-1 ConnectControl等,它的优点是基于特定环境,配置简单,使用灵活,成本低廉,可以满足一般的负载均衡需求。
软件解决方案缺点也较多,因为每台服务器上安装额外的软件运行会消耗系统不定量的资源,越是功能强大的模块,消耗得越多,所以当连接请求特别大的时候,软件本身会成为服务器工作成败的一个关键;软件可扩展性并不是很好,受到操作系统的限制;由于操作系统本身的Bug,往往会引起安全问题。
硬件负载均衡解决方案是直接在服务器和外部网络间安装负载均衡设备,这种设备通常称之为负载均衡器,由于专门的设备完成专门的任务,独立于操作系统,整体性能得到大量提高,加上多样化的负载均衡策略,智能化的流量管理,可达到最佳的负载均衡需求。
负载均衡器有多种多样的形式,除了作为独立意义上的负载均衡器外,有些负载均衡器集成在交换设备中,置于服务器与Internet链接之间,有些则以两块网络适配器将这一功能集成到PC中,一块连接到Internet上,一块连接到后端服务器群的内部网络上。一般而言,硬件负载均衡在功能、性能上优于软件方式,不过成本昂贵。
2、本地/全局负载均衡
负载均衡从其应用的地理结构上分为本地负载均衡(Local Load Balance)和全局负载均衡(Global Load Balance,也叫地域负载均衡),本地负载均衡针对本地范围的服务器群做负载均衡,全局负载均衡针对不同地理位置、不同网络结构的服务器群做负载均衡。
本地负载均衡不需要花费高额成本购置高性能服务器,只需利用现有设备资源,就可有效避免服务器单点故障造成数据流量的损失,通常用来解决数据流量过大、网络负荷过重的问题。同时它拥有形式多样的均衡策略把数据流量合理均衡的分配到各台服务器。如果需要在现在服务器上升级扩充,不需改变现有网络结构、停止现有服务,仅需要在服务群中简单地添加一台新服务器。
全局负载均衡主要解决全球用户只需一个域名或IP地址就能访问到离自己距离最近的服务器获得最快的访问速度,它在多区域都拥有自己的服务器站点,同时也适用于那些子公司站点分布广的大型公司通过企业内部网(Intranet)达到资源合理分配的需求。
全局负载均衡具备的特点:
1、提高服务器响应速度,解决网络拥塞问题,达到高质量的网络访问效果。
2、能够远距离为用户提供完全的透明服务,真正实现与地理位置无关性
3、能够避免各种单点失效,既包括数据中心、服务器等的单点失效,也包括专线故障引起的单点失效。

适用场景:

1、DNS负载均衡 最早的负载均衡技术是通过DNS来实现的,在DNS中为多个地址配置同一个名字,因而查询这个名字的客户机将得到其中一个地址,从而使得不同的客户访问不同的服务器,达到负载均衡的目的。DNS负载均衡是一种简单而有效的方法,但是它不能区分服务器的差异,也不能反映服务器的当前运行状态。
2、代理服务器负载均衡 使用代理服务器,可以将请求转发给内部的服务器,使用这种加速模式显然可以提升静态网页的访问速度。然而,也可以考虑这样一种技术,使用代理服务器将请求均匀转发给多台服务器,从而达到负载均衡的目的。
3、地址转换网关负载均衡 支持负载均衡的地址转换网关,可以将一个外部IP地址映射为多个内部IP地址,对每次TCP连接请求动态使用其中一个内部地址,达到负载均衡的目的。
4、协议内部支持负载均衡除了这三种负载均衡方式之外,有的协议内部支持与负载均衡相关的功能,例如HTTP协议中的重定向能力等,HTTP运行于TCP连接的最高层。
5、NAT负载均衡NAT(Network Address Translation网络地址转换)简单地说就是将一个IP地址转换为另一个IP地址,一般用于未经注册的内部地址与合法的、已获注册的Internet IP地址间进行转换。适用于解决Internet IP地址紧张、不想让网络外部知道内部网络结构等的场合下。
6、反向代理负载均衡普通代理方式是代理内部网络用户访问internet上服务器的连接请求,客户端必须指定代理服务器,并将本来要直接发送到internet上服务器的连接请求发送给代理服务器处理。反向代理(Reverse Proxy)方式是指以代理服务器来接受internet上的连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给internet上请求连接的客户端,此时代理服务器对外就表现为一个服务器。反向代理负载均衡技术是把将来自internet上的连接请求以反向代理的方式动态地转发给内部网络上的多台服务器进行处理,从而达到负载均衡的目的。
7、混合型负载均衡在有些大型网络,由于多个服务器群内硬件设备、各自的规模、提供的服务等的差异,可以考虑给每个服务器群采用最合适的负载均衡方式,然后又在这多个服务器群间再一次负载均衡或群集起来以一个整体向外界提供服务(即把这多个服务器群当做一个新的服务器群),从而达到最佳的性能。将这种方式称之为混合型负载均衡。此种方式有时也用于单台均衡设备的性能不能满足大量连接请求的情况下。

资料来源:

  1. 名词定义:百度百科
  2. 发展历程:https://network.51cto.com/art/201004/196764_all.htm
  3. 技术特点:http://www.xinnet.com/xinnews/cloudhost/36827.html
  4. 适用场景:百度百科
  5. 相关词:百度百科
相关实践学习
SLB负载均衡实践
本场景通过使用阿里云负载均衡 SLB 以及对负载均衡 SLB 后端服务器 ECS 的权重进行修改,快速解决服务器响应速度慢的问题
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
相关文章
|
5月前
|
Kubernetes Cloud Native 微服务
企业级容器部署实战:基于ACK与ALB灵活构建云原生应用架构
这篇内容概述了云原生架构的优势,特别是通过阿里云容器服务Kubernetes版(ACK)和应用负载均衡器(ALB)实现的解决方案。它强调了ACK相对于自建Kubernetes的便利性,包括优化的云服务集成、自动化管理和更强的生态系统支持。文章提供了部署云原生应用的步骤,包括一键部署和手动部署的流程,并指出手动部署更适合有技术背景的用户。作者建议在预算允许的情况下使用ACK,因为它能提供高效、便捷的管理体验。同时,文章也提出了对文档改进的建议,如添加更多技术细节和解释,以帮助用户更好地理解和实施解决方案。最后,展望了ACK未来在智能化、安全性与边缘计算等方面的潜在发展。水文一篇,太忙了,见谅!
|
7月前
|
运维 负载均衡 Cloud Native
Serverless 应用引擎产品使用之在Serverless 应用引擎中,使用云原生网关的情况下,SLB(负载均衡器)和证书配置如何解决
阿里云Serverless 应用引擎(SAE)提供了完整的微服务应用生命周期管理能力,包括应用部署、服务治理、开发运维、资源管理等功能,并通过扩展功能支持多环境管理、API Gateway、事件驱动等高级应用场景,帮助企业快速构建、部署、运维和扩展微服务架构,实现Serverless化的应用部署与运维模式。以下是对SAE产品使用合集的概述,包括应用管理、服务治理、开发运维、资源管理等方面。
|
运维 负载均衡 Kubernetes
云原生时代,如何从 0 到 1 构建 K8s 容器平台的 LB(Nginx)负载均衡体系
通过本文可以对 Kubernetes 容器平台的 LB(Nginx)负载均衡了然于心,并且可以快速深入建设 Kubernetes LB(Nginx)负载均衡体系。还可以了解到,一个中大型公司,是如何从 0 到 1 来构建大规模 Kubernetes 容器平台的 LB(Nginx)负载均衡体系的一些非常宝贵的实战经验。
云原生时代,如何从 0 到 1 构建 K8s 容器平台的 LB(Nginx)负载均衡体系
|
JSON 负载均衡 Cloud Native
【云原生】springcloud08——Ribbon负载均衡调用
【云原生】springcloud08——Ribbon负载均衡调用
|
负载均衡 Kubernetes Cloud Native
【云原生Kubernetes系列项目实战第一篇】k8s集群+高可用负载均衡层+防火墙( 提及年少一词,应与平庸相斥)(三)
【云原生Kubernetes系列项目实战第一篇】k8s集群+高可用负载均衡层+防火墙( 提及年少一词,应与平庸相斥)(三)
241 0
【云原生Kubernetes系列项目实战第一篇】k8s集群+高可用负载均衡层+防火墙( 提及年少一词,应与平庸相斥)(三)
|
存储 Kubernetes 负载均衡
【云原生Kubernetes系列项目实战第一篇】k8s集群+高可用负载均衡层+防火墙( 提及年少一词,应与平庸相斥)(二)
【云原生Kubernetes系列项目实战第一篇】k8s集群+高可用负载均衡层+防火墙( 提及年少一词,应与平庸相斥)(二)
216 0
【云原生Kubernetes系列项目实战第一篇】k8s集群+高可用负载均衡层+防火墙( 提及年少一词,应与平庸相斥)(二)
|
Kubernetes 负载均衡 Cloud Native
【云原生Kubernetes系列项目实战第一篇】k8s集群+高可用负载均衡层+防火墙( 提及年少一词,应与平庸相斥)(一)
【云原生Kubernetes系列项目实战第一篇】k8s集群+高可用负载均衡层+防火墙( 提及年少一词,应与平庸相斥)(一)
331 0
【云原生Kubernetes系列项目实战第一篇】k8s集群+高可用负载均衡层+防火墙( 提及年少一词,应与平庸相斥)(一)
|
存储 负载均衡 Cloud Native
【云原生&微服务八】Ribbon负载均衡策略之WeightedResponseTimeRule源码剖析(响应时间加权)
【云原生&微服务八】Ribbon负载均衡策略之WeightedResponseTimeRule源码剖析(响应时间加权)
293 0
【云原生&微服务八】Ribbon负载均衡策略之WeightedResponseTimeRule源码剖析(响应时间加权)