通过Dapr实现一个简单的基于.net的微服务电商系统(八)——一步一步教你如何撸Dapr之链路追踪

Dapr提供了一些开箱即用的分布式链路追踪解决方案，今天我们来讲一讲如何通过dapr的configuration来实现非侵入式链路追踪的

目录：

一、通过Dapr实现一个简单的基于.net的微服务电商系统

二、通过Dapr实现一个简单的基于.net的微服务电商系统(二)——通讯框架讲解

三、通过Dapr实现一个简单的基于.net的微服务电商系统(三)——一步一步教你如何撸Dapr

四、通过Dapr实现一个简单的基于.net的微服务电商系统(四)——一步一步教你如何撸Dapr之订阅发布

通过Dapr实现一个简单的基于.net的微服务电商系统(五)——一步一步教你如何撸Dapr之状态管理

通过Dapr实现一个简单的基于.net的微服务电商系统(六)——一步一步教你如何撸Dapr之Actor服务

通过Dapr实现一个简单的基于.net的微服务电商系统(七)——一步一步教你如何撸Dapr之服务限流

附录：(如果你觉得对你有用，请给个star)
一、电商Demo地址：https://github.com/sd797994/Oxygen-Dapr.EshopSample

二、通讯框架地址：https://github.com/sd797994/Oxygen-Dapr

　　首先依然简单聊聊什么是链路追踪以及我们为什么需要它,知道链路追踪的同学可以跳过。在传统的单体应用中，我们的每一次请求往往在同一个进程中被一次性处理。而在分布式系统中，我们需要通过不同容器隔离甚至物理机隔离的服务间协同作业来实现某些业务，同时由于业务流转会涉及到接口调用、事件订阅、状态读写、actor调用等等情况，往往想要追踪它们形成一个链式调用的记录会比较困难。这里举一个例子，某分布式系统集群运行在生产环境上，某日收到预警某接口调用非常缓慢。这个时候开发人员排查发现该聚合网关接口调用了服务A、B、C但是不知道具体是哪个服务导致的缓慢，通知A、B、C对应的开发组人员通过本地调试发现A、B、调用正常，C缓慢，但是C发现并非由于自身业务逻辑缓慢，而是自己调用D时返回比较缓慢，这时又只得通知D负责的团队进行业务排查，最终D发现自己的代码问题，然后逐一修复并发布到生产环境解决该问题。这个例子比较极端哈，这里仅举个例子说明。链路追踪系统就是帮助分布式系统在链路调用时记录每一个接口的响应时间以及自己依赖的下游接口的响应时间并提供可视化UI方便开发运维团队快速排查接口调用耗时异常定位问题。

　　传统的链路追踪一般是通过代码侵入式的方式由开发人员集成SDK插入代理，应用上线运行后这些代理即可自动化监视我们的应用进程记录流量流入、流出请求/响应时间并统一上报到链路追踪系统，而service mesh由于sidecar的存在可以确保流量在流入/流出应用时一定会经过sidecar，所以天生更容易实现链路追踪，从而免于让开发人员人工通过SDK的方式去集成一个分布式链路追踪系统，接下来就讲讲我们在dapr下如何来实现它。

　　首先我们需要在k8s环境跑起来一个链路追踪系统，大家可以看看这里：https://docs.dapr.io/operations/monitoring/tracing/supported-tracing-backends/ 是目前dapr支持的链路后端，我这里就选型我比较熟悉的zipkin来实现。zip在k8s中很容易跑起来，这是yaml:

---

apiVersion: apps/v1
kind: Deployment
metadata:name: zipkin
spec:selector:matchLabels:app: zipkinreplicas: 1template:metadata:labels:app: zipkinspec:containers:- name: zipkinimage: openzipkin/zipkin:latestimagePullPolicy: IfNotPresentports:- containerPort: 9411env:- name: TZvalue: "Asia/Shanghai"
---
apiVersion: v1
kind: Service
metadata:name: zipkin
spec:type: NodePortselector:app: zipkinports:- protocol: TCPport: 9411targetPort: 9411

　　由于需要在本地访问zip的website，我这里偷懒直接将nodeport暴露到本地k8s集群，方便等会儿通过浏览器访问。现在我们apply一下，稍微等待一段时间k8s拉取镜像并运行起来后,通过kubectl get svc 查询zipkin暴露的随机端口即可通过localhost:nodeport访问到zipkin的界面:

　　接下来就比较简单了，我们创建一个类型为configuration的配置文件，并注入到每一个需要追踪的服务即可，其中samplingRate是指采样率，而endpointAddress是指我们在k8s集群内通过svc能访问到的zipkin的地址（如果你的zipkin部署在非本集群，则可通过ip or 网址的方式访问）：

apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:name: zipkin
spec:metric:enabled: truetracing:samplingRate: "1"zipkin:endpointAddress: "http://zipkin.infrastructure.svc.cluster.local:9411/api/v2/spans"

　　接着我们将这个configuration注入到我们需要的服务中，这里我们直接看电商demo yaml文件账户服务的情况(红字部分)：

apiVersion: apps/v1
kind: Deployment
metadata:name: accountservicenamespace: dapreshoplabels:app: accountservice
spec: replicas: 1selector:matchLabels:app: accountserviceminReadySeconds: 5 strategy: type: RollingUpdate rollingUpdate:maxUnavailable: 1 maxSurge: 1template: metadata:labels: app: accountserviceversion: v1annotations:dapr.io/enabled: "true"dapr.io/app-id: "accountservice"dapr.io/app-port: "80"dapr.io/config: "zipkin"spec:containers:- name: webimage: accountservice:releaseimagePullPolicy: NeverreadinessProbe:httpGet:path: v1.0/healthzport: 3500initialDelaySeconds: 5periodSeconds: 10timeoutSeconds : 5failureThreshold : 3ports:- containerPort: 80

　　现在我们来下单看看，访问admin.dapreshop.com:30882,初始化系统后，访问m.dapreshop.com:30882，下单一次。接着打开我们的zipkin,查询run query即可看到最新一条链路追踪记录如下：