微服务系统设计——服务链路跟踪设计

摘要

微服务体系下，一个请求会调用多个服务，整个请求就会形成一个调用链，普通的日志输出是无法将整个体系串联起来，调用过程中某一个节点出现异常，定位排查难度系数增高，这种情况下就需要一个组件，来分析系统性能、展现调用链路，以便出现故障时快速定位并解决问题，由此 APM 工具闪亮登场。

一、APM

全称是Application Performance Management，关注于系统内部执行、系统间调用的性能瓶颈分析，与传统监控软件（比如 Zabbix）只提供一些零散的监控点和指标相比，即便告警也不知道问题是出在哪里。

抛开商业工具先不谈，开源产品就有许多，Pinpoint、Zipkin、CAT、SkyWalking 等，产品间比较，网络中有相当多的资料来解读，本篇案例实战中采用 SkyWalking 来监控系统，来看看 APM 的功效。

为什么采用 SkyWalking 呢？国内优秀开源项目，更符合国人的开发使用习惯，对国内生态兼容的更好，目前已经捐献给 Apache 组织，影响力进一步扩大、社区活跃度也很高。另外，它透过字节码注入这种无侵入的方式来监控系统，大大降低第三方工具对系统的代码污染。

二、SkyWalking

下载地址（国内镜像）：

Index of /apache/skywalking

解压后目录如下：

进入 config 文件夹，打开主配置文件 application.yml，可以发现 SkyWalking 有几种支持集群配置方式：ZooKeeper、Nacos、Etcd、Consul、Kubernates，本示例以单机版演示。SkyWalking 支持三种存储方式，H2、MySQL、ElasticSearch 三种，H2 默认将数据存储在内存中，重启后数据丢失。官方推荐 ElasticSearch，结果不言而喻，ElasticSearch 存储更快更多。

2.1 安装 ElasticSearch

下载 ElasticSearch（官方下载需要梯子）：https://thans.cn/mirror/elasticsearch.html

解压目录如下：

启动 ElasticSearch：（-d 为后台运行方式）

访问 http://127.0.0.1:9200/，注意正常情况下输出页面，表明 ElasticSearch 安装成功。

 2.2 配置 SkyWalking

打开主配置文件，修改配置相应：

 变更存储方式为 ElasticSearch，采用默认配置，同时注释掉原来的 h2 配置。

2.3 安装监控台

配置 webapp 目录下的 webapp.yml 文件，变更默认超时时间 10000，变更 server.por t= 13800，（原有的 8080 端口与默认的 sentinel-dashboard 端口冲突）如果超时，适当调大一些。以上配置结束后，启动 SkyWalking，访问 SkyWalking 的 UI，http://127.0.0.1:8080，正常如下：

日志显示启动成功，管理平台页面 默认端口 8080，登录信息 admin/admin，打开浏览器地址显示如下：

2.4 安装客户端

agent 俗称探针，以无侵入的方式来收集和发送数据到归集器。本案例以 Java 的方式加载探针，即 java -jar 的方式。在测试前，首先要构建出 jar 包。在 Eclipse 的根项目中执行 "maven install" 命令，构建输出 jar 包。

我的 SkyWalking agent 所在目录：

/Users/apple/software/apache-skywalking-apm-bin/agent/skywalking-agent.jar

构建 jar 过程中出现一个小插曲，启动后显示异常：

appledeMacBook-Air:target apple$ java -jar parking-member.jar 
parking-member.jar 中没有主清单属性

虽然 pom 配置中引用了 spring-boot-maven-plugin 插件，但构建出的jar依然无法找到主清单启动服务，由于我们的 parent 标签为自定义，无法按照标准的 spring-boot-starter-parent 方式构建可执行 jar，这里要特殊处理一下，增加如下配置项，才能达到与 spring-boot-starter-parent 一样的效果，在每个子模块的 pom 中增加此配置，重新测试可以正常启动。

<executions>
    <execution>
         <goals>
            <goal>repackage</goal>
         </goals>
     </execution>
</executions>

先拿 member 启动一个 agent，看数据能否正常写入 Elasticsearch 库中去，在终端窗口中执行如下命令：

java -javaagent:/Users/apple/software/apache-skywalking-apm-bin/agent/skywalking-agent.jar -Dskywalking.agent.service_name=parking-member-service -Dskywalking.collector.backend_service=127.0.0.1:11800 -jar parking-member-service.jar

 查看 agent 目录的日志文件 skywalking-api.log，可以看到客户端正常运行：

DEBUG 2020-02-05 11:45:06:003 SkywalkingAgent-5-ServiceAndEndpointRegisterClient-0 ServiceAndEndpointRegisterClient : ServiceAndEndpointRegisterClient running, status:CONNECTED.

按以上方式，多启动几个应用，并执行几个业务逻辑功能，比如会员绑定用户手机号、开通月卡、付费离场等等，来看下 SkyWalking 的数据收集、展现情况。注意后面的 jar 执行包路径，如下命令是基于当前目录下执行的操作。

java -javaagent:/Users/apple/software/apache-skywalking-apm-bin/agent/skywalking-agent.jar -Dskywalking.agent.service_name=parking-card-service -Dskywalking.collector.backend_service=127.0.0.1:11800 -jar parking-card-service.jar

java -javaagent:/Users/apple/software/apache-skywalking-apm-bin/agent/skywalking-agent.jar -Dskywalking.agent.service_name=parking-admin-server -Dskywalking.collector.backend_service=127.0.0.1:11800 -jar parking-admin-server.jar

java -javaagent:/Users/apple/software/apache-skywalking-apm-bin/agent/skywalking-agent.jar -Dskywalking.agent.service_name=parking-gateway-service -Dskywalking.collector.backend_service=127.0.0.1:11800 -jar parking-gateway.jar

java -javaagent:/Users/apple/software/apache-skywalking-apm-bin/agent/skywalking-agent.jar -Dskywalking.agent.service_name=parking-resource-service -Dskywalking.collector.backend_service=127.0.0.1:11800 -jar parking-resource.jar

java -javaagent:/Users/apple/software/apache-skywalking-apm-bin/agent/skywalking-agent.jar -Dskywalking.agent.service_name=parking-message-service -Dskywalking.collector.backend_service=127.0.0.1:11800 -jar parking-message-service.jar

2.5 监控台数据展现

刷新 SkyWalking 的 UI 界面，可以看到已经有数据收集到。（重点关注图中彩色框框住的三个关键区域）

 服务、服务实例、服务接口、数据库的性能监控，服务间的引用关系，服务接口的链路跟踪等等，都能从监控台找到相应的展现，我们这里重点关注下服务请求的链路跟踪。

三、请求链路案例分析

找一个涉及到两个以上服务的链路，深入分析一下，以会员绑定手机号为例子，请求调用到涉及会员服务、月卡服务两个。

左侧为请求端点显示：蓝色是正常的，红色是异常请求。

图中顶部棕色框圈住的部分是 traceid，什么是 traceid，这是一个全局的请求标识，从源头请求开始，中间涉及到的所有服务接口调用都携带此全局标识，用于标记这是一次完整的请求链路，通过这一 id 将所有请求串联起来，形成一个调用树，如上图中蓝色箭头所示的位置。

从中显露出两个信息：

1. 一条完整的请求链路，可以跟踪相应的日志信息（借助日志工具，比如 ELK）
2. 链路中的节点耗时，为后期优化提供了确切证据

至此，本篇带你使用 SkyWalking 融合到微服务中去，为微服务系统的正常运行保驾护航。有兴趣的同学，可以对照安装下其它的几个监控系统，对比一下，才能发现各自的优劣。

博文参考