用于扩展应用程序和 API 的应用程序交付模式
如今，扩展应用程序和 API 并不涉及选择正确的负载平衡算法。 在应用程序交付发展二十多年的过程中，唯一保持不变的就是负载平衡算法。 它们的主要优点是保持可用性。 它们对性能的影响至多是微乎其微的。
这并不是说选择算法无关紧要。 毕竟，循环很少是 API 或应用的最佳选择，但在最少连接和最快响应之间的选择对数字服务的整体性能和可用性的影响不太可能比其架构产生影响。
这将是从架构角度看待应用程序交付，以响应应用程序交付作为设计和运营数字服务所需的六个关键功能之一的提升。
什么是负载平衡算法？
负载平衡算法是一种在资源池中分配负载以确保可用性并提高性能的编程方法。
负载平衡算法指定如何选择特定资源以及考虑哪些变量。
循环法是最简单的算法，它只是按顺序对已知的一组资源进行迭代。 如果有三种资源 - A、B 和 C - 则循环将第一个请求路由到 A，第二个请求路由到 B，第三个请求路由到 C。然后选择过程重新开始。
最少连接是一种基于第二个操作公理的算法，该公理指出“随着负载的增加，性能会下降”。 因此，最小连接算法 将选择连接（负载）最少的资源。 该算法存在多种变体，最显著的是加权最少连接，它允许不同资源的容量存在差异。
当性能是首要考虑因素时，会使用最快的响应时间。 负载均衡器将以被动或主动的方式确定每个资源的响应时间，并针对每个请求选择最快的资源。 该算法不能保证用户响应时间，因为它对最后一英里或用户网络条件没有影响。
源 IP是网络负载平衡遗留下来的算法，它使用源（客户端）IP 的简单哈希值来选择资源。 该算法将始终为给定的源 IP 选择相同的资源。 该算法不再受欢迎，因为它容易受到“超级代理”问题的影响，即来自单个代理/IP 地址的所有用户都会被定向到同一资源。 这往往会导致目标资源不堪重负，从而导致性能不佳，并最终导致失败。
负载平衡算法是应用程序交付架构的重要组成部分，但与整体架构方法相比，其对应用程序或数字服务的性能和规模的影响较小。
什么是应用交付？
应用程序交付是为应用程序、API 和数字服务设计可扩展、高性能架构的学科。 它在很大程度上依赖负载平衡作为核心组件，但结合了第 7 层路由等现代功能，并利用常见的架构模式来优化性能和有效利用资源。
我们使用术语“应用程序交付”来刻意区分负载平衡（一种实现细节）和架构（一种设计过程）。
我们为什么要扩大规模？
规模是对业务成果的技术响应。 即需要维持数字服务所包含的工作负载的可用性和性能，以提高客户满意度分数、转化率和收入创造。 最后一部分尤其重要，因为我们的研究表明，当今大多数（58％）企业至少有一半的收入来自数字服务。
例如，还可以考虑使用公共云实现业务连续性（BC）。 BC是公有云的一个主要用途，其核心是全球规模的实现，即全局负载均衡。 故障转移是应用程序交付的一项核心功能，当应用于整个站点时，能够将请求从一个位置快速重定向到另一个位置。 企业数字存在的持续可用性是一项业务成果，由技术响应实现。
我们如何扩大规模？
回答这个问题开启了我们进入应用程序交付架构的技术之旅。 有两种尺度模型：垂直（向上）和水平（向外）。
垂直扩展基于这样的原则：为系统添加更多的处理能力将会增加容量。 这种扩展方法主要有利于独立的单片applications和系统。 除了基础设施之外，大多数组织不再依赖垂直规模，因为它需要改变物理环境——添加 CPU 或 RAM 或扩展网络容量。 虽然虚拟化可以大大加快垂直扩展速度，尤其是在公共云环境中，但迁移软件和系统（即使是迁移到新的虚拟机）的要求可能会造成破坏。
水平扩展是一种通过增加总可用资源来增强处理能力的架构方法。 这是通过将处理能力分配给应用、服务或系统的多个实例来实现的。 这是当今最常见的扩展方法，因为它依赖于复制资源而不是迁移资源。 此外，水平扩展比垂直扩展提供了更多种类的架构选项，使其更适合所有应用s和 API。
因此，现代应用程序交付模式基于水平扩展原则，这不足为奇。
X 轴刻度
X 轴模式是最基本的模式。 它基于水平复制，大部分工作通过负载平衡算法完成。 这是最简单的模式，其结果就是我所说的普通老式负载平衡（POLB）。
我们之所以这样称呼它，是因为其架构简单，没有利用现代负载均衡器的高级功能来与应用层的请求和响应进行交互。
在这种模式下，applications被复制，并且请求根据配置的负载平衡算法的决定被转发到实例。
由于此模式通常与 TCP（第 4 层）结合使用，因此与依赖于 HTTP（第 7 层）检查的其他模式相比，它具有性能优势。 主要是，连接可以被拼接在一起而不是通过代理，这在初始连接之后有效地将负载均衡器变成网络跳跃。 这会提高整体性能，但却会削弱负载均衡器在初始连接后检查或处理请求和响应的能力。 由于 X 轴架构在确保可用性方面表现出色并且性能卓越，因此它们通常用于扩展基础设施和安全服务，例如防火墙和应用网关。
各种传统（整体式、三层 Web 和客户端-服务器）applications倾向于使用这种模式进行扩展，因为这些applications很少被分解为可以用于现代应用程序交付架构的更离散的组件。
Y 轴刻度
该模式基于功能分解，利用应用程序交付的应用层（第 7 层）功能根据功能而不是整个系统进行扩展。 y 轴模式是第 7 层路由成为应用程序交付架构工具箱中的关键工具的第一个模式。
一般来说，基于 y 和 z 的模式利用第 7 层路由来选择池，然后使用负载平衡算法来选择特定资源。 这与基本的 x 模式不同，其中不使用第 7 层路由。
该模式假设在第 7 层操作，通常是 HTTP，并使用某些变量将流量分发到应用或服务的特定实例。 例如，如果在 URI 中找到模式/login ，则负载均衡器将根据配置的负载均衡算法在仅处理登录请求的应用程序实例池中选择一个实例。 该变量可以是请求标头或请求有效负载中的任何内容。 这允许基于代理的路由、API 路由和基于内容的路由（图像、脚本等）。
应用程序实例可能是克隆。 当应用程序的使用存在差异时，通常就会出现这种情况，而这种差异可以通过请求中的变量来识别。 例如，登录与结帐功能 可以根据 URI、HTTP 标头中的值或请求有效负载中的值在请求中辨别。 应用 y 轴模式允许传统应用s根据功能进行扩展，从而提高资源利用效率，因为可以分配更多资源来处理大容量功能，同时保持其他功能的预期性能。
使用 y 轴模式对传统applications进行功能扩展的做法起源于微服务流行之前，如今微服务对applications进行功能分解。 y 轴模式仍然适用于微服务，并且该模式实际上今天由入口控制器实现。 精明的读者会注意到，这种模式也适用于 API，因为它们依赖于 HTTP（第 7 层）构造，因此 API 网关利用这种基础模式也就不足为奇了。
这种模式在 Web 2.0 早期由 eBay 推广。 其可扩展性架构包括将功能划分为单独的应用池。 销售功能由一组应用服务器提供，竞价功能由另一组应用服务器提供，搜索功能由另一组应用服务器提供。 总的来说，他们将大约 16,000 台应用服务器组织到 220 个不同的池中。 这使得他们可以根据功能需求和资源消耗，独立地扩展每个池。 它进一步允许他们隔离和合理化资源依赖关系 - 例如，销售池只需要与相对较小的后端资源子集进行对话。
y 轴模式还可用于将不同类型的内容请求（例如将图像）分发到一个资源池，并将其他内容类型分发到其他资源池。
使用 y 轴分配负载使得数字服务的各个组件能够单独扩展，这在资源利用方面比 x 轴模式高效得多。 它允许在服务或应用层进行配置优化，通过调整 Web 或应用服务器中的特定变量来针对给定的内容类型进行优化，从而提高其性能。
Z 轴刻度
随着社交媒体和互联网的爆炸式增长，Z 轴模式出于必要而变得流行。 其核心是 Y 轴缩放模式，并应用了额外的分割，通常基于特定变量，如用户名或设备标识符。
该模式允许使用源自数据分片的技术来实现架构区分。
该模式应用数据库中的原理，根据请求中的某些数据来分发请求。 它可以用来协助解决数据层的瓶颈，同时也是确保遵守数据主权规则的一种手段。 它使用可识别的（通常是唯一的）变量来在水平扩展的资源池中路由请求。 当需要高吞吐量时通常使用此模式，例如对特定服务或应用的大量请求。
Z 轴模式对于管理数量达数百万的边缘和物联网设备特别有用。 通过使用设备标识符作为分片请求的基本模式，可以显著提高数据传输的速度。 这对于将其配置存储在远程（云或数据中心）位置的设备特别有用，因为这些数据对于设备来说是唯一的，并且可以安全地分片。
这种模式倾向于提高性能，因为高负载下的数据访问会显著降低性能。 因此，通过将数据访问分散到更多实例，负载就会减少，性能也会随之提高。 这需要仔细注意数据完整性，并且在用于分片共享数据时可能会导致一致性问题。 Meta 提出了分片的话题 当它将服务分片作为其整体架构的一部分进行开发时。 它致力于开发高性能、可扩展的应用程序交付架构，这是一个极好的例子，说明将应用程序交付视为更大架构中的正式层可以带来显著的益处。
对于访问非主数据源的服务，z 轴模式可以提高吞吐量，而不会显著影响整个系统的数据质量。 这种方法减轻了添加代码将应用或 API 的特定实例绑定到数据源的需要，而是依靠实例级别的数据连接器的配置和应用程序传送路由的组合来确保使用正确的数据源。
扩展的秘诀在于应用交付架构
如今，在数字服务交付的世界中，仅使用单一应用程序交付模式来构建高性能、可靠的数字服务的情况非常罕见。 这是因为数字服务本身就很复杂，而且“用户”的多样性也日益增强——涵盖设备、人类和软件。
因此，架构方法考虑在数字服务中充分利用应用程序交付模式，为用户提供最佳体验。
没有“正确”或“错误”的架构解决方案，因为它高度依赖于组成数字服务的服务和applications，只是这种解决方案不应仅基于负载平衡算法。
事实上，应该注意到，没有提到算法选择，因为在负载平衡模式中如何分配负载的选择并不像为特定应用程序或 API 做出正确的架构选择那么重要。
这是推动应用程序交付成为一门学科的因素之一。 如今，应用程序交付和安全的使用和实施方式远远超出了 Web 服务器的简单规模。 它的实施会影响性能、可用性，并最终决定业务成果的成败。 因此，对于组织来说，将应用程序交付作为其设计工具箱中的战略性架构工具非常重要。
负载平衡仍然是扩展的核心技术要求。 了解应用程序交付模式及其如何利用负载平衡将为数字服务的规模和性能架构提供更好的视角，特别是当这些服务可能是混合的并且包含API和现代和传统应用程序的混合时。