五大可扩展性模式

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

在应用即货币的经济环境中，可用性至关重要。无响应的应用会被用户毫不犹豫地删除，还会像 Yelp 上的负面评论一样，迅速遭到尖锐的网络差评。

从互联网诞生之初，组织就一直致力于确保应用（早期主要是网站）全年无休地保持可用。因为互联网从不休息，也不会休假或请病假。

为满足这一需求（实际上是必要条件），可扩展性成为最早用于保障可用性的应用服务之一。在满足可用性需求的应用服务中，负载均衡最为常见，也最广为人知。

不过，负载均衡有多种形式，利用这项核心技术也可以实施多种可扩展性模式。今天，我将重点介绍5种广泛使用的可扩展性模式，它们有助于确保应用和互联网全年无休地保持在线和可用。

全局服务器负载均衡（GSLB）

GSLB这个名称很容易引起误解。它实际上从来都不是关于服务器负载均衡，而是关于站点可用性。如今，其含义也扩展到了应用可用性。

GSLB可确保在一个数据中心（云数据中心或传统数据中心）无响应时找到另一个数据中心。GSLB可应用于域级别或主机级别。因此，可以使用它在不同位置之间切换example.com，也可以切换api.example.com.

最基本的GSLB采用简单的DNS负载均衡。它会维护一个与域或主机关联的IP地址列表；如果第一个IP地址不可用，请求就会被定向到列表中的第二个、第三个、第四个，依此类推。

此过程分为两个步骤：

1. 向全局负载均衡器查询适当的IP地址。这正是GSLB一直存在的缺点：如果您在过去15分钟内（或在cheese.com的IP地址当前TTL所规定的时间内）查询过，就会得到上次收到的响应。因此，如果该站点在此期间发生故障，您将无法连接。
2. 向GSLB查询返回的站点IP地址发出请求。该地址通常对应一个本地负载均衡器，它使用自身的算法和决策流程，将请求转发到适当的资源。

第1步的决策通常不涉及智能判断，只根据指定站点是否响应来决定。不过，通过这种方式，可以利用云、托管服务提供商和本地部署等多个位置来确保可用性。通过有策略地选择分布在不同地理区域的位置，可以避免受到自然灾害或互联网中断的影响。

但这更像是DR（灾难恢复）或BC（业务连续性）场景。其他场景则会利用更智能的GSLB应用服务，例如地理位置和应用性能服务。因此，如果站点A的应用性能不佳，可以考虑将访问者转至站点B，直至问题解决。也可以将用户引导至地理位置最近的站点，以帮助提升性能（毕竟光速仍是客观限制，距离会影响应用性能）。

无论如何做出决策，基本模式都保持不变：GLSB通过返回其中一个可用站点的IP地址，将请求分发到多个物理隔离的站点。无论是API还是应用，GSLB都是一种顶层可用性保障模式。

传统负载均衡（POLB）

基于连接的可用性

我喜欢用传统负载均衡（POLB）来描述基于TCP的标准负载均衡。这种模式通过复制应用，并确保客户端（用户或设备）能够与应用建立连接来实现可用性。

负载均衡器（也可以称为代理）接收连接请求，选择一个可用的应用实例，然后转发该连接。此后，负载均衡器便不再主动参与。这就像发送一封“引荐邮件”，帮助两位同事建立联系。您会主动参与最初的交流，但随后会被移至抄送栏，通常不再进一步参与。

我使用POLB一词，是因为请求转发方式完全由算法决定。遗憾的是，采用不同的请求分配算法，可能会引发许多问题。例如，轮询算法不考虑容量或性能，只会选择“下一个应用”，然后将请求转发过去。选择“最少连接”算法可能会让请求集中到某个资源上，从而迅速影响性能，而其他资源的处理速度或许更快。因此，算法的选择成为维持可用性的关键因素。

POLB是容器环境以及许多云原生负载均衡服务默认采用的负载均衡方法。

持久性

会话保持与SSL

三层应用通常是有状态的，这是其实际特点之一。这意味着，它们会在请求和响应之间存储对应用运行至关重要的信息。购物车、凭据、状态、上次访问的页面以及当前所处的流程步骤等信息，通常都会作为“会话”的一部分进行存储。问题在于，许多使用三层框架开发的应用最终将会话存储在应用服务器或Web服务器上，而不是数据库中。因此，一旦连接到某台服务器，后续请求就必须持续发送到该服务器，才能确保所有信息均可用。

负载均衡器通过多种方式实现会话持久性，其中最常见的是基于Cookie的方式。会话ID存储在Cookie中，负载均衡器随后利用该ID确保请求发送到正确的服务器，从而有效绕过基于算法的选择过程。

当使用SSL/TLS成为增强购物者安全感的一项关键要求时，同样的问题也随之出现。SSL/TLS可在客户端与特定应用服务器之间建立安全会话。为确保通信双方都能解密并使用通过该连接交换的数据，负载均衡器必须能够将客户端请求发送到最初建立连接的同一台服务器。通过采用与实现基于会话的持久性相同的技术，负载均衡器能够支持基于SSL/TLS的持久性。

无论采用哪种具体的持久性类型，其工作模式都相同。如果有指示信息表明会话已建立，负载均衡器会沿用现有连接，并确保该连接在用户会话期间保持不变。如果没有此类指示信息，负载均衡器会根据其配置和算法选择资源并建立连接。

这会影响选择负载均衡算法时的容量规划。最少连接算法适合此场景，因为它可以确保不会出现单个资源因持续会话而过载、其他资源却处于空闲状态的情况。使用其他算法时，单个资源可能最终需要同时维持大量用户会话，从而对定向到该服务器的所有用户的性能产生负面影响。

基于主机的负载均衡

虚拟服务器

基于主机的负载均衡是最常见且受到广泛支持的扩展模式之一。您可能认为，实现这种模式不需要负载均衡器，因为所有Web服务器都能同时充当多个主机。但实际上仍然需要。虽然Web/应用服务器可以托管多个虚拟服务器，但不一定会在这些虚拟服务器之间进行负载均衡。因此，要实现扩展，仍然需要负载均衡器。问题在于：是由负载均衡器拆分主机，还是交由Web/应用服务器处理？

无论使用Web/应用服务器指令还是外部负载均衡器，流程都相同。目标（负载均衡器或Web/应用服务器）收到请求后，会检查HTTP标头并查找host值，然后将请求定向到相应的虚拟服务器。

使用负载均衡器拆分主机的优势在于，可以按主机隔离域并分别进行扩展。这样效率更高，并可减少扩展应用所需的服务器（硬件和软件）数量。此外，由于可以更准确地预测每台主机服务器在特定时间能够处理的负载，容量规划也会更加轻松。

这是因为，调用业务逻辑与请求图像所需的计算资源并不相同。在同一扩展域中混合部署主机，会导致负载波动和容量难以预测。如果选择使用负载均衡器仅提供基本的负载均衡，则需要由Web/应用服务器拆分主机，并将请求定向到相应的虚拟服务器。这种方法还存在共享基础设施方面的缺点，例如版本冲突、补丁安装和应用更新都可能导致虚拟服务器之间相互影响。

随着容器和微服务日益普及，基于主机的负载均衡正越来越多地以入口控制器的形式得到应用。

路由与返回

第7层（HTTP）负载均衡

第7层（HTTP）负载均衡是我最喜欢的方式，因为它非常灵活（或者说敏捷？）。您可以根据任何HTTP内容（包括有效负载）对请求进行负载均衡。大多数人会明智地将负载均衡规则限定为HTTP标头中可获取的信息，包括主机、HTTP方法、内容类型、Cookie、自定义标头和用户代理等。

HTTP负载均衡首先进行路由，然后再进行负载均衡。典型的HTTP负载均衡模式为“路由→分配”。也就是说，首先确定应将请求定向到哪个虚拟服务器，然后由算法从支持该虚拟服务器的资源池中选择一项资源。

HTTP负载均衡支持API版本控制等模式，其中API版本嵌入URI（或自定义HTTP标头）中。负载均衡器可以区分不同版本，并确保将客户端请求发送到正确的后端服务执行。在无法强制升级的情况下，这可以让客户端平稳迁移。

此类可扩展性模式还支持功能分解和数据分区等其他可扩展性模式。它在这些模式中具有较强的稳健性和敏捷性，可为应用以及日益普及的微服务横向扩展提供丰富的选择。

总而言之，主要有五种可扩展性模式，其中大多数可以结合使用，而且通常也是如此，从而尽可能提高资源利用效率和性能。即使目前尚未采用其中任何一种，今后也很可能会用到。因此，无论使用何种应用，或将其部署在何处，了解这些模式的基本构成都能为构建可扩展架构打下良好基础。

持续扩展！

关于作者

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。

Lori Mac Vittie 的更多博客文章