【服务网格架构】Envoy架构概览(5):负载均衡

本文涉及的产品
传统型负载均衡 CLB,每月750个小时 15LCU
应用型负载均衡 ALB,每月750个小时 15LCU
EMR Serverless StarRocks,5000CU*H 48000GB*H
简介: 【服务网格架构】Envoy架构概览(5):负载均衡

负载均衡

当过滤器需要获取到上游群集中主机的连接时,群集管理器使用负载平衡策略来确定选择哪个主机。负载平衡策略是可插入的,并且在配置中以每个上游集群为基础进行指定。请注意,如果没有为群集配置活动的运行状况检查策略,则所有上游群集成员都认为是正常的。

支持的负载平衡器


循环赛(Round robin)

这是一个简单的策略,每个健康的上游主机按循环顺序选择。


加权最低要求

请求最少的负载均衡器使用O(1)算法来选择两个随机健康主机,并挑选出活动请求较少的主机。(研究表明,这种方法几乎与O(N)全扫描一样好)。如果群集中的任何主机的负载均衡权重大于1,则负载均衡器将转换为随机选择主机,然后使用该主机<权重>次的模式。这个算法对于负载测试来说简单而充分。在需要真正的加权最小请求行为的情况下(通常如果请求持续时间可变且长度较长),不应使用它。我们可能会在将来添加一个真正的全扫描加权最小请求变体来覆盖这个用例。


环哈希

环/模哈希负载平衡器对上游主机执行一致的哈希。该算法基于将所有主机映射到一个圆上,使得从主机集添加或移除主机的更改仅影响1 / N个请求。这种技术通常也被称为“ketama”哈希。一致的散列负载均衡器只有在使用指定要散列的值的协议路由时才有效。目前唯一实现的机制是通过HTTP路由器过滤器中的HTTP头值进行散列。默认的最小铃声大小是在运行时指定的。最小环大小控制环中每个主机的复制因子。例如,如果最小环大小为1024,并且有16个主机,则每个主机将被复制64次。环哈希负载平衡器当前不支持加权。


当使用基于优先级的负载均衡时,优先级也由散列选择,所以当后端集合稳定时,选定的端点仍然是一致的。


随机

随机负载均衡器选择一个随机的健康主机。如果没有配置健康检查策略,那么随机负载均衡器通常比循环更好。随机选择可以避免在发生故障的主机之后对集合中的主机造成偏见。


原始目的地

这是一个特殊用途的负载平衡器,只能与原始目标群集一起使用。上游主机是基于下游连接元数据选择的,即,连接被打开到与连接被重定向到特使之前传入连接的目的地地址相同的地址。新的目的地由负载均衡器按需添加到集群,并且集群定期清除集群中未使用的主机。原始目标群集不能使用其他负载平衡类型。

恐慌阈值

在负载均衡期间,Envoy通常只考虑上游群集中的健康主机。但是,如果集群中健康主机的比例过低,特使就会忽视所有主机的健康状况和平衡。这被称为恐慌阈值。默认的恐慌阈值是50%。这可以通过运行时配置。恐慌阈值用于避免主机故障在负载增加时在整个集群中级联的情况。


优先级

在负载均衡期间,Envoy通常只考虑配置在最高优先级的主机。对于每个EDS LocalityLbEndpoints,还可以指定一个可选的优先级。当最高优先级(P = 0)的端点健康时,所有的流量都将落在该优先级的端点上。由于最高优先级的端点变得不健康,交通将开始慢慢降低优先级。


目前,假定每个优先级级别由1.4的(硬编码)因子过度配置。因此,如果80%的终点是健康的,那么优先级依然被认为是健康的,因为80 * 1.4> 100。随着健康终点的数量下降到72%以下,优先级的健康状况低于100。的流量相当于P = 0的健康状态将进入P = 0,剩余的流量将流向P = 1。


假设一个简单的设置有2个优先级,P = 1 100%健康

P=0 healthy endpoints Percent of traffic to P=0 Percent of traffic to P=1
100% 100% 0%
72% 100% 0%
71% 99% 1%
50% 70% 30%
25% 35% 65%
0% 0% 100%


如果P = 1变得不健康,它将继续从P = 0接受溢出负荷,直到健康P = 0 + P = 1的总和低于100为止。此时,健康将被放大到“有效”健康 的100%。

P=0 healthy endpoints P=1 healthy endpoints Traffic to P=0 Traffic to P=1
100% 100% 100% 0%
72% 72% 100% 0%
71% 71% 99% 1%
50% 50% 70% 30%
25% 100% 35% 65%
25% 25% 50% 50%


随着更多的优先级被添加,每个级别消耗等于其“缩放”有效健康的负载,因此如果P = 0 + P = 1的组合健康小于100,则P = 2将仅接收业务。

P=0 healthy endpoints P=1 healthy endpoints P=2 healthy endpoints Traffic to P=0 Traffic to P=1 Traffic to P=2
100% 100% 100% 100% 0% 0%
72% 72% 100% 100% 0% 0%
71% 71% 100% 99% 1% 0%
50% 50% 100% 70% 30% 0%
25% 100% 100% 35% 65% 0%
25% 25% 100% 25% 25% 50%

用伪算法来总结这一点:

loadtoP_0=min(100,health(P_0)*100/total_health)

health(P_X)=140*healthy_P_X_backends/total_P_X_backends

total_health=min(100,Σ(health(P_0)...health(P_X))


loadtoP_X=100-Σ(percent_load(P_0)..percent_load(P_X-1))


区域感知路由

我们使用以下术语:


  • 始发/上游集群:特使将来自原始集群的请求路由到上游集群。
  • 本地区域:包含始发和上游群集中的主机子集的同一区域。
  • 区域感知路由:尽力将请求路由到本地区域中的上游群集主机。

在原始和上游群集中的主机属于不同区域的部署中,Envoy执行区域感知路由。在区域感知路由可以执行之前有几个先决条件:


  • 发起和上游集群都不处于恐慌状态。
  • 区域感知路由已启用。
  • 原始群集与上游群集具有相同的区域数量。
  • 上游集群有足够的主机。浏览此处获取更多信息。

区域感知路由的目的是尽可能多地向上游群集中的本地区域发送流量,同时在所有上游主机(每个上游主机(取决于负载平衡策略))上每秒大致保持相同数量的请求。


只要维持上游集群中每台主机的请求数量大致相同,特使就会尝试尽可能多地将流量推送到本地上游区域。决定Envoy路由到本地区域还是执行跨区域路由取决于本地区域中始发群集和上游群集中健康主机的百分比。在原始和上游集群之间的本地区的百分比关系有两种情况:


  • 源群集本地区域百分比大于上游群集中的百分比。在这种情况下,我们不能将来自原始集群的本地区域的所有请求路由到上游集群的本地区域,因为这将导致所有上游主机的请求不平衡。相反,Envoy会计算可以直接路由到上游群集的本地区域的请求的百分比。其余的请求被路由到跨区域。特定区域是根据区域的剩余容量(该区域将获得一些本地区域业务量并且可能具有特使可用于跨区域业务量的额外容量)来选择。
  • 发起群集本地区域百分比小于上游群集中的百分比。在这种情况下,上游集群的本地区域可以获得来自原始集群本地区域的所有请求,并且还有一定的空间允许来自发起集群中其他区域的流量(如果需要)。

请注意,使用多个优先级时,区域感知路由当前仅支持P = 0。

负载平衡器子集

特使可能被配置为根据附加到主机的元数据将上游集群中的主机划分为子集。路由然后可以指定主机必须匹配的元数据以便由负载平衡器选择,并且可以选择回退到预定义的一组主机(包括任何主机)。


子集使用集群指定的负载平衡器策略。原来的目标策略可能不能与子集一起使用,因为上游主机事先不知道。子集与区域感知路由兼容,但请注意,使用子集可能很容易违反上述的最小主机条件。


如果子集已配置且路由未指定元数据或没有与元数据匹配的子集,则子集负载均衡器将启动其后备策略。默认策略是NO_ENDPOINT,在这种情况下,请求失败,就好像群集没有主机一样。相反,ANY_ENDPOINT后备策略会在群集中的所有主机之间进行负载均衡,而不考虑主机元数据。最后,DEFAULT_SUBSET会导致回退在与特定元数据集匹配的主机之间进行负载均衡。


子集必须预定义为允许子集负载均衡器有效地选择正确的主机子集。每个定义都是一组键,可以转换为零个或多个子集。从概念上讲,每个具有定义中所有键的元数据值的主机都将被添加到特定于其键值对的子集中。如果没有主机拥有所有的密钥,那么定义就不会产生子集。可以提供多个定义,并且如果单个主机匹配多个定义,则其可以出现在多个子集中。


在路由期间,路由的元数据匹配配置用于查找特定的子集。如果存在具有由路由指定的确切密钥和值的子集,则该子集用于负载平衡。否则,使用回退策略。因此,集群的子集配置必须包含与给定路由具有相同密钥的定义,以便发生子集负载平衡。


此功能只能使用V2配置API启用。而且,主机元数据仅在使用群集的EDS发现类型时才受支持。子集负载平衡的主机元数据必须放在过滤器名称“envoy.lb”下。同样,路由元数据匹配条件使用“envoy.lb”过滤器名称。主机元数据可以是分层的(例如,顶级密钥的值可以是结构化值或列表),但子集负载平衡器仅比较顶级密钥和值。因此,当使用结构化值时,如果主机的元数据中出现相同的结构化值,那么路线的匹配条件只会匹配。

例子

我们将使用所有值都是字符串的简单元数据。假定定义了以下主机并将其与集群关联:

Host Metadata
host1 v: 1.0, stage: prod
host2 v: 1.0, stage: prod
host3 v: 1.1, stage: canary
host4 v: 1.2-pre, stage: dev

集群可以启用子集负载平衡,如下所示:

---name: cluster-nametype: EDSeds_cluster_config:
  eds_config:
    path: '.../eds.conf'connect_timeout:
  seconds: 10lb_policy: LEAST_REQUESTlb_subset_config:
  fallback_policy: DEFAULT_SUBSET
  default_subset:
    stage: prod
  subset_selectors:
  - keys:
    - v
    - stage
  - keys:
    - stage

下表介绍了一些路由及其在集群中的应用结果。通常,匹配标准将与匹配请求的特定方面的路由一起使用,例如路径或报头信息。

Match Criteria Balances Over Reason
stage: canary host3 Subset of hosts selected
v: 1.2-pre, stage: dev host4 Subset of hosts selected
v: 1.0 host1, host2 Fallback: No subset selector for “v” alone
other: x host1, host2 Fallback: No subset selector for “other”
(none) host1, host2 Fallback: No subset requested

元数据匹配标准也可以在路由的加权群集上指定。来自所选加权群集的元数据匹配条件将与路线中的条件合并并覆盖该条件:

Route Match Criteria Weighted Cluster Match Criteria Final Match Criteria
stage: canary stage: prod stage: prod
v: 1.0 stage: prod v: 1.0, stage: prod
v: 1.0, stage: prod stage: canary v: 1.0, stage: canary
v: 1.0, stage: prod v: 1.1, stage: canary v: 1.1, stage: canary
(none) v: 1.0 v: 1.0
v: 1.0 (none) v: 1.0


具有元数据的示例主机


具有主机元数据的EDS LbEndpoint:

---endpoint:
  address:
    socket_address:
      protocol: TCP
      address: 127.0.0.1
      port_value: 8888metadata:
  filter_metadata:
    envoy.lb:
      version: '1.0'
      stage: 'prod'

具有元数据标准的示例路线

具有元数据匹配标准的RDS路由:

---match:
  prefix: /route:
  cluster: cluster-name
  metadata_match:
    filter_metadata:
      envoy.lb:
        version: '1.0'
        stage: 'prod'
相关实践学习
SLB负载均衡实践
本场景通过使用阿里云负载均衡 SLB 以及对负载均衡 SLB 后端服务器 ECS 的权重进行修改,快速解决服务器响应速度慢的问题
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
相关文章
|
28天前
|
自然语言处理 监控 Cloud Native
探索微服务架构中的服务网格Service Mesh
【10月更文挑战第7天】服务网格(Service Mesh)是微服务架构中的关键组件,通过在每个服务实例旁部署Sidecar代理,实现服务间通信的管理、监控和安全增强。本文介绍了服务网格的基本概念、核心组件、优势及实施步骤,探讨了其在现代开发中的应用,并提供了实战技巧。
|
3月前
|
运维 负载均衡 监控
探索微服务架构下的服务网格(Service Mesh)实践之路
【8月更文挑战第30天】 在当今日益复杂的分布式系统中,微服务架构已成为众多企业解决系统扩展与维护难题的利器。然而,随着服务的不断增多和网络交互的复杂性提升,传统的微服务管理方式开始显得力不从心。服务网格(Service Mesh)作为一种新兴的解决方案,旨在通过提供应用层的网络基础设施来简化服务间通讯,并增强系统的可观察性和安全性。本文将分享我在采用服务网格技术过程中的经验与思考,探讨如何在现代云原生环境中有效地实施服务网格,以及它给开发和运维带来的变革。
|
3月前
|
消息中间件 负载均衡 Kafka
Kafka 实现负载均衡与故障转移:深入分析 Kafka 的架构特点与实践
【8月更文挑战第24天】Apache Kafka是一款专为实时数据处理和流传输设计的高性能消息系统。其核心设计注重高吞吐量、低延迟与可扩展性,并具备出色的容错能力。Kafka采用分布式日志概念,通过数据分区及副本机制确保数据可靠性和持久性。系统包含Producer(消息生产者)、Consumer(消息消费者)和Broker(消息服务器)三大组件。Kafka利用独特的分区机制实现负载均衡,每个Topic可以被划分为多个分区,每个分区可以被复制到多个Broker上,确保数据的高可用性和可靠性。
63 2
|
4月前
|
存储 分布式计算 大数据
从零到一建设数据中台 - 架构概览
从零到一建设数据中台 - 架构概览
103 1
|
4月前
|
敏捷开发 运维 Cloud Native
云原生架构的演进之路:从容器化到服务网格
在数字化转型的浪潮中,云原生技术以其灵活性、可扩展性和弹性成为企业IT架构的新宠。本文将探讨云原生技术的演进路径,特别是容器化技术和服务网格的发展,以及它们如何共同推动现代应用的开发和部署。通过分析实际案例,我们揭示了云原生技术如何助力企业实现敏捷开发和高效运维,同时指出了未来云原生技术的发展趋势。
|
3月前
|
Cloud Native 安全 云计算
云原生技术的未来:探索服务网格和无服务器架构
随着企业数字化转型的深入,云计算已成为推动业务创新的核心力量。本文将深入探讨云原生技术的最新发展趋势,重点分析服务网格和无服务器架构如何重塑云计算的未来。通过实际案例和技术解析,揭示这些前沿技术如何解决现代应用部署的复杂性,提高系统的可伸缩性和弹性。文章旨在为读者提供云原生领域的深度见解,并激发对云技术未来发展的思考。
94 0
|
4月前
|
负载均衡 监控 Kubernetes
Service Mesh 是一种用于处理服务间通信的基础设施层,它通常与微服务架构一起使用,以提供诸如服务发现、负载均衡、熔断、监控、追踪和安全性等功能。
Service Mesh 是一种用于处理服务间通信的基础设施层,它通常与微服务架构一起使用,以提供诸如服务发现、负载均衡、熔断、监控、追踪和安全性等功能。
|
4月前
|
Kubernetes Cloud Native 持续交付
云原生架构的核心组成部分通常包括容器化(如Docker)、容器编排(如Kubernetes)、微服务架构、服务网格、持续集成/持续部署(CI/CD)、自动化运维(如Prometheus监控和Grafana可视化)等。
云原生架构的核心组成部分通常包括容器化(如Docker)、容器编排(如Kubernetes)、微服务架构、服务网格、持续集成/持续部署(CI/CD)、自动化运维(如Prometheus监控和Grafana可视化)等。
|
4月前
|
Kubernetes Cloud Native Docker
云原生架构的演进:从容器化到服务网格
本文深入探讨了云原生技术从最初的容器化技术,如Docker和Kubernetes,发展到现代的服务网格架构,如Istio。文章将通过分析云原生技术的演进路径,揭示其在处理微服务复杂性、流量管理和安全性方面的优势。我们将通过具体案例展示服务网格如何优化分布式系统的性能,并预测未来云原生技术的发展趋势。
46 2
|
4月前
|
敏捷开发 设计模式 运维
探索微服务架构中的服务网格
【7月更文挑战第30天】在现代软件工程中,微服务架构因其灵活性和可扩展性而备受推崇。然而,随着系统规模的扩大,服务之间的通信和管理变得日益复杂。服务网格作为解决这一问题的新兴技术,提供了一种透明、可靠的服务到服务通信方式。本文将深入探讨服务网格的核心概念、实现原理以及其在微服务架构中的应用实践,为读者呈现一个关于如何利用服务网格优化微服务间通信的全景视图。
46 0
下一篇
无影云桌面