环境

deepin jdk1.8 linkerd 1.0.2

部署

创建服务app1

mkdir /data/linkerd_tmp1/app1

cd /data/linkerd_tmp1/app1

echo 'app1' > index.html

/usr/bin/python -m SimpleHTTPServer 9999

##这里笔者使用python 快速启动了一个占用端口为9999的服务.

curl http://127.0.0.1:9999

## 返回app1,服务正常

linkerd配置,通过linkerd访问app1服务

笔者linkerd安装目录:/opt/soft/linkerd-1.0.2/ 配置目录:/data/linkerd_tmp1/config.yaml

配置如下

admin:

port: 9990

routers:

- protocol: http

servers:

- ip: 0.0.0.0

port: 4140

dtab: >-

/svc/app1 => /$/inet/127.1/9999;

label: app

启动

/opt/soft/linkerd-1.0.2/linkerd-1.0.2-exec /data/linkerd_tmp1/config.yaml

访问

http_proxy=http://127.0.0.1:4140/ curl http://app1

##返回app1,正常linkerd通过app1代理9999端口服务成功.

同理配置app2服务.使用端口9998,返回app2

mkdir /data/linkerd_tmp1/app2

cd /data/linkerd_tmp1/app2

echo 'app2' > index.html

/usr/bin/python -m SimpleHTTPServer 9998

##这里笔者使用python 快速启动了一个占用端口为9999的服务.

curl http://127.0.0.1:9998

## 返回app1,服务正常

修改linkerd配置,使之代理app2

admin:

port: 9990

routers:

- protocol: http

servers:

- ip: 0.0.0.0

port: 4140

dtab: >-

/svc/app1 => /$/inet/127.1/9999;

/svc/app2 => /$/inet/127.1/9998; #多了这行,app2代理9998端口服务.

label: app

重启linkerd服务

http_proxy=http://127.0.0.1:4140/ curl http://app2

##返回app2,正常linkerd通过app1代理9998端口服务成功.

修改linkerd配置,使访问app1服务的流量分50%到app2

admin:

port: 9990

routers:

- protocol: http

servers:

- ip: 0.0.0.0

port: 4140

dtab: >-

/svc/app1 => /$/inet/127.1/9999;

/svc/app2 => /$/inet/127.1/9998;

/svc/app1 => 5 * /$/inet/127.1/9999 & 5 * /svc/app2;

label: app

重启linkerd服务.

for k in $( seq 1 100 ); do http_proxy=http://127.0.0.1:4140/ curl http://app1; done

循环100次访问app1,可以从linkerd admin管理页面看到两个服务的访问频率大致平衡

将比例切换为2:8.

/svc/app1 => 2 * /$/inet/127.1/9999 & 8 * /svc/app2;

循环100次结果如下.

紫色线条为app2服务,与app1访问频比为2:8

使用namer动态变更dtab

上面讲了修改配置文件重启的方式,但是这种方式是不可取的,在生产环境中,每时每刻都有请求,每次变更都要重启造成的影响太大了.

使用namer参数,将服务发现从配置中摘取出来,每次变动不需要修改配置.

基于文件的服务发现机制. io.l5d.fs

任然是上面两个服务 app1: 9999 app2: 9998

配置文件地址: /data/linkerd_tmp2

config.yaml配置如下

admin:

port: 9990

namers:

- kind: io.l5d.fs

rootDir: root

routers:

- protocol: http

dtab: |

/svc => /#/io.l5d.fs;

label: int

servers:

- port: 4140

ip: 0.0.0.0

命令行:

root@superwen2-pc:/data/linkerd_tmp2/root# ls

root@superwen2-pc:/data/linkerd_tmp2/root# echo '127.1 9999' > app1

root@superwen2-pc:/data/linkerd_tmp2/root# cat app1

127.1 9999

root@superwen2-pc:/data/linkerd_tmp2/root# http_proxy=http://127.0.0.1:4140/ curl http://app1

app1

root@superwen2-pc:/data/linkerd_tmp2/root# echo '127.1 9998' > app1

root@superwen2-pc:/data/linkerd_tmp2/root# cat app1

127.1 9998

root@superwen2-pc:/data/linkerd_tmp2/root# http_proxy=http://127.0.0.1:4140/ curl http://app1

app2

root@superwen2-pc:/data/linkerd_tmp2/root# echo -e '127.1 9999\n127.1 9998' > app1

root@superwen2-pc:/data/linkerd_tmp2/root# cat app1

127.1 9999

127.1 9998

root@superwen2-pc:/data/linkerd_tmp2/root# http_proxy=http://127.0.0.1:4140/ curl http://app1

app1

root@superwen2-pc:/data/linkerd_tmp2/root# http_proxy=http://127.0.0.1:4140/ curl http://app1

app2

执行下面命令,返回app1和app2的数量大致相同.

for k in $( seq 1 100 ); do http_proxy=http://127.0.0.1:4140/ curl http://app1; done

注意的一些坑.

如果配置写错了,并不会生效,还是会使用上次正确的配置.例如

root@superwen2-pc:/data/linkerd_tmp2/root# echo 'asdfad' > app1

root@superwen2-pc:/data/linkerd_tmp2/root# http_proxy=http://127.0.0.1:4140/ curl http://app1

app2

2.不能使用下面这种配置了,linkerd解析到了这层,不会再去递归解析/svc/app2地址,而是直接转发了.

127.1 9999

/svc/app2

由于Java中的文件监视器的隐含，该namer消耗大量CPU，不适合生产使用。