原创文章，转载请注明出处。由于本人水平有限，文中错漏之处在所难免，希望大家多多批评指正。本文的内容过多，我们分成四篇聊，此为第二篇。
通过前面的分析与对比，我们最终选择了SkyWalking（下文简称SW）来做链路监控。考虑到SW是开源的系统，从以往的经历来看，开源的并且达到了系统级别的，一般都是有雷的，不注意的话偷偷爆个雷，所有关联的系统可能都会受到影响，严重的时候会让你很后悔使用了这个系统。而如果使用的是分布式追踪系统的话，在暴雷时会更加的严重，因为它不是独立部署的，是要集成到每一个系统实例的容器中，出问题的时候会直接牵连到容器内的其他服务。所以本着小心求证的原则，在正式上线使用之前，我们先在测试环境简单部署一套SW，初步尝试下系统接入，既有助于对数据体量、集群配置和工作人力的预估，也可以探探雷，提前发现问题，实际验证下是否适合我们，方便我们后续工作的风险把控。整个部署过程我们使用MacOS Mojave操作系统进行演示，可能与Linux会存在细微差别。
先说说背景
- 机器：因为资源紧张，审批从严，只拿到了1台虚拟机。
- 硬件[虚拟机]：4C/8GB/50GB[HDD]/100Mbps[LAN]
- 软件[64-Bit]：CentOS[7.4]/JDK[1.8.0_91]/Docker[18.09.7]/Docker Compose[1.18.0]
- CD工具：公司自研的系统，全界面化操作，这里就叫他tard吧。提供了容器管理，docker镜像配置，环境变量配置，打包，上下线等功能。
- SkyWalking：使用Apache官方Docker镜像，版本号6.3.0。友情提示，推荐大家使用6.3.0或者更高的版本，因为低版本有个雷，后面再详细聊。
提到需要简单、快速的部署，我们首先想到的就是使用Docker，而且SW是有官方Docker镜像的，可以放心的拿来使用，省去了我们自己做镜像的时间。这次我们主要使用Docker和Docker Compose部署SW，包括服务编排，容器发布与管理。读者需要对基本的Docker命令有所了解，如果没有使用过，这里强推一波Docker。Docker真的是个好东西啊，超级好用，属于那种一旦用过就离不开的程序，也有助于我们的思维扩展，强烈建议大家学习一下。
部署SkyWalking服务
我们只有1台机器，只有8个G的内存，初步猜测只能部署单机版，不过我们还是想以集群的方式部署SW。因为集群最能真实的模拟线上的环境，也比单机版更容易暴露问题，而且1台机器也不是不可以部署集群，这样的话我们就再挣扎下，先统计集群版和单机版都需要部署多少个实例，看看有没有运行集群的可能性。
最小集群配置 skywalking-ui skywalking-oap-server ZooKeeper Elasticsearch 共计 实例数量 2 2 3 2 9 最小单机配置 skywalking-ui skywalking-oap-server ZooKeeper Elasticsearch 共计 实例数量 1 1 0 1 3 结合实例数量和每个实例正常工作大概需要的内存量，可以看到集群和单机的差别还是很大的。考虑到集群版就算可以正常启动，在后面的读写压力下性能也不会太好，内存溢出的概率也很大，所以对这次的情况来说单机版更适合。不过有转机的是，如果大家再仔细的想下，这些组件当中只有Elasticsearch（下文简称ES）对内存的要求比较高，最耗内存，而在平时的使用中我们已经验证过ES集群的读写性能和稳定性了，这次其实可以忽略ES的测试，主要验证SW集群的问题。这样我们就可以采用SW集群 + ES单机混合搭配的方式，减少虚拟机的内存压力，实现集群部署。通过后面的试验，我们发现这种混合的方式是行得通的，而且也很好的满足了我们本次的需求。最终采用的部署配置如下：
集群 + 单机混合配置 skywalking-ui skywalking-oap-server ZooKeeper Elasticsearch 共计 实例数量 2 2 3 1 8 从零部署的过程中实际操作有很多，这里省略虚拟机的网络配置、防火墙配置、处理FD限制等操作系统级别的操作，省略JDK、Docker、Docker Compose等软件的安装操作，请大家自行安装调试，我们直接上关键的部分。
提前下载好镜像文件（这步可以省略）
# 我们使用6.3.0版本的SW，下载过程如图1所示。 macos$ docker pull apache/skywalking-ui:6.3.0 macos$ docker pull apache/skywalking-oap-server:6.3.0
图1 使用docker下载镜像# 思考下ZooKeeper使用什么版本？ # skywalking-oap-server:6.3.0的镜像文件中有一个oap-lib目录，存放了所有的依赖。 # 我们发现它使用的ZooKeeper客户端版本号是3.4.10，如图2所示。 # 所以ZooKeeper服务最好也使用3.4.10版本 macos$ docker pull zookeeper:3.4.10
图2 skywalking-oap-server:6.3.0依赖的ZooKeeper版本# 6.3.0版本的SW只能兼容6.3.2或者更高版本的ES，如图3所示。 # 因为运维同学使用的是6.4.2版本，我们最好和运维保持一致。 macos$ docker pull elasticsearch:6.4.2
图3 SkyWalking官网对ES的版本要求说明# 下载完成后，应该可以看到如图4所示的四个镜像文件。 macos$ docker images
图4 查看本地镜像- 使用Docker Compose编排服务
我们使用的docker-compose.yml配置文件
version: "3" services: elasticsearch: image: elasticsearch:6.4.2 container_name: elasticsearch restart: always ports: - 9200:9200 - 9300:9300 ulimits: memlock: soft: -1 hard: -1 environment: - discovery.type=single-node - bootstrap.memory_lock=true - "ES_JAVA_OPTS=-Xms1536m -Xmx1536m -Xmn512m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m" - TZ=Asia/Shanghai oap1: image: apache/skywalking-oap-server:6.3.0 container_name: oap1 depends_on: - elasticsearch - zk1 - zk2 - zk3 links: - elasticsearch - zk1 - zk2 - zk3 restart: always ports: - 11801:11800 - 12801:12800 environment: SW_CLUSTER: zookeeper SW_CLUSTER_ZK_HOST_PORT: zk1:2181,zk2:2181,zk3:2181 SW_STORAGE: elasticsearch SW_STORAGE_ES_CLUSTER_NODES: elasticsearch:9200 SW_STORAGE_ES_INDEX_SHARDS_NUMBER: 1 SW_STORAGE_ES_INDEX_REPLICAS_NUMBER: 0 TZ: Asia/Shanghai oap2: image: apache/skywalking-oap-server:6.3.0 container_name: oap2 depends_on: - elasticsearch - zk1 - zk2 - zk3 links: - elasticsearch - zk1 - zk2 - zk3 restart: always ports: - 11802:11800 - 12802:12800 environment: SW_CLUSTER: zookeeper SW_CLUSTER_ZK_HOST_PORT: zk1:2181,zk2:2181,zk3:2181 SW_STORAGE: elasticsearch SW_STORAGE_ES_CLUSTER_NODES: elasticsearch:9200 SW_STORAGE_ES_INDEX_SHARDS_NUMBER: 1 SW_STORAGE_ES_INDEX_REPLICAS_NUMBER: 0 TZ: Asia/Shanghai ui1: image: apache/skywalking-ui:6.3.0 container_name: ui1 depends_on: - oap1 - oap2 links: - oap1 - oap2 restart: always ports: - 8081:8080 environment: SW_OAP_ADDRESS: oap1:12800,oap2:12800 TZ: Asia/Shanghai ui2: image: apache/skywalking-ui:6.3.0 container_name: ui2 depends_on: - oap1 - oap2 links: - oap1 - oap2 restart: always ports: - 8082:8080 environment: SW_OAP_ADDRESS: oap1:12800,oap2:12800 TZ: Asia/Shanghai zk1: image: zookeeper:3.4.10 restart: always container_name: zk1 ports: - 2181:2181 environment: ZOO_MY_ID: 1 ZOO_SERVERS: server.1=zk1:2888:3888 server.2=zk2:2888:3888 server.3=zk3:2888:3888 zk2: image: zookeeper:3.4.10 restart: always container_name: zk2 ports: - 2182:2181 environment: ZOO_MY_ID: 2 ZOO_SERVERS: server.1=zk1:2888:3888 server.2=zk2:2888:3888 server.3=zk3:2888:3888 zk3: image: zookeeper:3.4.10 restart: always container_name: zk3 ports: - 2183:2181 environment: ZOO_MY_ID: 3 ZOO_SERVERS: server.1=zk1:2888:3888 server.2=zk2:2888:3888 server.3=zk3:2888:3888创建容器，启动服务
# 指定配置文件docker-compose.yml的路径，在后台启动所有服务。 # 如图5所示，会显示容器的创建结果。 macos$ docker-compose -f ./docker-compose.yml up -d
图5 启动所有服务# 查看容器是否启动成功，如图6所示。 macos$ docker ps
图6 查看容器状态
到这里SW集群就部署完毕了。有些同学可能会发现在集群启动的过程中oap1和oap2两个容器会经常的重启，别慌，不是你做错了什么，这个是正常现象，等一会就稳定了。
部署SkyWalking Agent
推荐到SkyWalking官网下载Agent的安装包，网速还是不错的。请根据各自的操作系统下载对应的安装包，如图7所示。
图7 SW安装包，二选一我们下载的安装包是完整的All-In-One安装包，解压后我们会看到安装包内有Agent，OAP Server，Web UI三个组件。由于我们只需要Agent，所以只提取agent文件夹就可以了，如图8所示。
图8 从安装包中提取agent- 拿到了Agent，接下来需要做的是把Agent和我们的系统部署到同一个容器中去，我们日常会使用一些CI工具，再结合CD工具tard将系统部署到私有云上。这次呢，我们还是使用tard演示Agent的部署过程，而不是使用原生的Docker。
说到这里可能会有一部分同学觉得不太理解，尤其是很少使用Docker，对部署流程了解较少的同学，他们可能会疑惑：”读者原本是想参考文章中的代码、命令来尝试部署测试，tard是你们公司的内部系统，我们没法使用，如果用更加通用的Docker会不会更好？“。
解释这个问题前先简单说下背景。和很多的公司一样，我们也是有一套标准的打包发布流程的，tard有一套自己的使用规范，关于这一点曾经与运维的同学简单了解过。出于安全的考虑，tard会要求所有的系统只能使用公司统一的基础镜像，或者以基础镜像为底做出来的其他镜像，tard也会限制很多的docker命令不可以使用。同时tard自身还有一些功能待完善，比如在创建docker镜像的时候，基础镜像只支持解压War包，暂不支持其他的压缩格式，所以tard只支持添加War包；容器启动时唯一可以执行的命令是运行Tomcat等等。（PS：tard为部分功能是留了口子的，如果项目组有什么特殊需求可以走运维部门的技术支持流程，由运维同学再细看是否可以处理。有些限制是可以解决的，有些暂时还是不可以，具体的细节没有深入了解。）
- 所以从发布流程来说，我们是一定要使用tard来发布的，使用tard演示可以为公司的同事提供一些参考，也可以还原我们当时遇到的一些问题和解决思路，分享这些我觉得是很有意义的。同时在tard现有的限制下部署Agent还是有些难度的，可以说这也是一个雷，不过这些问题的存在也会促使我们思考，这也是让我觉得好玩的地方，可能是个人的恶趣味吧。而且tard和Docker的相似度很高，只要有一点Docker的基础就没什么问题，所以选择了tard来演示。这里我们最主要来理解都需要做什么，具体使用什么实现都可以的。
要实现前文说的整个接入过程无任何代码侵入，只需要简单修改镜像的配置就可以完成接入的这个目标，我们需要将Agent做到基础镜像里面，这样只需要修改发布系统依赖的基础镜像就可以使用Agent了。常规做法一般是将Agent文件夹压缩成tar包或者zip包，上传，然后在镜像内解压就可以了。可是tard只支持添加War包，怎么办？这是我们遇到的一个问题，请大家思考一下再向下阅读。
- tard只支持添加War包怎么办？很简单，那就打成War包喽。很多人会觉得有点别扭，有点反常规，尤其是有技术洁癖的同学。我觉得别想太多，能解决问题就是好办法，规则已经制定了，无法打破我们就想想怎么利用规则解决问题吧。既然是研发熟悉的War包，那我们走常规的研发流程就可以了。
考虑到大概率上只会做一次基础镜像，我们就尽量简单点，不需要走申请创建新代码仓库的审批流程，最好可以利用已有的Web系统，复用原有的打包配置。这样我们从现有系统的git代码仓库拉出来了一个分支，命名为sw-agent。
保留Maven中使用maven-assembly-plugin插件打包的配置，删除其他无关代码。将SW安装包中的agent文件夹添加到项目中，commit、push到仓库，如图9所示。
图9 将sw的agent文件夹添加到分支中- 新建分支打包配置，指定要编译、打包的分支与War包生成路径，后面再结合tard的界面化操作，可以实现一键完成编译、打包、上传操作。
图10 打包的分支配置、War包配置
我们能够拿到sw-agent.war，就可以开始做基础镜像了。
# Dockerfile FROM 公司统一的基础镜像:JDK8+Tomcat8版本 ADD sw-agent.war /opt WORKDIR /opt # 解压后删除War包多余的文件，最终的结果就和使用tar包、zip包一样了 RUN jar xf sw-agent.war && rm -rf sw-agent.war META-INF #做好的镜像我们暂时命名为skywalking-agent-6.3:1.0修改发布系统的基础镜像，然后再将agent加入到Tomcat的运行时参数里面。
# 修改基础镜像，使用skywalking-agent-6.3:1.0 FROM skywalking-agent-6.3:1.0 省略......# 修改Tomcat的环境配置脚本setenv.sh 省略...... # 加入这一段脚本代码 AGENT_BOOTSTRAP="/opt/skywalking/agent/skywalking-agent.jar" if [ -f $AGENT_BOOTSTRAP ]; then # SW_AGENT_NAME：我们要追踪的系统的名称。 # SW_AGENT_COLLECTOR_BACKEND_SERVICE：SW OAP服务地址和端口号。 CATALINA_OPTS="$CATALINA_OPTS -DSW_AGENT_NAME=${SW_AGENT_NAME} -DSW_AGENT_COLLECTOR_BACKEND_SERVICES=${SW_AGENT_COLLECTOR_BACKEND_SERVICES} -javaagent:$AGENT_BOOTSTRAP" fi- 现在我们可以让系统跑起来，验证下接入是否成功了。
在系统启动之前，我们需要先为上面留的两个运行时变量赋值。我个人更喜欢以环境变量的方式配置系统，简单、改动更加方便，具体的配置如下所示。
# 指定被追踪的系统的名称，不可重复。 SW_AGENT_NAME=ATS-WZ # Agent需要将生产的数据上报给我们部署的服务实例oap1，oap2。 # 使用过程中在这里发现了一个雷，标记下。 SW_AGENT_COLLECTOR_BACKEND_SERVICES=127.0.0.1:11801,127.0.0.1:11802实例启动成功以后，打开SW的首页[ http://127.0.0.1:8081, http://127.0.0.1:8082 ]，UI文本会默认使用英文显示，可以通过右下角的中英文切换功能切换语言。如果能在当前服务中看到我们配置的系统名称ATS-WZ，就表示接入成功了，如图11所示，至此SkyWalking Agent我们就部署完毕了。
图11 SW可以识别被追踪的系统了
简单说下探到的雷吧
整个的接入、使用与测试过程中我们发现了几个雷，包括上面说的在低版本的SW上可能会出现一些问题的雷。我们都一一标记、收集整理了，打算在后面总结的时候我们再集中一一拆解，本节只是试验与探雷，至于排雷后面再聊。不过有一些雷可能会导致接入出现问题，我们可以先简单说一下，以免影响大家使用。
- 问题表现：SW首页没有数据，包括当前服务、端点、实例都没有数据，可以说接入失败了。
大概率是OAP服务挂了，可以检查一下。
- 如果是6.3以下的版本，在OAP服务重启以后可能还是没有数据的。因为低版本的SW要求在OAP重启以后，所有的agent端都要重启，重新接入，否则是没有数据的。这是一个比较坑的问题，建议SW官网能够加上这个使用说明，这个问题带来的后果就是如果OAP服务挂了，重启，那么要通知所有的接入方重启自己的系统。一个是很麻烦，一个是可能会影响我们的服务。还好的是在6.3版本升级了相关功能，解决了这个问题，所以强烈建议使用或者升级到6.3以上版本。
问题表现：SW首页没有数据，并且在agent日志中可以看到如图12所示的报错。
图12 Agent日志报错很大的可能是我们配置的环境变量SW_AGENT_COLLECTOR_BACKEND_SERVICES有问题。一些同学会想的很全面，他们考虑到了负载均衡的问题，使用的是OAP集群的域名，考虑的很好很充分，只不过SW不支持。我们通过查看SW的源码可以发现，SW是不支持域名的，只支持 ip1:port1,ip2:port2 这种格式，如图13所示。
图13 从源码中可以推断出OAP服务地址的配置格式- 至于OAP集群的负载均衡问题，我们不需要自建类似Nginx+OAP这种的反向代理集群。查看源码可以发现Agent采用的是客户端软负载均衡，默认使用随机算法选择需要连接的OAP服务实例。
问题表现：SW页面上有很多的区域都没有数据，或者说响应很慢。打开Chrome浏览器的开发者工具可以发现，SW页面发出的很多接口请求都超时失败了，超时时间大约为10秒。查看ui1和ui2的日志可看到如图14所示的错误。
图14 UI日志中的错误这个问题一般是因为连接、请求超时，主要问题在于OAP服务或者ES性能不足，造成连接超时、响应超时甚至无响应。从根本上解决这个问题的办法，一般是调整优化OAP服务或者ES的性能。
我们也可以使用一个临时方案，UI的时间不够，那我们就延长下UI的时间。可以修改UI的超时配置，默认为10秒，测试和生产环境都可以适当的延长这个值，我们将ReadTimeout延长到了30秒。同时增加ConnectTimeout配置，也设置为30秒，如图15所示。
图15 延长超时时间
问题表现：在追踪页面里，我们可以看到所有被追踪接口的调用链路。我们可以再前进一步，打开某一个接口的调用链路详情，我们希望可以拿到这个接口的入参和出参。不过可惜的是，大多时候我们是拿不到这个接口的入参和出参的，如图16所示。
图16 在接口详情里面拿不到接口的入参和返参- 因为SW的默认实现在很多情况下是不会记录这些数据的，需要定制开发，具体如何做我们后面再聊。
总结
在整个的安装、使用、测试过程中，我们遇到了一些问题，不过幸运的是通过查阅官方文档以及阅读SW源码，我们发现问题是可控的，是可以解决的。这次也让我们尝到了使用熟悉的技术带给我们的好处，尤其是在这种时间紧迫的情况下，让我们可以做到对项目更可控，更有信心。在验证完SW的适用性、稳定性和读写性能以后，我们将针对SW做一定的开发与扩展以满足我们的业务需要，这些内容让我们慢慢再聊。
参考资料
Tard使用文档
SkyWalking官方文档