负载平衡器（Load Balancer）是什么？
通常一个大型的资料中心里面，每秒可能会有上百万甚至是上千万来自其他伺服器或是用户端的请求。为了有效地处理这些流量，我们势必需要针对这些流量进行管理以及平衡，而负载平衡器就是这样的模组，专门用来处理这种大流量的问题！
负载平衡器主要是将所有用户端的请求，根据当前伺服器负载的情况，进行分配到对应的伺服器。这样的好处是避免伺服器过载或是崩溃。不过这边也可以思考一下，如果当前系统的流量不高，大约只有每秒几千个请求，则可能不太需要负载平衡器，毕竟一个系统越复杂，则需要考虑的事情越多。
负载平衡器特性
如果负载平衡器是专门处理大流量的元件，那负载平衡器应该需要有哪些特性呢？
可扩展性（Scalability）
根据 现代系统设计入门 - 系统设计 01 有提到，一个良好的系统必须要考虑到可扩展性，因为系统用庞大需要的伺服器或是元件则越多。负载平衡器则有这样的特性，本身是一个可以扩大或是缩小的元件，因此可以根据当前系统的系统去做扩展。
可用性（Availability）
所谓的可用性指的是，如果系统某些伺服器当机时，整个系统不会因此停止运作。负载平衡器则可以有效地处理这类型的问题，因为负载平衡器可以判断哪些伺服器过载或是当机，而将流量导流至正常运作的伺服器，进而避免系统故障甚至停止营运。
效能（Performance）
对于负载平衡器来说，有一项非常重要的任务就是确保每一台伺服器是平均分配的，基本上来说不会有特定伺服器流量过高的问题。这样的特性，可以确保用户端可以获得更快的回应时间。
负载平衡器如何运作？
先来看看如果没有负载平衡器的话，伺服器是如何运作
如同前面所提到的，如果没有负载平衡器，会导致流量流向特定伺服器，用户端会因此延迟。
相反的，如果中间放置负载平衡器，则可以有效的平衡流量至对应的伺服器
AWS 负载平衡器解说
这边提供先AWS 的原理图来做讲解，并且附上出处与来源！
以下是AWS 原文翻译后的文字：
公司通常将其应用程式运行在多个伺服器上。这种伺服器布置称为伺服器集区。用户对应用程式的请求首先转到负载平衡器。然后，负载平衡器将每个请求路由到伺服器丛集中最适合处理该请求的单一伺服器。
负载平衡就像餐厅经理所做的工作。考虑一家有五名服务员的餐厅如果允许顾客选择服务员，那么一两个服务员可能会超负荷工作，而其他服务员却闲着。为了避免这种情况，餐厅经理将顾客分配给最适合为他们服务的特定服务员。
负载平衡器运作原理
负载平衡是由负载平衡器来去做处理的，因此可以分成两个部分，第一个是负载平衡器这个工具，第二个则是负载平衡这件事情。
负载平衡器（Load balancer）
首先是负载平衡器可以是硬体也可以是软体。如果是硬体的负载平衡器需要安装专用的负载平衡设备，而如果是软体的负载平衡器，则可以在伺服器、虚拟机器、云端上运作。曾经在 系统设计元件介绍Building Block – 系统设计05 有提到的内容传递网路（CDN） 也通常会有负载平衡的功能，未来也会花一篇文章的篇幅，好好的讲解CDN。
负载平衡演算法（Load balancing algorithms）
当用户发送请求时，负载平衡器会将请求透过不同的演算法，来决定哪个伺服器来处理请求。这些演算法可以分成两大类：静态负载平衡演算法以及动态负载平衡演算法
静态负载平衡演算法（Static load balancing algorithms）
静态负载平衡演算法，是根据平均演算法来去做负载平衡，不会考虑当前系统的状态。白话来说，静态负载平衡不会知道伺服器的状态，也无法根据伺服器过载、闲置来决定是否导入流量。而是透过最一开始根据的计画来去分配负载。这样的好处是非常好设定以及理解负载平衡，当然坏处是会导致效率低下。
其中常见的静态负载平衡为轮流法（Round Robin, RR），这个演算法其实在作业系统、CPU 排程中相当常见，顾名思义就是根据时间量的长短，轮流的执行对应的任务。为了更深入讲解Round Robin 演算法，这边也提供维基百科的范例。
在时间片长度为100毫秒的系统中，考虑下表所列举的进程：
动态负载平衡演算法（Dynamic load balancing algorithms）
动态负载平衡演算法会考虑每一台伺服器当前状态，包含：可用性、工作负载情况、伺服器运作情况。
并且会将流量从负担过重或效能不佳的伺服器，转移到尚未满载的伺服器之中，这样的优点是平均分配流量更加高效。不过缺点则是动态负载平衡是很难达到的，许多不同的因素都会影响到伺服器的可用性，例如：伺服器运作的情况、伺服器的记忆体容量、用户端请求的规模。
这边也提供几个常见的动态平衡演算法给各位读者，包含最少连线（Least Connection）、加权最少连线（Weighted Least Connection）、资源负载平衡（Resource-Based Load Balancing）、地理位置负载平衡（Geolocation-based Load Balancing）
全域端和本地负载平衡
前面有提到负载平衡器是什么以及负载平衡器的运作原理，接下来讲讲负载平衡器的种类，基本上可以分成全域负载平衡器（Global Server Load Balancing） 以及本地负载平衡器（Local Load Balancing ）。如果单纯从字面上的意思，也不难看出，全域负责的范围是跨多了地理位置的流量平衡，本地负载平衡则是负责一个大型资料中心的流量平衡。
全域伺服器负载平衡（Global Server Load Balancing）
全域伺服器负载平衡最主要的工作就是将全球的流量，平衡分散至不同的大型资料中心。例如：美国用户的流量，透过GSLB 来将流量分散至北美的资料中心。全域伺服器负载平衡可以根据使用者当前的地理位置、不同资料中心的状态来去决定将流量导流至哪一个地理位置的资料中心。
这边提供另一个例子：如果使用者在东京，并且他们正在使用伺服器位于纽约的Web 服务，则请求和回应都必须传输很长的距离，这会导致载入时间明显延迟。
使用GSLB，全球伺服器集区可确保每个使用者都可以连接到地理位置靠近他们的伺服器，从而最大限度地减少跃点和传输时间。这边的例子中，如果总部位于纽约的公司正在使用GSLB，东京使用者可以连接到距离其位置较近伺服器，从而获得更快速的使用者体验。
GSLB 之于DNS
前一篇文章 DNS 是什么？网域名称系统介绍– 系统设计06 深入讲解了DNS，不过实际上里面的运作方式与负载平衡的概念是相关连的。 DNS 重新排序IP 位址清单以回应每个DNS 查询，不同的使用者也会得到IP 位置清单。使用者也会发送请求至不同的伺服器来处理他们的请求，因此DNS 也是透过全域伺服器负载平衡来去将请求流量，分配至不同的资料中心。
本地负载平衡（Local Load Balancing）
本地负载平衡则是一个限制在资料中心内部的负载平衡，范围仅限于一个资料中心内部。不过本质上与负载平衡器一样，都是将流量透过不同的演算法来去分配至对应的伺服器。
负载平衡器的实现
最一开始的介绍提到负载平衡器可以简单分成硬体、软体、云端负载平衡器，以下则是三者的实现方式介绍：
硬体负载平衡器
负载平衡器在30 年前就已经存在了，最一开始也是由硬体来去实作出负载平衡器。当然在早期年代，要用硬体时做出负载平衡器是非常昂贵的，不过好处是可以处理当时流量的使用者需求。不过到了现代，硬体负载平衡器不一定是企业的首选，主要缺点是硬体负载平衡器非常依赖于硬体，需要较高的维护、运营成本，并且还需要处理硬体相容性问题。
软体负载平衡器
软体负载平衡器则相较于硬体，多了几个特性：高灵活性、可程式性、成本便宜。软体负载平衡器也因为有高度扩展性，可以随着系统规模越大而快速地进行设置，越来越受企业欢迎。
云端负载平衡器
当然除了软体以外，随着三大云服务商的出现，现在负载平衡器也可以使用云端服务。其中负载平衡器及服务（LBaaS）也是在这时候出现的。当然如果对于其他的专有名词，IaaS、PaaS、SaaS 有兴趣的读者，可以观看这一篇 从Zeabur 来讲解IaaS & PaaS & SaaS 是什么？云端服务模型介绍！。
云端负载平衡器最大的好处是，使用者可以根据当前使用量与云端提供商付费。并且相较于硬体、软体的技术门槛，云端负载平衡器是相对门槛低的。因此当前云端负载平衡器是满多企业的主要选择之一。
结论
负载平衡器是系统设计中，重要的概念之一，并且也是大型系统必不可少的工具。除了可以提高系统效能以外，更可以确保系统不至于因为短时间的高流量，导致系统崩溃。
如果对于其他系统设计有兴趣的读者，也不妨观看其他系统设计的文章，也非常欢迎留言交流！
相关文章
系统设计元件介绍Building Block – 系统设计05
Back-of-the-envelope 封底计算– 系统设计04
引用
CLOUD FLARE – What is load balancing? | How load balancers work
简体中文 
繁體中文 
English 
한국어 
日本語 
Español