关于 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 是什么的，可以看一下百度百科的解释。