概述
服务提供者
之前我们使用ngnix搭建了一个服务提供者示例。为了演示负载均衡，我们必须有至少两个及以上的服务提供者提供相同命名的服务。我们来调整下ngnix的配置。
1、新建ngnix配置/etc/nginx/sites-enabled/default2
$ sudo cp /etc/nginx/sites-enabled/default /etc/nginx/sites-enabled/default2
2、修改default2配置，我们使用81端口
$sudo vi /etc/nginx/sites-enabled/default2
#listen 80 default_server; 改为
listen 81;
#listen [::]:80 default_server;改为
listen [::]:81;
#listen 80 default_server;改为
root /var/www/html2;
3、修改index.html 页面
$sudo cp /var/www/html /var/www/html2
$sudo vi /var/www/html2/index.html
It works! 改为 It works too!
4、ngnix 重新加载配置文件
$ sudo ./usr/sbin/ngnix -s reload
5、打开浏览器测试
服务注册
接下来我们要把81端口提供的服务注册到consul服务注册中心去。可以通过配置文件的方式，也可以通过http api。我们就配置文件进行演示：
1、新建配置文件test2.json
$ cp <parent path>/consul.d/test.json <parent path>/consul.d/test2.json
$ vi <parent path>/consul.d/test2.json
{"service":{"id": "test2","name": "test","address": "127.0.0.1","port": 81,"tags": ["dev","test2"]}}
2、关闭并重启consul
$ ./consul agent -dev -ui -node=consul-dev -client=127.0.0.1 -config-dir consul.d
3、查看test服务
linkerd配置
routers:
- protocol: http
#下面为新增配置
client:
loadBalancer:
kind: p2c
maxEffort: 10
重启linkerd
./linkerd conf/linkerd.yaml
演示
执行多次请求
$ curl -H "Host:test" http://127.0.0.1:4140
It works too!
It works too!
It works!
It works!
It works!
It works too!
It works!
loadBalancer配置详解
键 |
默认值 |
说明 |
kind |
p2c |
|
enableProbation |
false |
Round Robin
kind: roundRobin
最基本的轮询负载均衡算法
键 |
默认值 |
说明 |
maxEffort |
5 |
负载均衡器重试多少次后将节点标记为不可用 |
Heap: Least Loaded
kind: heap
Heap负载均衡器请求可以访问到的共享区域，堆中的每个节点维护未完成请求的计数。请求分发的时候递增，当我们接收到响应时递减（注意依赖于延迟）。堆是升序排列允许有效地访问最小负载。Heap负载均衡器继承堆的所有优点（即选择堆的顶部是常数时间，其他常用操作取O（log n））。这种配置有一定的局限性。特别是，在不牺牲堆的性能的情况下，很难使用加权节点或交换出负载度量。更重要的是，堆必须通过每个请求原子化更新，因此堆是高度竞争的资源。
Power of Two Choices: Least Loaded
kind: p2c
P2C负载均衡器解决了堆负载均衡器固有的许多限制，并且是Finagle客户端的负载均衡器。通过采用优美的（令人惊讶的）数学现象，该算法随机地从服务集合中挑选两个节点，并选择这两个节点中的最小负载。通过反复使用这种策略，我们可以期望在任何服务器的最大负载上可管理的上限。然而，由于P2C是完全并发的，P2C负载均衡器的默认负载度量是最小负载的节点，它允许我们以最小的每请求成本有效地实现加权节点或不同的负载度量。
maxEffort 参数（默认值为5）是我们在不重置内部状态的情况下愿意在负载平衡决策上花费的最大“努力”。简单地说，这是负载平衡器能够重试的次数，因为先前选择的节点被标记为不可用（即，**了断路器）。如果重试次数达到maxEffort ，仍然没有找到可用的节点，负载均衡器将使用之前选择的上一个历史节点发送请求。
键 |
默认值 |
说明 |
maxEffort |
5 |
负载均衡器重试多少次后将节点标记为不可用 |
Power of Two Choices: Peak EWMA
kind: ewma
基于P2C负载均衡器，Peak EWMA在服务的请求响应时间（RTT）上使用平均值，RTT对峰值非常敏感。这个平均值对未完成请求的数量加权，有效地提高了每个请求的时间。它被设计为迅速对慢服务作出反应。此负载均衡器适合在服务需要时间来从故障中恢复的场景。因此对于加载中的服务通常是安全的。然而，这种假设在长轮询客户端的存在下崩溃。
键 |
默认值 |
说明 |
maxEffort |
5 |
负载均衡器重试多少次后将节点标记为不可用 |
decayTimeMs |
10 seconds |
延时观察时间窗口 |
Aperture: Least Loaded
kind: aperture
所有前面提到的均衡器在高负载下运行最佳。也就是说，没有足够的并发负载，之前的负载均衡器可以降级为随机选择。Aperture均衡器的目的是弥补这一点。通过采用基于客户端负载的简单反馈控制器，Aperture均衡器平衡服务器的子集来匹配指定的负载带宽。将滞回原理应用于Aperture，以避免快速波动并抑制大负载尖峰的影响。
1、客户端使用与所提供的负载相称的资源。特别是，它不必在大集群中打开每个服务的会话。当所提供的负载和簇容量不匹配时，这尤其重要。
2、它平衡了较少的服务，从而使服务更加温和。这也意味着客户端较少会话建立消耗。
3、它增加了最小负载平衡的功效，为了工作良好，需要并发负载。
键 |
默认值 |
说明 |
maxEffort |
5 |
负载均衡器重试多少次后将节点标记为不可用 |
smoothWin |
5 seconds |
并发负载观察时间窗口 |
lowLoad |
0.5 |
下限带宽 |
highLoad |
2 |
上限带宽 |
minAperture |
1 |
最小Aperture |