微信号:infoqchina

介绍:有内容的技术社区媒体

负载均衡常用手段解析

2018-12-01 10:17 Key先森 译
作者 | Laura Nolan,Murali Suriar
译者 | Key 先森
包括 CDN(内容交付网络)和云提供商在内,多站点的大型互联网系统可以选择多种方式来均衡进入其网络的流量。在本文中,我们将描述常见的流量均衡设计,包括技术和权衡手段。

如果你是早期的云计算服务提供商,你可以使用一个单独的客户 web 服务器,为它分配一个 IP 地址,并配置一个 DNS(域名系统)记录来将它与一个易读的名字关联起来,之后通过 BGP(边界网关协议)来传播 IP 地址,这是种在网络间交换路由信息的标准方式。

在冗余的网络路径上分发流量,在不可用的基础设施周围进行路由来提高可用性(会导致不对称路由等现象),这些从本质上讲并不是负载均衡。

简单的 DNS 负载均衡

随着客户服务流量的增长,业务方希望获得更高的可用性。你添加了另一个具有公网 IP 地址的 web 服务器,并更新了 DNS 记录来将用户引导到这两个 web 服务器(希望稍微公平一些)。直到某一个 web 服务器意外宕机前,这种方法都是可行的。假设你快速检测到故障,可以通过更新 DNS 配置(手动方式或使用软件)来停止引用损坏的服务器。

遗憾的是,由于 DNS 记录是有缓存的,这些缓存记录可能会在客户端或者 DNS 层次结构中的其他名称服务器中,在它们过期之前,大约有 50% 的请求仍然可能失败。DNS 记录的 TTL(time to live,生存时间)通常为几分钟或更长,因此这会对系统的可用性造成重大影响。

更糟糕的是一些客户端完全忽略了 TTL,所以一些请求将在一段时间内被定向到已经宕机的 web 服务器上。设置非常短的 DNS TTL 也不是什么好主意;这意味着 DNS 服务的负载增加,延迟增加,因为客户端不得不更加频繁地执行 DNS 查找。如果你的 DNS 服务不可用,那么使用更短的 TTL 访问服务将更快地降级,因为缓存服务 IP 地址的客户端更少。

增加网络负载均衡

为了解决这个问题,你可以添加一对冗余的 4 层(Layer 4)网络均衡器,并在相同的虚拟 IP(VIP)地址提供服务。它们可以是硬件设备,或者像 HAProxy 这样的软件均衡器。这意味着 DNS 记录仅仅指向虚拟 IP 而不再做负载均衡。

4 层负载均衡器将来自用户的连接均衡分布在两个 web 服务器上

4 层均衡器将来自因特网的流量均衡地引导至后端服务器。这通常是基于每个 IP 包的 5 元组的哈希(一个数学函数)完成的:源 IP 地址和目标 IP 地址,以及端口加上协议(如 TCP 或 UDP)。这种方式快速、高效(并且仍然维持了 TCP 的基本属性),并且不需要均衡器维护每个连接的状态。

4 层均衡器可以进行健康检查,并仅仅向那些通过检查的 web 服务器发送流量。与 DNS 均衡不同的是,如果一个 web 服务器崩溃,将流量重定向到另一个 web 服务器上的延迟很小,尽管现有连接将被重置。

4 层均衡器可以做加权平均,处理不同容量的后端,它为运维人员提供了强大的能力和灵活性,同时在计算能力方面相对便宜。

走向多站点

系统继续扩张。即使你的数据中心出现故障,你的客户也希望能继续保持运转。你会构建一个新的数据中心,其中包含自己的一组后端服务和另一组 4 层均衡器,它们在与之前一样的虚拟 IP 上提供服务。DNS 设置不变。这两个站点的边缘路由器都在传播地址信息,包括服务的虚拟 IP。根据终端用户和系统之间的网络连接情况,以及它们的路由策略配置,发送到虚拟 IP 的请求可以到达任一个站点。这被称为 anycast(任播)。大多数情况下,这种方法都很有效。如果其中一个站点出现故障,你可以停止通过 BGP 传播服务虚拟 IP,这样流量就可以迅速转移到另一个站点。

使用 anycast(任播)从多个站点提供服务

这个设置有几个问题。最糟糕的是,你无法控制流量的走向或者限制发送到某个特定站点的流量。通常,决定路由的网络协议和配置应该将用户路由到最近的站点,不过就网络延迟而言,你并没有明显的方法来实现这个目标。

在多站点系统中控制入站请求

为了维持稳定性,你需要控制每个站点的流量,你可以为每个站点分配不同的虚拟 IP,并使用 DNS 的简单循环或加权 循环 来均衡流量。

从多个站点提供服务:每个站点使用一个主虚拟 IP,二级站点备份,使用地理感知 DNS

现在产生了两个新的问题。

首先,使用 DNS 均衡意味着你有缓存记录,这不太适用于那些需要迅速重定向流量的场景。

第二,每当用户做一次新的 DNS 查询,虚拟 IP 会将用户连接到一个随机的站点,而不一定是离用户最近的那一个。如果你的服务站点分布广泛,根据用户和服务站点之间的网络延迟,各个用户感知到的系统响应性能会有较大波动。

让每个站点不断传播虚拟 IP,并为所有其他站点(以及任何有问题的站点的虚拟 IP)提供服务,你可以通过这种方式解决第一个问题。一些网络技巧(比如从备份中传播不那么特殊的路由信息)可以确保虚拟 IP 对应的主站只要是可用的,那么它便是首选。这是通过 BGP 完成的,因此在更新 BGP 后的一到两分钟内,我们应该会看到流量的移动。

除了让距离用户最近的健康站点为其提供服务以外,并没有一个更加优雅的选择。很多大型互联网服务尝试使用 DNS 来向不同位置的用户返回不同的结果,并在一定程度上取得了成功。不过这种方法总是有点 复杂和容易出错,因为因特网的寻址方案并不是按地理位置组织的,地址块可以改变位置(例如,当公司重新组织其网络时),很多终端用户仍然可以通过缓存名称服务器获得服务。

增加 7 层负载均衡

随着时间的推移,你的客户开始对一些更加高级的特性提出要求。

虽然 4 层负载均衡器可以高效地在多个 web 服务器之间分配负载,但这种分配是只在源 IP 地址和目标 IP 地址、协议和端口上进行的。4 层均衡器对请求的内容一无所知,所以也无法实现很多高级特性。相对而言,7 层(L7)负载均衡器知道请求的结构和内容,可以做得更多。

在 7 层均衡器中可以实现的一些特性包括缓存、限流、错误注入和代价敏感的负载均衡(部分请求需要更多的服务端处理时间)。

它们还可以基于请求的属性(例如 HTTP cookies)进行均衡、终止 SSL 连接,并帮助抵御应用层拒绝服务(DoS)攻击。7 层均衡器成本较高,不易扩容——它们为处理请求做了更多的计算,而且每个活动请求都会消耗一些系统资源。在一个或多个 7 层均衡器池前运行 4 层均衡器可以帮助解决扩展问题。

写在最后

负载均衡是一个复杂的难题。除了本文描述的策略之外,还有不同的 负载均衡算法、用于实现负载均衡器的高可用技术、客户端负载均衡技术以及最近兴起的服务网格。

随着云计算的发展,核心的负载均衡模式也在不断演进,大型 web 服务也将继续改进负载均衡所能提供的控制和灵活性。

英文原文:

https://opensource.com/article/18/10/internet-scale-load-balancing

本文彩蛋

解决技术难题,除了具备过硬的技术理论知识的储备,你还需要掌握一些好用的开发工具。近年来,微服务有多热相信不用我赘述。微服务是一种用于开发高度可伸缩软件系统的架构风格。这种架构可用于开发企业、政府、学校和慈善机构的企业级应用。InfoQ 编辑准备了一份顶级的微服务开源工具清单送给大家,请在公众号对话框回复关键词:微服务,获取清单详细内容。

注:请在公众号对话框回复关键词,留言区回复收不到链接哦~


 
InfoQ 更多文章 没想到你是这样的AWS 从“被动挖光缆”到“主动剪网线”,蚂蚁金服异地多活的微服务体系 分布式系统中最容易被忽视的六大“暗流” 移动互联网的下半场,Android开发者在焦虑什么? 代码行数、查杀bug数笑笑就好,技术团队的KPI到底怎么定?
猜您喜欢 程序员和工程师有什么不一样? ActiveRecord::Relation之scope 重磅开源!《阿里巴巴Android开发手册》抢鲜下载! 2016年全球IT外包百强排行榜 [Markdown] 献给写作者的语言