全局服务器负载均衡已开始向云上转移

本文涉及的产品
应用型负载均衡 ALB,每月750个小时 15LCU
传统型负载均衡 CLB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
简介:

即使应用程序已经从传统的数据中心转移到云计算,但服务器负载均衡仍然是IT基础设施的核心元素。无论服务器是真实的还是虚拟的,永久的还是短暂的,能够在多个服务器之间智能地分配工作负载总是必要的。

但是,在多个云、多个数据中心和混合基础设施之间可靠地分布工作负载的能力仍然存在较大的不足,结果就是工作负载分布不佳和应用程序性能降级。如果能在全球范围内更好地管理工作负载,则可以避免这种性能下降。简而言之,需要更好的全局服务器负载均衡(GSLB)。

全局服务器负载均衡已开始向云上转移

云计算和负载均衡

负载均衡器也被称为应用程序交付控制器(ADCs),被广泛部署在数据中心。它们的功能是将工作负载分配到后端服务器,从而确保最佳地使用聚合服务器容量和带来更好的应用程序性能。

包括Citrix、F5、Kemp Technologies和Radware在内的供应商占据了传统的负载均衡器市场。他们的硬件ADCs一直是基础设施和运营团队的首选解决方案。最近,随着企业将应用转移到云上,来自这些供应商的基于软件的ADCs以及诸如HAProxy、Nginx和Amazon ELB这样的软件解决方案出现了。

组织可以使用两种基本方法中的一种实现多数据中心、多云GSLB。第一个是使用传统的DNS托管方案来进行基本的流量管理。它的优点是易于实现,成本低且可靠,不需要资金投入。不幸的是,它只提供了最小的流量管理功能,如循环DNS和地理路由。这些方法不能阻止工作负载的分布,因为它们使用固定的静态规则,而不是根据每个数据中心的实时工作负载和容量进行路由。例如,地理路由只能确保用户(及其工作负载)被发送到地理位置最近的数据中心。它无法解释用户在地理位置上分布不均、本地需求激增或数据中心服务器宕机的情况。

许多ADC厂商提供他们自己专用的DNS设备,它们与负载均衡器更紧密地集成在一起,以解决这些限制。这是第二种基本方法。这些设备可以根据每个数据中心的实际使用级别来进行流量管理决策,通过接收来自本地负载平衡器的实时负载和容量信息。

这一优势被其权衡所掩盖,许多企业认为这是不愉快的:

1、这些是典型的高性能网络设备,具有很高的资本支出。由于它们必须被广泛部署、冗余配置和防御攻击,因此解决方案的总体结果是高capex(资本性支出)和高opex(运营成本)的。

2、在单个数据中心托管的DNS的性能不足以满足全球用户的需求,但是部署一个全球通用的DNS的成本和复杂性对于大多数企业来说都是望而却步的。

3、对DNS(DDoS)的攻击是普遍存在的,并且很难减轻。对于企业的互联网服务来说,这是一个失败之处。部署和维护DNS的需求带来了一个额外的操作和成本负担。

4、DNS是一项关键任务服务,它对专业技能的要求很高,以100%的可用性进行正确的操作。很少有企业能完成这项任务。

因此,大多数部署了数据中心负载均衡器的企业都没有使用负载均衡供应商提供的GSLB功能。那些已经部署了GSLB功能的人可以使用更好的解决方案来替换它们。更好的方法是基于云计算的GSLB解决方案,它使用负载均衡器的实时遥测技术来进行智能流量管理决策。

GSLB即服务

GSLB最好是作为一种基于云的托管服务交付。这种方法的核心属性和优点如下:

1、活跃。一个有效的GSLB解决方案需要做的不仅仅是直接工作负载,而是那些超载问题。它应该防止过载的情况发生。这样做需要有能力检测过载情况的发生并适当地转移流量,无论这些情况是由于需求峰值、容量损失还是两者都有。

2、用于实时遥测的开放接口。目前大多数使用云架构的公司都有一个混合架构(RightScale,2017),其中包含一些私有数据中心服务器和一些基于云计算的服务器。因为部署混合基础设施的企业经常使用ADC类型(包括商业和开源)的混合,所以GSLB解决方案需要一个开放的接口来从不同的ADC类型中收集实时数据。

3、更低的成本。根据定义,基于云的GSLB作为一种服务可以减少capex,因为没有必要购买硬件或软件设备。运行一个自己的权威DNS需要在全局上部署高性能,并且必须设计为冗余,攻击保护,维护和人员24x7。因此,一个受管理的GSLB解决方案可能会有较低的资本支出和运营支出。

梦想成真

现在,我们可以享受这两个世界的最佳状态:一种全球性能的、可靠的托管DNS服务和先进的流量管理功能,以前只能使用专有的ADC解决方案。这一组合为企业提供了新的机会,可以防止应用程序工作负载的分布不均,并提供更好的整体应用程序性能,以及更好、更一致的终端用户体验。

本文转自d1net(转载)

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
相关文章
|
网络协议 Java API
【JavaEE初阶】 TCP服务器与客户端的搭建
【JavaEE初阶】 TCP服务器与客户端的搭建
|
机器学习/深度学习 人工智能 监控
AI工程化—— 探索如何实现AI在企业多快好省的落地
AI工程化—— 探索如何实现AI在企业多快好省的落地
|
9天前
|
存储 关系型数据库 分布式数据库
PostgreSQL 18 发布,快来 PolarDB 尝鲜!
PostgreSQL 18 发布,PolarDB for PostgreSQL 全面兼容。新版本支持异步I/O、UUIDv7、虚拟生成列、逻辑复制增强及OAuth认证,显著提升性能与安全。PolarDB-PG 18 支持存算分离架构,融合海量弹性存储与极致计算性能,搭配丰富插件生态,为企业提供高效、稳定、灵活的云数据库解决方案,助力企业数字化转型如虎添翼!
|
7天前
|
存储 人工智能 Java
AI 超级智能体全栈项目阶段二:Prompt 优化技巧与学术分析 AI 应用开发实现上下文联系多轮对话
本文讲解 Prompt 基本概念与 10 个优化技巧,结合学术分析 AI 应用的需求分析、设计方案,介绍 Spring AI 中 ChatClient 及 Advisors 的使用。
357 130
AI 超级智能体全栈项目阶段二:Prompt 优化技巧与学术分析 AI 应用开发实现上下文联系多轮对话
|
8天前
|
人工智能 Java API
AI 超级智能体全栈项目阶段一:AI大模型概述、选型、项目初始化以及基于阿里云灵积模型 Qwen-Plus实现模型接入四种方式(SDK/HTTP/SpringAI/langchain4j)
本文介绍AI大模型的核心概念、分类及开发者学习路径,重点讲解如何选择与接入大模型。项目基于Spring Boot,使用阿里云灵积模型(Qwen-Plus),对比SDK、HTTP、Spring AI和LangChain4j四种接入方式,助力开发者高效构建AI应用。
348 122
AI 超级智能体全栈项目阶段一:AI大模型概述、选型、项目初始化以及基于阿里云灵积模型 Qwen-Plus实现模型接入四种方式(SDK/HTTP/SpringAI/langchain4j)
|
20天前
|
弹性计算 关系型数据库 微服务
基于 Docker 与 Kubernetes(K3s)的微服务:阿里云生产环境扩容实践
在微服务架构中,如何实现“稳定扩容”与“成本可控”是企业面临的核心挑战。本文结合 Python FastAPI 微服务实战,详解如何基于阿里云基础设施,利用 Docker 封装服务、K3s 实现容器编排,构建生产级微服务架构。内容涵盖容器构建、集群部署、自动扩缩容、可观测性等关键环节,适配阿里云资源特性与服务生态,助力企业打造低成本、高可靠、易扩展的微服务解决方案。
1338 8
|
1天前
|
存储 JSON 安全
加密和解密函数的具体实现代码
加密和解密函数的具体实现代码
189 136
|
6天前
|
监控 JavaScript Java
基于大模型技术的反欺诈知识问答系统
随着互联网与金融科技发展,网络欺诈频发,构建高效反欺诈平台成为迫切需求。本文基于Java、Vue.js、Spring Boot与MySQL技术,设计实现集欺诈识别、宣传教育、用户互动于一体的反欺诈系统,提升公众防范意识,助力企业合规与用户权益保护。