环境
deepin jdk1.8 linkerd 1.0.2
部署
创建服务app1
mkdir /data/linkerd_tmp1/app1cd /data/linkerd_tmp1/app1echo '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: 9990routers:- 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/app2cd /data/linkerd_tmp1/app2echo 'app2' > index.html/usr/bin/python -m SimpleHTTPServer 9998##这里笔者使用python 快速启动了一个占用端口为9999的服务.curl http://127.0.0.1:9998## 返回app1,服务正常
修改linkerd配置,使之代理app2
admin: port: 9990routers:- 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: 9990routers:- 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: 9990namers:- kind: io.l5d.fs rootDir: rootrouters:- protocol: http dtab: | /svc => /#/io.l5d.fs; label: int servers: - port: 4140 ip: 0.0.0.0
命令行:
root@superwen2-pc:/data/linkerd_tmp2/root# lsroot@superwen2-pc:/data/linkerd_tmp2/root# echo '127.1 9999' > app1root@superwen2-pc:/data/linkerd_tmp2/root# cat app1 127.1 9999root@superwen2-pc:/data/linkerd_tmp2/root# http_proxy=http://127.0.0.1:4140/ curl http://app1app1root@superwen2-pc:/data/linkerd_tmp2/root# echo '127.1 9998' > app1root@superwen2-pc:/data/linkerd_tmp2/root# cat app1 127.1 9998root@superwen2-pc:/data/linkerd_tmp2/root# http_proxy=http://127.0.0.1:4140/ curl http://app1app2root@superwen2-pc:/data/linkerd_tmp2/root# echo -e '127.1 9999\n127.1 9998' > app1root@superwen2-pc:/data/linkerd_tmp2/root# cat app1127.1 9999127.1 9998root@superwen2-pc:/data/linkerd_tmp2/root# http_proxy=http://127.0.0.1:4140/ curl http://app1app1root@superwen2-pc:/data/linkerd_tmp2/root# http_proxy=http://127.0.0.1:4140/ curl http://app1app2
执行下面命令,返回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' > app1root@superwen2-pc:/data/linkerd_tmp2/root# http_proxy=http://127.0.0.1:4140/ curl http://app1app2
2.不能使用下面这种配置了,linkerd解析到了这层,不会再去递归解析/svc/app2地址,而是直接转发了.
127.1 9999/svc/app2
- 由于Java中的文件监视器的隐含，该namer消耗大量CPU，不适合生产使用。