面对大量用户访问、高并发请求，海量数据，可以使用高性能的服务器、大型数据库，存储设备，高性能Web服务器，采用高效率的编程语言比如(Go,Scala)等，当单机容量达到极限时，我们需要考虑业务拆分和分布式部署，来解决大型网站访问量大，并发量高，海量数据的问题。

从单机网站到分布式网站，很重要的区别是业务拆分和分布式部署，将应用拆分后，部署到不同的机器上，实现大规模分布式系统。分布式和业务拆分解决了，从集中到分布的问题，但是每个部署的独立业务还存在单点的问题和访问统一入口问题，为解决单点故障，我们可以采取冗余的方式。将相同的应用部署到多台机器上。解决访问统一入口问题，我们可以在集群前面增加负载均衡设备，实现流量分发。

负载均衡（Load Balance），意思是将负载（工作任务，访问请求）进行平衡、分摊到多个操作单元（服务器，组件）上进行执行。是解决高性能，单点故障（高可用），扩展性（水平伸缩）的终极解决方案。

下面是介绍搭建（有一定规模的）线上服务会用到的load balancer的科普文章。我将它翻译一下， 因为水平有限， 文中不免有错误， 如果发现可以后台

或留言告诉我。

这篇文章将会介绍 Facebook 如何处理数十亿个请求并保持高可用性的一个方面：负载均衡。

什么是负载均衡

负载均衡器是将用户的请求分配到许多资源（通常是计算机）的设备。 它们通常目的用于增加并发和可靠性。

为了以一般的方式谈论负载平衡，关于网站的服务，我做下面两个假设：

• 我可以根据需要启动多个实例

• 用户的任何请求都可以访问任何服务

第一个假设意味着服务是无状态的（或者像Redis集群中的共享状态）。 第二个假设在实践中是不必要的（因为有粘性负载平衡这类考虑：同一个客户端的请求往往含有相同的上下文数据，为了减少与服务器的交流成本，负载均衡通常把来自相同客户端的请求分配给同一个服务器），但是为了简单起见，先这样假设了。
以下是我要讨论的负载平衡技术：

1. 第七层（笔者注：应用层）负载均衡（HTTP，HTTPS，WS）

2. 第四层（笔者注：传输层）负载均衡（TCP，UDP）

3. 第三层（笔者注：网络层）负载均衡

4. DNS负载均衡

5. 手动负载均衡多个子域

6. Anycast

最后还有一些其它话题：

• 延迟和吞吐量

• 后台服务器直接响应用户

这些技术都被笼统地定义为网站想要承担更多流量的“步骤”。 例如，第7层负载均衡是首先要做的事情（比 Anycast 早得多）。 前三种技术有助于增加吞吐量和可用性，但仍然存在单点故障。 剩下的三种技术消除了单点故障问题的同时也提高了服务的吞吐量。

为了帮助我们了解负载均衡，我们先看一下我们想要扩展的简单服务。注意：每种技术都可以和商店购买商品的非技术类比。 这些类比是技术背后的想法的简化表示，可能不完全准确。

服务

我们先看一个简单网站服务。 它可能看起来像这样：

这个系统将无法处理大量的流量，如果服务异常挂掉，整个应用程序都会异常。

类比：

1. 你去商店里唯一收银柜台

2. 结算

• 如果那里没有收银员，就不能进行购买

第七层负载均衡

开始处理更多流量的第一种技术是使用第7层负载平衡。 第7层是应用层。 这包括 HTTP，HTTPS 和 WebSockets。 Nginx 是一个非常受欢迎的并且经过大量测试的第7层负载均衡应用。 让我们看看这将如何扩大我们网站规模：

请注意，我们实际上可以使用此技术在数十或数百个服务上进行负载均衡。 只是上图只是显示两个服务。

类比：

• 商店的员工将您带到特定的收银台

• 结算

工具：

• Nginx

• HAProxy

第4层负载均衡

上面第七层的技术将帮助我们处理大量流量，但是如果我们需要处理更多的流量，第4层负载平衡可能会帮到我们。 第4层是传输层。 它包括 TCP 和 UDP 协议。 目前一些受欢迎的第4层负载均衡应用是 HAProxy（可以进行第7层负载均衡）和 IPVS。

我们来看下图：

在大多数情况下，第7层负载均衡 + 第4层负载均衡应该能够处理足够多的流量。 但是，我们仍然需要担心可用性。 这里的单点故障可能发生在第4层负载均衡节点上。 我们将在下面的 DNS 负载均衡部分解决这个问题。

类比：

1. 根据会员号码，为人们提供单独的结帐区域， VIP 一个区域，非 VIP 另一个区域。

2. 一旦您到达正确的结帐区域，商店的员工将指导您到特定的收银台

3. 结算

工具:

• HAProxy

• IPVS

第三层负载均衡

如果我们需要负担更大的请求，我们可能要添加第3层负载均衡。 这比前两种技术更复杂。 第三层是网络层，包括 IPv4 和 IPv6 协议。 以下是第3层负载均衡的示意图：

为了了解如何工作，我们首先需要一个ECMP（相同的成本多路径路由）背景。 通常在同一目的地有多条相同的路径时使用 ECMP。 它允许路由器或交换机通过不同的链路将数据包发送到目的地（允许更高的吞吐量），使用非常广泛地，。

我们可以利用这一点做L3负载均衡，因为从我们的角度来看，它和每个L4负载均衡节点都是一样的。 这意味着我们可以将L3负载均衡节点和L4负载均衡节点之间的每个链路作为同一目的地的路径。 如果我们给所有这些负载均衡节点提供相同的 IP地址，我们可以使用 ECMP 将所有的L4负载均衡节点中的流量分开。

类比：

1. 在街对面有两个独立的相同商店。 你去的哪个取决于你

2. 一旦您到达正确的商店，根据会员号码，可以为个人提供单独的结帐区域

3. 一旦您到达正确的结帐区域，商店的员工将指导您到特定的收银台

4. 结算

工具：

• 通常使用机架顶部开关的硬件完成

TL; DR：

• 除非您大规模运行或拥有自己的硬件，否则您不需要这样做

DNS负载平衡

DNS 是将域名转换为IP地址的系统。 例如，它可能会将 example.com 解析为 93.184.216.34。 它还可以返回多个IP地址，如下所示：

如果返回多个 IP，客户端通常使用第一个IP（但是，一些实现只会查看第一个返回的 IP）。

有许多 DNS 负载均衡技术，包括 GeoDNS 和 round-robin。 GeoDNS 根据谁的请求返回不同的 IP。 这样我们可以将客户端路由到最接近它们的服务器或数据中心。round-robin 返回每个请求的不同 IP，循环遍历所有可用的IP地址。 如果有多个IP可用，这两种技术只是改变响应中 IP 的顺序。

下面是这种技术的示意图：

在此示例中，不同的用户正在路由到不同的群集（随机地或基于他们的位置）。

现在没有单一的故障点（假设有多个DNS服务器）。 为了更加可靠，我们可以在不同的数据中心运行多个集群。

类比 ：

1. 您在网上查询购物中心。一般首先放置最近的购物中心。 您可以查看每一次，并打开列表中的第一个。

2. 在街对面有两个独立的相同类型商店。 你去的哪个取决于你自己

3. 一旦您到达正确的商店，根据会员号码，可以为个人提供单独的结帐区域

4. 一旦您到达正确的结帐区域，商店的员工将指导您到特定的收银台

5. 结算

手动负载均衡/路由

如果我们的内容在许多服务器或数据中心上被分割，并且我们需要路由到特定的内容，这种技术可能是有帮助的， 比如，cat.jpg 存储在伦敦的一个集群中，而不是任何其他的集群。同样，我们假设dog.jpg 存储在 NYC 中，但不存储在任何其他数据中心或集群中。例如，当内容刚刚上传并且尚未被数据中心复制时，可能会发生这种情况。

但是，为了访问内容，用户不必等待复制完成。这意味着我们的应用程序将需要临时将所有的 cat.jpg 请求引导到伦敦，并将所有请求的 dog.jpg 发送到 NYC。所以我们要使用 https://lon-1e.static.example.net/cat.jpg 来代替 https://cdn.example.net/cat.jpg。同样的访问 dog.jpg 也类似。

为此，我们需要为每个数据中心（最好是每个集群和每个机器）设置子域。除了上面的 DNS 负载平衡之外，还可以做到这一点。

注意：我们的应用程序需要跟踪用户的位置。

类比：

1. 您打电话给公司办公室询问哪些地点携带猫食。

2. 您在网上查询购物中心。一般首先放置最近的购物中心。 您可以查看每一次，并打开列表中的第一个。

3. 在街对面有两个独立的相同类型商店。 你去的哪个取决于你自己

4. 一旦您到达正确的商店，根据会员号码，可以为个人提供单独的结帐区域

5. 一旦您到达正确的结帐区域，商店的员工将指导您到特定的收银台

6. 结算

   Anycast

   它是这篇文章最后介绍的技术。 先介绍一下背景：

   大多数互联网使用单播。 这本质上意味着每台计算机都能获得唯一的IP地址。 还有一种称为 Anycast 的方法。 使用 Anycast 技术，多台机器可以拥有相同的IP地址，并且路由器将请求发送到最近的一个机器上。 我们可以将其与上述技术相结合，拥有一个非常可靠和可用的系统，可以处理大量流量。

Anycast 基本上允许互联网处理我们的部分负载均衡。

类比：

1. 你询问路人你附近的商店，他们告诉离你最近商店的位置

1. 在街对面有两个独立的相同类型商店。 你去的哪个取决于你自己

2. 一旦您到达正确的商店，根据会员号码，可以为个人提供单独的结帐区域

3. 一旦您到达正确的结帐区域，商店的员工将指导您到特定的收银台

4. 结算

其它

延迟和吞吐量

除此之外，这些技术还可以提高低延迟服务的吞吐量。 而不是试图使服务本身处理更多流量，而是添加更多的流量。 这样我们将有一个低延迟，高吞吐量的系统。

后台服务器直接响应用户（Direct server return）

在传统的负载均衡系统中，请求遍历所有层次的负载均衡设备，响应也通过所有这些层返回。 

而后台服务器直接返回（DSR）是不对称负载分布的一项功能，在不对称负载分布中请求和回应通过不同的网络路径。 如果服务的响应很大，这是非常有用的工具。

原文大家可以点击下面的“原文链接”。

每周至少一篇关于践行的思考，请帮我转发给你身边对此有兴趣的朋友。
点击“原文链接”，可查看我原创的所有践行以及思考类文章，关注后可随时查看。

更多精彩内容请关注：