用于扩展应用和API的应用交付模式

如今，要扩展应用和API，关键并不在于选择合适的负载均衡算法。在应用交付技术演进的20多年里，负载均衡算法始终没有太大变化。其主要作用是维持可用性，对性能的影响则十分有限。

这并不是说算法的选择无关紧要。毕竟，轮询通常并非API或应用的理想选择，但与数字服务的架构相比，在最少连接和最快响应之间进行选择，对其整体性能和可用性的影响可能较小。 

本文将从架构角度探讨应用交付，以回应应用交付被提升为设计和运营数字服务所需的六项关键能力之一。

什么是负载均衡算法？

负载均衡算法是一种通过程序将负载分配到资源池中的方法，旨在确保可用性并提升性能。

负载均衡算法规定如何选择特定资源，以及需要考虑哪些变量。

轮询是最简单的算法，按顺序依次遍历一组已知资源。如果有A、B和C这3个资源，轮询算法会将第1个请求路由到A，第2个请求路由到B，第3个请求路由到C，然后重新开始选择。

最少连接数算法基于第二条运行公理，即“负载越高，性能越低”。因此，最少连接数算法会选择连接数（负载）最少的资源。该算法有多种变体，其中较为常见的是加权最少连接数，它可以考虑不同资源之间的容量差异。

最快响应时间适用于将性能作为首要考虑因素的场景。负载均衡器会以被动或主动方式确定各资源的响应时间，并为每个请求选择响应最快的资源。此算法无法保证用户响应时间，因为它无法影响最后一公里或用户的网络状况。

源IP是一种沿用自网络负载均衡的算法，它使用源（客户端）IP的简单哈希值来选择资源。对于给定的源IP，此算法始终会选择同一资源。由于此算法容易受到“巨型代理”问题的影响，现已不再常用。在这种情况下，来自同一代理或IP地址的所有用户都会被定向到同一资源。这往往会使目标资源不堪重负，导致性能下降，并最终发生故障。

负载均衡算法是应用交付架构的重要组成部分，但与整体架构方法相比，对应用或数字服务的性能和扩展能力影响较小。

什么是应用交付？

应用交付是一门为应用、API和数字服务设计可扩展高性能架构的专业领域。它以负载均衡为核心组件，同时融入第7层路由等现代功能，并利用常见架构模式来优化性能和资源利用效率。

我们使用“应用交付”一词，是为了明确区分作为实施细节的负载均衡与作为设计过程的架构。

为什么要扩展？

扩展是为实现业务成果而采取的技术措施。具体而言，需要保持构成数字服务的工作负载的可用性和性能，从而提高客户满意度评分、转化率和创收能力。最后一点尤为重要，因为我们的研究表明，如今大多数企业（58%）至少有一半的收入来自数字服务。

例如，还可以考虑将公有云用于业务连续性（BC）。业务连续性是公有云的主要用途之一，其核心是实现全球规模扩展，即全局负载均衡。故障转移是应用交付的一项核心能力。将其应用于整个站点时，可以将请求从一个位置快速重定向到另一个位置。企业数字化业务的持续可用性是一项业务成果，需要通过技术手段来实现。

如何实现扩展？

回答这个问题，是我们探索应用交付架构技术之旅的起点。扩展有两种模式：纵向扩展（向上）和横向扩展（向外）。

垂直扩展基于这样一个原理：为系统增加更多处理能力可以提升容量。这种扩展方式主要适用于单体应用和自包含系统。除基础设施外，大多数组织已不再依赖垂直扩展，因为这需要改变物理环境，例如增加CPU或RAM，或扩展网络容量。虽然虚拟化可以大幅加快垂直扩展，尤其是在公有云环境中，但迁移软件和系统（即使只是迁移到新的虚拟机）仍可能造成中断。

横向扩展是一种通过增加可用资源总量来提升处理能力的架构方法。它将处理能力分布到应用、服务或系统的多个实例上。由于采用复制资源而非迁移资源的方式，横向扩展已成为目前常用的扩展方法。此外，横向扩展比纵向扩展提供更多架构选择，因此更适合各类应用和API。

因此，现代应用交付模式以横向扩展原则为基础也就不足为奇了。

应用交付模式

仅仅选择“横向扩展”并不意味着讨论就此结束。

做出这一选择后（通常默认会这样选择），还应综合考虑其他因素，以确定具体的实施架构。最简单的方法是从扩展立方体的角度来评估这一决策，具体可参阅《可扩展性艺术》。

简单来说，扩展立方体包含x、y和z三个轴，每个轴分别对应一种负载均衡架构模式。针对不同类型的应用和API，这些模式各自适用于实现特定的性能和可用性目标。

数字服务可能会采用融合多种模式的架构，以同时优化性能和资源消耗。这种方法需要运用系统思维，综合考虑所有组件、组件之间的交互方式，以及请求如何从用户流向应用，再由应用返回用户。

X轴缩放

X轴模式是最基本的模式。它以水平复制为基础，大部分工作通过负载均衡算法完成。这是最简单的模式，形成了我所说的普通负载均衡（POLB）。

之所以这样称呼，是因为这种架构非常简单，并未利用现代负载均衡器在应用层与请求和响应交互的高级功能。

在此模式下，应用会被复制，请求则根据已配置负载均衡算法的决策转发到相应实例。

由于此模式通常与TCP（第4层）结合使用，因此与依赖检查HTTP（第7层）的其他模式相比，它具有性能优势。其主要原因是，连接可以直接拼接，而无需通过代理转发。这样一来，初始连接建立后，负载均衡器实际上就成为一个网络跃点。此方式可提升整体性能，但负载均衡器将无法在初始连接后检查请求和响应，也无法对其执行操作。X轴架构在确保可用性方面表现出色，并且可以实现较高性能，因此常用于扩展防火墙和应用网关等基础设施及安全服务。

各种传统应用（包括单体应用、三层Web应用和客户端-服务器应用）往往采用此模式进行扩展，因为这类应用很少会被拆分为更细粒度的组件，以供现代应用交付架构使用。

Y轴扩展

此模式以功能分解为基础，利用应用交付的应用层（第7层）功能，按功能而非整个系统进行扩展。Y轴模式首次将第7层路由作为应用交付架构工具箱中的关键工具。

通常，基于y轴和z轴的模式会利用第7层路由选择资源池，然后使用负载均衡算法选择具体资源。这与基本的x轴模式不同，后者不使用第7层路由。

此模式假定在第7层（通常为HTTP）运行，并使用某个变量将流量分配到应用或服务的特定实例。例如，如果在URI中发现模式/login，负载均衡器将根据配置的负载均衡算法，从仅处理登录请求的应用实例池中选择一个实例。该变量可以是请求标头或请求有效负载中的任何内容。这样便可实现基于代理的路由、API路由和基于内容的路由（图像、脚本等）。

应用实例可以是克隆实例。当应用中不同功能的使用量存在差异，并且可通过请求中的变量识别这种差异时，通常会采用这种方式。例如，可以根据URI、HTTP标头中的值或请求负载中的值，识别请求中的登录和结账功能。应用Y轴模式后，传统应用可以按功能进行扩展，从而提高资源利用效率。这是因为可以为高流量功能分配更多资源，同时保持其他功能达到预期性能。

使用y轴模式按功能扩展传统应用的做法，早在微服务普及之前就已出现。如今，微服务可按功能拆分应用。y轴模式仍适用于微服务，而且目前已有入口控制器采用该模式。细心的读者会注意到，此模式也适用于API，因为API依赖HTTP（第7层）结构。因此，API网关采用这一基础模式也就不足为奇了。

这种模式因eBay的采用而得到普及，当时正值Web 2.0发展初期。其可扩展性架构将不同功能划分到独立的应用池中。销售功能由一组应用服务器提供，竞价功能由另一组提供，搜索功能则由又一组提供。他们总共将约16,000台应用服务器划分到220个不同的应用池中。这样便可根据各项功能的需求和资源消耗，彼此独立地扩展每个应用池。此外，还可隔离并合理规划资源依赖关系。例如，销售应用池只需与相对较少的一部分后端资源通信。

Y轴模式还可用于将不同类型的内容请求分配到不同的资源池，例如，将图像请求分配到一个资源池，将其他类型的内容请求分配到其他资源池。

使用y轴分配负载，可让数字服务的各个组件独立扩展，在资源利用率方面比x轴模式高效得多。还可以在服务层或应用层优化配置，通过调整Web服务器或应用服务器中的特定变量，针对给定内容类型进行优化，从而提升性能。

Z轴扩展

随着社交媒体和整个互联网的爆发式增长，实际需求推动了Z轴模式的普及。其本质上是一种应用了额外分段的Y轴扩展模式，通常根据用户名或设备标识符等特定变量进行分段。

此模式采用源自数据分片的技术，实现架构差异化。

此模式采用数据库中的相关原理，根据请求中的某项数据分发请求。它有助于解决数据层的瓶颈，也可用于确保遵守数据主权规则。此模式使用一个可识别且通常唯一的变量，将请求路由到横向扩展的资源池。它通常用于需要高吞吐量的场景，例如特定服务或应用需要处理大量请求时。

Z轴模式特别适合管理数量可能达到数百万台的边缘设备和物联网设备。以设备标识符为依据对请求进行分片，可以显著提高数据传输速度。对于将配置存储在远程位置（云或数据中心）的设备，这种模式尤其有用，因为这些数据是设备独有的，可以安全地进行分片。

这种模式通常有助于提升性能，因为高负载下的数据访问可能会显著降低性能。因此，将数据访问分散到更多实例上，可以降低负载并提升性能。这需要密切关注数据完整性；如果用于对共享数据进行分片，可能会导致一致性问题。Meta提升了业界对分片的关注，当时该公司将服务分片纳入其整体架构。Meta在构建高性能、可扩展的应用交付架构方面投入了大量精力，充分说明了将应用交付视为大型架构中的正式层级可以带来显著收益。

对于访问非主数据源的服务，z轴模式可以提高吞吐量，同时不会显著影响整个系统的数据质量。此方法无需添加代码来将应用或API的特定实例绑定到某个数据源，而是结合实例级数据连接器配置与应用交付路由，确保使用正确的数据源。

实现规模扩展的关键在于应用交付架构

如今，在数字服务交付领域，仅采用单一应用交付模式来构建高性能、高可靠性的数字服务已不多见。这是因为数字服务本身具有复杂性，而“用户”也日益多样化，涵盖设备、人员和软件。

因此，架构方法会考虑如何在整个数字服务中合理运用各种应用交付模式，为用户提供更优体验。

架构解决方案并无绝对的“对”与“错”，因为它在很大程度上取决于构成数字服务的各项服务和应用程序。但有一点是明确的：此类解决方案不应仅基于负载均衡算法。

事实上，需要注意的是，前文并未提及算法选择，因为与为特定应用或API选择合适的架构相比，如何在负载均衡模式中分配负载并没有那么重要。

这是推动应用交付发展成为一门专业学科的因素之一。如今，应用交付和安全的使用与实施方式早已超越了简单扩展Web服务器的范畴。其实施方式可能会影响性能和可用性，并最终决定业务成果的成败。因此，组织应将应用交付视为设计工具箱中的战略性架构工具。

负载均衡仍是实现规模扩展的核心技术要求。了解应用交付模式及其如何利用负载均衡，有助于更全面地规划数字服务的规模扩展和性能架构，尤其是当这些服务可能采用混合模式，并由API、现代应用和传统应用共同组成时。

_脚注

_{¹ 维基百科}