关于takin-data,你想知道的都在这里(一)启动命令篇

通过docker部署体验takin的小伙伴都应该知道,在安装部署手册(https://docs.shulie.io/docs/opensource/opensource-1d40ib39m90bu) 中有提到:在启动surge-deploy任务前,需要将启动命令中的ip参数替换为docker容器所在宿主机的ip,很多小伙伴都在这里踩过坑,有忘了修改的,有改错的,还有不知道怎么修改的,这些都会导致各种小伙伴们在体验产品的过程中,遇到各种各种的问题。像这样:

应用agent日志中提示找不到日志节点

在这里插入图片描述

还有像这样:

小伙伴满心欢喜压测完,却发现请求流量明细真空

在这里插入图片描述

其实这些,都跟surge-deploy任务是否正确启动有着很大的关系,今天就来给大家说一说surge-deploy配置启动命令的正确姿势!

首先,在安装完镜像进入容器中,我们能看到这样的目录结构(当前目录为/data目录):

在这里插入图片描述

如果发现自己的目录结构和图上有区别的小伙伴请不要着急,初次安装镜像需要一定的初始化时间,一些文件可能还未被解压出来,这个时间一般是10分钟左右~

和图上目录结构一致的小伙伴们,恭喜你们,你们离成功又更近了一步啦!我们看到文件夹中有一个install.sh文件,通过vi命令打开:

在这里插入图片描述

我们看到在行尾处(绿色框框出来的)就是我们的surge-deploy启动命令了,这个时候大家可以把这个命令复制一下,后续我们修改就要用到啦。

nohup java -jar surge-deploy-1.0-jar-with-dependencies.jar '{"172.17.0.2":"192.168.1.138"}' > surge.out 2>&1 & 首先我们分析一下这个命令,nohup xxxxx,在linux中nohup命令用于不挂断地运行命令,而学过java的小伙伴都知道java -jar 用于启动一个jar包,而这里的surge-deploy-1.0-jar-with-dependencies.jar就是我们提供的jar包,然后我们先忽略那串令人头疼的ip配置,我们看到在后面是:

  >surge.out  2>&1 &

在linux中> 符号用作输出符,这里的意思就是将java -jar 启动的日志输出到surge.out文件,所以大家如果想要查看surge-deploy的运行日志,就可以查看surge.out文件啦,再往后,我们看到有一个2>&1, 2>1? 2当然大于1,为什么还要&?哈哈,这里其实不是大于符号,在linux中,2代表错误输出,1代表标准输出,这里的含义就是将错误输出重定向到标准输出,简单理解,就是错误日志和正常日志都被输出到一起!

细心的小伙伴发现了,为什么末尾还有一个&,这个&怎么就跟我们过不去了!哈哈,这里不能怪&,他的作用可重要。前面我们说到nohup代表不挂断地运行命令,但是这个操作仍是在前台执行的,我们不能一直盯着他不做其他事呀,所以&就和nohup巧妙的结合起来了,他们在一起,就代表这个命令将会在后台默默地执行,谁也干扰不了,像不像海枯石烂?

题外话,我们总结一下,整体的启动命令的含义就是静默启动surge-deploy任务,并将所有日志输出到surge.out文件。是不是很简单?有人问:不是还有那串烦人的ip吗?哈哈是的,其实这里不配置ip也是可以的,为什么呢,这里就要解释下surge-deploy在takin产品中的作用了。

surge-deploy作为takin-data的运行模块,实际上是承担了一个接收linkAgent推送日志,并进行数据存储和计算的角色。有人问它计算了什么?在我们开源的第一个版本里,我们的链路梳理功能由于准备不充分,其实是并没有开放出来的;而承担链路梳理功能的,就是我们的takin-data模块!为我们的takin打call!告诉大家一个好消息,下个月我们就会发布开源第二次版本,而这次版本链路梳理功能就会隆重登场拉,这里给大家剧透下,看张图,提前体验下我们强大的链路梳理功能:

在这里插入图片描述

应用调用关系一目了然有木有!!好了,言归正传,大家现在体会到takin-data模块的重要性了吧,回到那个ip上来,takin-data目前是利用netty服务和linkAgent进行网络通信,从而实现接收linkAgent传输过来的的日志信息,而我们作为服务端,需要对外暴露服务地址和端口。所以,目前我们是根据本机的ip地址进行服务注册以及暴露的,但是由于我们的部署环境是在docker容器内部,所以获取到的本机ip容器是docker网卡虚拟生成的一个ip,也就是参数中的172.12.0.2。而对docker有一定了解的人肯定知道,通过在外网,我们是无法直接访问dockerip的,需要用一些特殊手段来进行数据转发。而这里,我们就是通过ip映射的关系来实现数据转发的。

而我为什么说不配置这个ip也可以呢,那当然是将我们的linkAgent也起在容器内部啦,这样就是容器内部的通信,完全可以,没问题。

但是!!!对于有些想要压测自己应用的小伙伴来说,他们的应用可能在公司内网,可能在云服务器上,总而言之,肯定不在容器内,这种情况下默认的服务注册就不能满足我们的需求了。

于是,我们在启动surge-deploy任务的时候通过传入指定ip映射,来实现将实际可被外网访问的ip注册到服务上去,以达到数据通信的目的。

有些小伙伴问:那我配置的外网的ip,可我自己的surge-deploy不还是部署在容器内部吗,不也没用吗?这就要说到docker的通信机制了,细心的小伙伴可能发现我们在安装镜像时候追加了很多端口号,如下:

docker run -d -p 80:80 -p 2181:2181 -p 3306:3306 -p 6379:6379 -p 8086:8086 -p 9000:9000 -p 10032:10032 -p 6628:6628 -p 8000:8000 -p 6627:6627 -p 8888:8888 -p 29900-29999:29900-29999 registry.cn-hangzhou.aliyuncs.com/forcecop/forcecop:v1.0.0 大家看到很多-p了吧,这种方式被称作端口映射,什么意思呢:就是将docker宿主机的端口和容器内部的端口号做一个绑定关系,当外部访问了宿主机的xxxx端口,则请求将会被自动转发到容器内部的xxxx端口。说到这里,是不是各位小伙伴们都明白了!!!于是,我们就实现了外部数据的传输!

说到这里,大家是不是对这个ip配置都了如指掌拉,我们总结下:如果是同一网络环境中的linkAgent和surge-deploy通信,大家大可不必配置这个ip映射;如果surge-deploy部署在容器内部,那么ip映射的左边的172.17.0.2大家也不必修改,除非本机上运行了多个docker镜像,导致takin镜像的dockerip不是172.17.0.2,那么这个时候就需要进行修改了。关于ip映射的右边,大家现在应该知道怎么配置了吧,如果是内网环境通信,配置docker宿主机的内网ip即可,如果是外网访问,如阿里云的机器想要访问,那么就应该配置docker宿主机的外网ip。有的小伙伴不知道外网ip是什么的,可以看一下百度百科的解释。 想要了解更多开源产品信息,扫码小树入群交流! 在这里插入图片描述

{{o.name}}
{{m.name}}

猜你喜欢

转载自my.oschina.net/u/5129714/blog/5232245