应用程序的可用性从未像今天这样受到重视,因为我们使用应用程序不仅仅用于个人或专业的交流,而且应用程序就是业务。
不经常在线或不稳定的应用程序会失去用户和相关性,最终过时。 它发生在一瞬间。 因为互联网从不休眠,每周 24 天,每天 7 小时运行,同样的想法必须适用于应用程序。
可扩展性对于执行此操作和确保应用程序可用性至关重要。 负载平衡是确保可用性的最重要组成部分之一。 许多人仍然相信负载均衡可以通过一个简单的脚本来完成。
然而,这种情况并非如此。 仅它就可以随时随地从任何设备访问世界各地的程序。
在这篇文章中,我们将深入研究负载平衡、它的算法以及它与微服务的关系等等。 让我们开始!
什么是负载均衡?
随着对网站或业务应用程序需求的增长,单个服务器很快将无法处理全部负载。 组织将工作负载分布在众多服务器上以满足需求。 这种称为“负载平衡”的方法可以防止单个服务器过载,这可能导致它变慢、丢弃请求甚至崩溃。
负载均衡平均分配网络流量,以避免由于资源过载而导致的故障。 应用程序、网站、数据库和其他计算机资源使用此方法性能更好,并且更可用。 它还有助于正确和及时地处理用户请求。
从用户的角度来看,负载均衡充当客户端和服务器集合之间的隐形中介,确保连接请求不被丢弃。 如果在没有负载平衡的情况下需求变得太大,应用程序、网站、数据库和在线服务很可能会崩溃。
数十万个用户请求可以同时发送到一个高流量的网站。 需要多个服务器才能使用请求的内容(例如文本、图像、视频和音频流)正确填充网页。 负载平衡通常用于高流量网站服务器群,以及 DNS 服务器、数据库和文件传输协议 (FTP) 站点。
如果单个服务器负担过重,这可能会运行不佳甚至崩溃。 负载均衡器通过在一组服务器之间平均分配用户请求来减少停机的机会。 如果组中的一台服务器发生故障,则流量将重新路由到组中的其他服务器。 负载均衡器在将新服务器添加到服务器池时,会在流量分配过程中自动添加它们。
负载均衡是如何工作的?
它的工作原理如下:
- 当客户端收到请求时,例如通过浏览器或应用程序,它会尝试与服务器连接。
- 当负载均衡器收到请求时,它会根据算法(或场)建立的模式将请求路由到服务器组中的一台服务器。
- 服务器接收连接请求并通过负载均衡器应答客户端。
- 当负载均衡器收到响应时,它会将客户端的 IP 地址与所选服务器的 IP 地址进行匹配。 之后,答案与数据包一起发送。
- SSL 卸载是使用安全套接字层加密协议解密数据的过程,因此服务器不必这样做。
- 重复该过程直到会话结束。
负载平衡方法
为了选择服务器场中的哪些服务器接收下一个请求,每种负载平衡技术都使用一组标准。 负载均衡有五种典型的方法:
- 循环赛:这是默认方法,它的工作原理与听起来一样。 负载均衡器以轮换模式分发请求,从组中的第一台服务器开始,一直到底部,等待再次调用。 此方法可确保每台服务器处理大致相同数量的连接。
- 加权循环:这种方法为每个服务器分配一个权重(或偏好),该权重通常与其容量成正比。 服务器收到的请求越多,权重就越高。 例如,权重值为 XNUMX 的服务器接收的请求数量是权重值为 XNUMX 的服务器的两倍。
- 粘性会话:这种方法也称为会话持久性,在会话期间连接某些客户端和服务器。 为了建立链接,负载均衡器使用 cookie 或用户的 IP 地址来识别用户属性。 建立连接后,用户的请求将被定向到同一服务器,直到会话结束。 这优化了网络资源,同时也改善了用户体验。
- 最少连接:此策略假定所有请求都会导致相同的服务器负担。 结果,请求数量最少的服务器接收下一个请求。
- IP 哈希:此算法根据客户端和服务器的源和目标 IP 地址生成唯一的哈希密钥。 该密钥用于路由请求并允许恢复与同一服务器的丢失连接。
硬件与。 软件负载均衡器
硬件负载均衡器
物理硬件(例如设备)构成了硬件负载平衡器。 这些根据现有连接数、处理器使用率和服务器性能等因素将流量路由到服务器。 硬件负载平衡器具有专有固件,必须在新版本和安全修复可用时进行维护和更新。
硬件负载平衡器通常提供更高的性能和控制,以及更广泛的功能,例如 Kerberos 身份验证和 SSL 硬件加速,但它们需要一定程度的管理和维护专业知识。 由于硬件负载平衡器的灵活性和可扩展性不如软件负载平衡器,因此存在过度配置硬件负载平衡器的倾向。
软件负载均衡器
软件负载平衡器通常比硬件负载平衡器更容易设置。 它们也更具成本效益和适应性,并且可以很好地与软件开发环境配合使用。 该软件方法允许您根据环境的确切要求自定义负载平衡器。 增加的灵活性可能是以花费额外的时间来设置负载平衡器为代价的。
与硬件平衡器相比,软件平衡器为您提供了更大的修改和更新灵活性,后者具有更封闭的方法。 预打包的虚拟机可用作软件负载平衡器 (VM)。 虚拟机将为您节省一些设置时间,但它们可能不具备硬件对应物的所有可用功能。
简单的负载均衡实现
我们将使用 Spring Cloud 库来 建立应用 以负载平衡的方式连接到其他应用程序。 在处理远程服务请求时,我们可以使用我们喜欢的任何技术轻松构建负载平衡。 以下面的代码为例。 我们将从一个基本的服务器应用程序开始。
服务器将只有一个 HTTP 端点,并且将在多个实例中运行。 然后我们将构建一个客户端应用程序,该应用程序使用负载均衡器在多个服务器实例之间分发请求。
服务器
我们从一个基本的 春季靴 我们的示例服务器的应用程序:
首先,我们注入一个名为 instance_ID 的可自定义变量。 这有助于我们区分正在运行的众多实例。 之后,我们创建一个返回消息和实例 ID 的 HTTP GET 端点。
ID 为 1 的默认实例将在端口 8080 上运行。我们只需添加一些程序参数即可启动第二个实例:
客户
现在让我们看一下客户端代码。 这就是负载均衡器的用武之地,所以让我们首先将它整合到我们的应用程序中:
之后,我们开发了一个 ServiceInstanceListSupplier 的实现。 这是负载均衡器中最重要的接口之一。 它指定了我们如何定位可访问的服务实例。
我们将在示例应用程序中对示例服务器的两个单独实例进行硬编码。 它们在同一系统上运行,但使用不同的端口:
现在创建一个 LoadBalancerConfiguration 类:
这个类只有一个目的:它创建一个负载平衡的 WebClient 构建器来发出远程请求。 我们的注释为服务使用了一个虚构的名称。
这是因为我们很可能不会提前知道运行实例的精确主机名和端口。 因此,我们使用一个虚构的名称作为占位符,框架将在选择运行实例时替换实际信息。
接下来,让我们创建一个配置类,用于实例化我们的服务实例供应。 请注意,我们使用与以前相同的别名:
我们现在可以构建真正的客户端应用程序。 让我们使用之前的 WebClient bean 向示例服务器发送 10 个查询:
我们可以从输出中看到我们正在两个单独的实例之间进行负载平衡:
微服务中的负载均衡
Netflix 和 Amazon 等多家公司正在使用微服务架构将业务应用程序开发为一组松散连接的服务。 复杂应用程序的超大规模和持续交付只是迁移到这种分布式、松散连接架构的两个原因。
这些企业的团队已经实施了敏捷和 DevOps 策略,以便比传统方法更快地生产应用程序并降低故障率。 但是,您必须在分布式架构的复杂性与应用程序的需求、规模要求和上市时间限制之间取得平衡。
多年来,应用交付控制器 (ADC) 对于满足托管在本地或云中的企业应用程序的服务级别要求至关重要。 使用基于微服务的应用程序的客户端不需要了解提供它的实例即可独立地发展客户端和微服务。
这正是反向代理或负载均衡器提供的解耦。 同样,负载平衡是确保微服务能够处理需求、安全性和可用性的解决方案。
当您将客户端和基于微服务的应用程序之间的传统南北负载平衡与东西部署相结合以实现水平可扩展性时,您将获得显着提升。 目标是在不牺牲开发敏捷性或 DevOps 自动化 要求。
认证的益处
负载平衡通过提高高流量网站和应用程序以及获得大量查询的数据库的资源利用率、数据交付和响应时间来提供各种好处。 负载均衡可确保在高流量场景下快速正确地满足用户请求。
它们为用户节省了处理缓慢程序和资源的麻烦。 负载平衡还有助于避免停机并简化安全性,降低公司生产力和收入损失的风险。
- 除了管理流量以达到最佳效率外,负载平衡还提供了根据需要添加和删除服务器的灵活性。 由于在维护期间流量会被转移到其他服务器,因此在不干扰用户的情况下进行服务器维护也是可行的。
- 负载平衡通过在一组服务器之间划分流量来提供内置冗余。 如果一台服务器出现故障,您可以立即将负载转移到其他服务器,从而最大限度地减少对用户的影响。
- 如果应用程序或网站的使用量增加,如果不能有效处理,增加的流量可能会降低其性能。 通过负载平衡,您可以添加真实或虚拟服务器来满足需求,而不会中断服务。 负载均衡器在新服务器上线时识别它们,并毫不费力地将它们整合到操作中。 这种方法比将网站从负担过重的服务器迁移到新的服务器更可取,这通常会导致一些停机时间。
结论
负载平衡是当代容错系统的关键组成部分。 我们可以简单地构建应用程序,使用各种负载平衡方法将请求分发到多个服务实例。 企业必须支持复杂的 IT 系统才能安全地提供应用程序。
跨域微服务配置、部署和维护可能容易出错、昂贵且耗时。 IT 应使用与其敏捷和 DevOps 流程兼容的自动化、可见性、分析和编排最佳实践和技术,以简化这些微服务的设置和维护。
发表评论