English | 简体中文
从满足本次转发要求的服务实例集中, 通过一定的均衡策略,选取一个实例返回给主调方,供主调方进行服务请求发送。
负载均衡策略一般分为2类:
无状态负载均衡策略,主要特点是每次负载均衡获取到的结果是由具体的负载均衡算法决定。目的是让负载均匀的分发到后端节点。
主要负载均衡策略包括:权重随机,权重轮询等
对于无状态的业务逻辑,为了保证后端节点能够均衡分配请求,此时应该选择权重随机负载均衡策略
有状态负载均衡策略,除了要达到让负载均衡分散到节点的目标以外,还需要实现将同一对象的请求分发到同一个节点。例如业务场景需要将同一个用户的全部请求发送到后端同一个节点处理的情况。
主要负载均衡策略是一致性hash
权重随机负载均衡策略,利用区间算法,基于伪随机因子取模的方式选择对应服务实例。
对于有状态的业务逻辑(比如通过用户ID或者请求ID进行hash分区的),为了保证同key请求能够持续命中同一个物理节点,此时应该选择一致性hash负载均衡策略。
该负载均衡策略基于ketama环算法,每一个服务实例会按照权重分裂成若干个虚拟节点。虚拟节点通过取hash值的方式,映射到长度为2^32的hash环中。
发起查询时,北极星会基于用户传入的hashKey,计算出具体的hash值,然后到环中寻找hash值刚刚好大于传入数据hash值的虚拟节点,并返回其对应的服务实例
该负载均衡策略基于maglev算法(https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/44824.pdf)进行节点分配。
首先为实例集创建一个长度为质数65537的向量表,算法根据节点的权重,将向量表进行填充,直到向量表全部被节点所占满。取节点时则根据用户传值的hashValue取摸的方式,返回对应下标的节点。
算法优点:由于是直接取模寻址,因此算法性能相比ketama环要高(官方数据是在256K个插槽的情况下,性能是5X到10X的差距)。
算法缺点:当节点下线后,导致迁移的节点数量相比ketama环要多(官方数据为迁移节点数量是ketama的两倍)
该负载需要主调方感知被调方的负载情况,一般用于以下2种场景:
- 持续时间差异较大的业务,比如游戏、直播类业务,这种业务的特点是一个对局持续半个小时以上,且每个对局的时长不一样,假如按照随机方式分配的话,容易造成负载不均。
- 长链接的业务,长链接的情况下,业务往往会持续往会话保持的机器上发送请求。为避免连接聚积导致性能问题,需要往最小负载机器建立长链接,且当机器负载超标后,切换连接到其他机器。
一般需要capacity&used两个指标, 被调方通过携带附件的方式,将负载数据告知主调端,主调端实时更新本地的权重属性,按权重进行负载均衡。
名称 | 类型 | 描述 | 是否必选 |
---|---|---|---|
namespace | string | 规则所属的命名空间 | 是 |
service | string | 规则所属的服务 | 是 |
lb_policy | enum | 负载均衡策略 | 是 |
lb_config | any | 负载均衡的配置,如果不填则使用默认配置 | 否 |