负载均衡(Load Balancing)
调度后方多台机器通过统一接口对外提供服务。负责此职责的技术组件称为“负载平衡”。
互联网时代初期，网站流量比较小，业务也比较简单。一台服务器就可能满足访问需求。然而如今，互联网应用和企业级应用普遍用于生产。几乎所有的系统都离不开集群部署。无论信息系统采用单架构多副本部署还是微服务架构，无论是实现高可用性还是获得高性能，都需要利用多台机器来扩展服务能力。希望用户请求无论连接到哪台机器上都会被连接到。都得到同样的待遇。另一方面，如何构建和调度服务集群对于用户侧必须足够透明。即使背后有一千、万台机器共同响应请求，也绝对不是用户关心的事情。用户只需记住一个域名地址即可。在后台调度多台机器通过统一的接口对外提供服务。负责此操作的技术组件称为“负载平衡”。
真正大型系统的负载平衡过程通常是多级的。例如，一个在各地有多个机房的大型互联网网站，或者有不同网络链接入口的机房，会从DNS解析开始，经过“域名”“CNAME”“负载调度服务”“最近的数据” “中心入口”路径，首先根据IP地址（或其他条件）将访问用户分配到合适的数据中心，然后再去进行后面将要讨论的各种负载均衡，DNS层面的负载均衡工作原理类似。前面介绍的DNS智能线路、内容分发网络等，不同的是，数据中心不仅可以提供缓存，还可以提供全方位的服务能力，后面我们要讨论的“负载均衡”只关注其他层面的负载。网络请求进入数据中心入口后进行均衡。
无论网关内部建立多少级负载均衡，从形式上都可以分为两种：四层负载均衡和七层负载均衡。在详细介绍它们是什么以及它们如何工作之前，让我们先建立两个一般性的概念印象。
四层负载均衡的优点是性能高，七层负载均衡的优点是功能强。在做多级混合负载均衡时，通常应该先做低级负载均衡，最后做高层负载均衡（想想为什么？）。我们所说的“四层”、“七层”是指经典OSI七层模型中的第四传输层和第七应用层。表4-1来自维基百科对OSI七层的描述。模型的介绍（作者做了简单的中文翻译），这部分属于网络的基础知识，所以这里不再做进一步的解释。稍后我们会多次使用这个表。如果您对网络知识不是特别熟悉，可以通过维基百科获取更多信息。
表4-1 OSI七层模型
数据链路层负载均衡
请参阅上面的OSI 模型表。数据链路层传输的内容是数据帧（Frame），比如常见的以太网帧、ADSL宽带PPP帧等。在我们讨论的具体上下文中，目标一定是以太网帧。根据IEEE 802.3标准，最典型的1500字节MTU的以太网帧结构如表4-2所示。
表4-2 最典型的1500 Bytes MTU以太网帧结构说明
本节中可以暂时忽略帧结构中其他数据项的含义。只需关注“MAC目的地址”和“MAC源地址”两项即可。我们知道每个网卡都有一个独立的MAC地址。以太网帧上的这两个地址告诉交换机该网卡的哪个端口连接到交换机以及该帧应该发送到哪个网卡。
图4-8 数据链路层负载均衡
虽然数据链路层负载均衡非常高效，但它并不适合所有情况，除了那些需要感知应用层协议信息的负载均衡场景（所有四层负载均衡器都无法胜任，稍后会进行解释）后面介绍七层均衡器时），这也受到网络侧很大的限制。二层负载均衡器直接重写目标MAC地址的工作原理决定了它与真实服务器的通信必须是二层可达的。通俗地说，就是必须在同一个子网，不能跨VLAN。优点（效率高）和缺点（不能跨子网）共同决定了数据链路层负载均衡最适合用作数据中心的一级均衡设备，连接其他下级负载均衡器。
网络层负载均衡
根据OSI七层模型，第三网络层传输的单元是分组数据包（Packets），它是在分组交换网络（PSN）中传输的结构化数据单元。以IP协议为例，一个IP数据包由两部分组成：Headers和Payload。 Headers 的最大长度为60 Bytes，其中包括20 Bytes 固定数据和最多40 Bytes 的可选附加设置。根据IPv4标准，典型报文的报头部分的结构如表4-3所示。
表4-3 packet包的Header部分说明
图4-9 IP隧道模式负载分担
图4-10 NAT模式负载均衡
当流量压力较大时，NAT模式的负载均衡会带来较大的性能损失，甚至比直接路由和IP隧道模式下降一个数量级。这是显而易见的。负载均衡器代表整个服务集群进行响应。每个服务器的响应数据都会相互竞争平衡器的出口带宽。这就像在家里使用NAT访问互联网一样。如果有人在下载，你的游戏可能会感觉卡住，整个系统的瓶颈很容易出现在负载均衡器上。
应用层负载均衡
“代理”一词按照“哪一方能够感知”的原则可以分为“正向代理”、“反向代理”和“透明代理”三类。正向代理就是我们通常所说的简称代理。是指在客户端设置的代理服务，代表客户端与服务器之间的通信。它对客户端是可知的，对服务器是透明的。反向代理是指设置在服务器端，代表真实服务器与客户端进行通信的代理服务。这时候对于客户端来说是透明的。透明代理是指对双方透明的、配置在网络中间设备上的代理服务，例如安装在路由器上的透明旁路代理。
相信大家对于代理人的工作模式都应该比较熟悉。我这里就不展开了。我简单列出七层代理可以实现的一些功能，以便读者可以直观地感受到它的“强大功能”。
CDN能做的所有缓存工作（即除了CDN根据物理位置返回优化链接的工作外），七层均衡器都可以实现，如静态资源缓存、协议升级、安全防护、访问等控制。七层均衡器，让路由更智能。例如，采用基于Session的路由来实现亲和力聚类；实现基于URL的路由，实现专门的服务（这个相当于网关的职责）；甚至实现基于用户身份的路由，实现对某些用户的特殊服务（如某些站点的VIP服务器）等。在很多微服务架构系统中，需要在第七层进行链路管理措施，例如服务降级、断路器、异常注入等。例如，只有当某个服务器出现物理或系统级故障导致无法响应TCP 请求时，才会被四层均衡器感知并从服务集群中移除。如果一个服务器能够响应但是一直报500错误，那么四层均衡器就完全无能为力了，只能通过七层均衡器来解决。
均衡策略与实现
加权轮询：根据服务器处理能力的不同，为每个服务器分配不同的权重，使其能够接受相应权重的服务请求。例如：服务器A的权重设计为1，B的权重为3，C的权重为6，那么服务器A、B、C将获得10%、30%、60%的服务分别请求。这种平衡算法可确保高性能服务器获得更多利用率，并防止低性能服务器过载。随机平衡（Random）：将客户端的请求随机分布到多个内部服务器上，在数据足够大的场景下实现相对均衡的分布。加权随机平衡（Weighted Random）：这种平衡算法与加权轮询算法类似，但在分配处理请求时是一个随机选择的过程。一致性哈希：根据请求中的某些数据（可以是MAC、IP地址，或者上层协议中的一些参数信息）计算出需要落到的节点作为特征值，算法一般保证相同特征值每次都会落在同一个服务器上。一致性是指保证当服务集群中的某个真实服务器发生故障时，只影响该服务器的哈希，不会导致整个服务集群的哈希键值重新分布。响应速度均衡（Response Time）：负载均衡设备向各个内部服务器发出检测请求（如Ping），然后根据各个内部服务器对客户端的服务请求的最快响应时间来决定由哪台服务器响应客户端的服务请求。检测请求。这种均衡算法可以更好地反映服务器当前的运行状态，但最快响应时间仅指负载均衡设备与服务器之间的最快响应时间，而不是客户端与服务器之间的最快响应时间。最少连接平衡：每个客户端请求服务在服务器上停留的时间可能相差很大。随着工作时间的增加，如果采用简单的轮询或随机平衡算法，每台服务器所花费的时间和连接过程可能会产生巨大的不平衡，并不能实现真正的负载平衡。最小连接数平衡算法内部对每个需要加载的服务器都有一条数据记录，记录了服务器当前正在处理的连接数。当有新的服务连接请求时，当前请求将被分配给连接数最少的服务器。服务器使得平衡更加符合实际情况，负载更加均衡。这种平衡策略适用于长处理请求服务，例如FTP传输。
……在硬件均衡器方面，往往直接使用专用集成电路（ASIC）来实现，并有专用处理芯片的支持，以避免操作系统层面的损耗，实现最高性能。这类的代表是著名的F5、A10公司的负载均衡产品。
文章分享结束，深度解析负载均衡和的答案你都知道了吗？欢迎再次光临本站哦！
本文采摘于网络，不代表本站立场，转载联系作者并注明出处：https://www.iotsj.com//kuaixun/6846.html
用户评论
感觉这篇文章很有深度，负载均衡虽然很重要，但很多人都只是了解表面，没有真正理解它的运作机制。
有18位网友表示赞同！
之前学习过负载均衡，但还是经常在实战中遇到新的问题，期待看看文章能带给我哪些启发。
有18位网友表示赞同！
做开发的确实需要深入了解负载均衡原理，不然很容易在系统设计阶段踩坑呢！
有16位网友表示赞同！
最近公司打算进行技术升级，负载均衡可能会用到，希望能通过这篇文章了解更多知识，为部署做好准备去。
有17位网友表示赞同！
作为一名后端工程师，负载均衡是必修课，期待学习最新的负载均衡方案和实践经验。
有10位网友表示赞同！
很多时候负载均衡的策略需要根据实际情况进行调整，这篇文章或许能提供一些新的思路。
有12位网友表示赞同！
负载均衡是一个很重要的概念，希望文章可以详细讲解它的优缺点，以及不同类型的负载均衡模型的特点。
有14位网友表示赞同！
我个人对硬件负载均衡不太了解，希望能从这篇文章中学习到更多。
有11位网友表示赞同！
感觉负载均衡的应用场景非常广泛，无论是传统的网站架构还是微服务架构都需要用到它。
有6位网友表示赞同！
这篇文章标题很有吸引力，我想知道“老生常谈”和负载均衡之间还有什么值得探讨的？
有17位网友表示赞同！
我之前对负载均衡了解并不多，希望能通过这篇文章快速入门，了解它的核心概念。
有9位网友表示赞同！
希望这篇文章能结合案例说明，更容易理解复杂的负载均衡技术。
有9位网友表示赞同！
文章题目感觉很新鲜，期待作者能够提出一些新的观点和思考，打破传统的认知模式。
有7位网友表示赞同！
我很想学习如何根据具体的业务场景进行合适的负载均衡策略选择。
有11位网友表示赞同！
这篇文章能否提供一些常见的负载均衡工具的介绍和比较？
有16位网友表示赞同！
负载均衡技术发展很快，希望这篇文章能够分享最新的趋势和应用案例。
有19位网友表示赞同！
希望能从这篇文章中学到一些实战经验，解决实际工程中遇到的问题。
有8位网友表示赞同！
优秀的系统设计离不开合理的负载均衡策略，期待这篇深入的分析能给我带来帮助！
有9位网友表示赞同！