五大可扩展性模式
在应用就是货币的经济体中，可用性是一件严肃的事情。 没有响应的应用程序会被立即删除，并会以 Yelp 负面评论的速度和讽刺在互联网上遭到诋毁。
自互联网诞生之初，各组织就一直致力于确保应用（以前是网站）能够全天候 (24x7x365) 可用。 因为互联网从不休息、从不休假、从不请病假。
为了满足这一需求（实际上是要求），可扩展性成为首批提供可用性的应用服务之一。 满足可用性需求的最明显且最容易理解的应用服务是负载均衡。
然而，您可以使用这项核心技术实现多种形式的负载均衡和可扩展性模式。 今天，我将重点介绍目前使用的五大可扩展性模式，这些模式可确保应用程序和互联网全年 24 小时不间断地在线且可用。
全局服务器负载平衡 (GSLB)
GSLB 这个名字非常不恰当。 这实际上与服务器负载均衡无关，而是与站点可用性有关。 如今，这一概念已延伸至应用程序可用性。
GSLB 是一种确保如果一个数据中心（云或传统）没有响应时可以找到另一个数据中心的手段。 GSLB 可以应用于域或主机级别。 因此，您可以使用它在位置之间切换example.com以及api.example.com。
从最基本的角度来说，GSLB 使用基本的基于 DNS 的负载均衡。 这意味着它有一个与域或主机关联的 IP 地址列表，如果第一个不可用，则请求将被定向到列表中的第二个、第三个、第四个等等。
此过程分为两个步骤：
- 向全局负载均衡器询问适当的 IP 地址。 这始终是与 GSLB 相关的负面问题 —— 如果您在过去 15 分钟内或当前 TTL 内询问过 cheese.com 的 IP 地址，您将收到最后的回应。 因此，如果该网站在那时瘫痪了，您将无法连接。
- 向 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 标头并找到主机值，然后将请求定向到适当的虚拟服务器。
使用负载均衡器分割主机的好处是它能够基于主机隔离域并单独扩展它们。 这更有效率，并且可以减少扩展应用所需的服务器（硬件和软件）数量。 它进一步使容量规划变得更容易，因为您可以更好地预测每个主机服务器在给定时间内可以处理的负载。
这是因为调用业务逻辑所需的计算与请求图像所需的计算不同。 在同一个可扩展域中混合和匹配主机会导致负载不稳定且容量不可预测。 如果您选择使用负载均衡器来提供普通的负载均衡，那么 Web / 应用服务器将负责分离主机并将请求定向到适当的虚拟服务器。 这种方法的其他缺点是共享基础设施的性质，版本冲突和修补以及应用程序更新可能会导致虚拟服务器之间的摩擦。
容器和微服务的日益普及推动了以入口控制器形式使用基于主机的负载均衡。
路线和返回
第 7 层 (HTTP) 负载平衡
我最喜欢第 7 层（HTTP）负载均衡，因为它具有多功能性（灵活性？）。 您可以根据任何 HTTP（包括有效负载）来平衡请求负载。 大多数人（我认为很聪明）将他们的负载均衡规则限制在 HTTP 标头中可以找到的内容。 其中包括主机、HTTP 方法、内容类型、cookie、自定义标头和用户代理等。
HTTP负载均衡首先讲的是路由，然后讲的是负载均衡。 典型的 HTTP 负载均衡模式采用路由 –> 分发的形式。 这意味着首先要决定将请求定向到哪个虚拟服务器，然后使用算法从支持该虚拟服务器的池中选择一个资源。
HTTP 负载均衡支持 API 版本控制等模式，其中 API 版本嵌入在 URI 中（或自定义 HTTP 标头中）。 负载均衡器能够分离版本并确保客户端被发送到正确的后端服务进行执行。 在无法强制升级的情况下，这总是可以顺利地迁移客户端。
这种可扩展性模式还支持其他可扩展性模式，如功能分解和数据分区。 它是组合中最强大、最敏捷的可扩展性模式，并且在扩展应用程序和日益增多的微服务时允许大量的选项。
总而言之，我们有五种主要的可扩展性模式，其中大多数可以（通常是）结合起来，以实现最有效的资源利用和尽可能最高的性能。 很有可能您现在没有使用其中任何一个，但将来您也会使用，因此了解它们的基本组成是构建可扩展架构的良好基础，无论您使用什么类型的应用程序 - 或者将它们部署在何处。
继续扩大规模！