服务内链路追踪实践

搭建链路追踪基础设施

为了能够展示链路追踪信息并将不同服务问的请求关联起来，需要为链路追踪搭建一套收集器和一个界面，同时还需要引入一些类库并将其配置到服务中。为了展示分布式链路追踪功能，将使用SimpleBank的profile服务和setting服务作为服务示例。

profile服务会调用一个外部服务的url http://ip.jsontest.com以检索IP信息，并且会从setting服务中获取用户设置的信息。将搭建一套链路追踪系统（Jaeger）并修改一些必要的代码来展示trace与span，并将这些span关联起来。将这些span关联起来能够帮助了解在profile服务的一次调用中每个操作的耗时及其相对整体执行时间的占比。

将Jaeger添加到docker-compose.yml文件

(…)

jaeger:

    container_name: jaeger

    image: jaegertracing/all-in-one:latest --- 使用包含所有必需组件的Jaeger镜像，因为它更加易于安装和配置。这个all-in-one镜像使用内存来存储span数据

    ports:

      - 5775:5775/udp ---传输span数据的端口

      - 6831:6831/udp

      - 6832:6832/udp

      - 5778:5778

      - 16686:16686---  访问Jaeger界面的端口

      - 14268:14268

      - 9411:9411 ---  另一款分布式链路追踪系统Zipkin所使用的端口——OpenTracing的一个优点是在不修改所有实现的情况下可使用另一套系统，否则会被绑定在特定的系统上

    environment:

      COLLECTOR_ZIPKIN_HTTP_PORT: "9411"

借助添加到docker-compose文件中的Docker镜像，在启动完所有SimpleBank基础设施后，也就拥有了一套分布式链路追踪系统。

现在需要确定SimpleBank的profile服务和setting服务都能够创建trace和span并将其传输到Jaeger服务。向setting服务和profile服务添加一些必要的类库并初始化链路追踪器。

SimpleBank的profile服务初始化了一个trace，这个trace会将不同的span组合起来。它分别为对http://ip.jsontest.com/调用以及对SimpleBank的settings服务调用创建span。

在从settings服务接收到的请求中提取出span上下文后，可以将其作为新创建的span的父span。将新创建的子span独立地进行可视化显示。但是也能够利用Jaeger，它能将该span作为SimpleBank settings服务上下文中独立的span来展示，也可作为profile服务上下文中的子span来展示。

链路追踪系统可视化

当请求到达profile端点时发生了什么。

1）profile服务创造了一个span A。

2）profile服务与外部服务交互以获取IP，并将其包装在一个新的span B中。

3）profile服务在新建的span C中与内部的SimpleBank settings服务交互以获取用户信息，并将父span的上下文传递给下游服务。

4）两个服务将span信息传递至Jaeger服务。

为了将追踪可视化，需要访问运行在16686端口的Jaeger界面。

在Service部分，可以看到有3个服务拥有追踪数据：2个SimpleBank服务还有1个被称为jaeger-query的服务。profile服务为执行外部服务调用和settings服务调用分别创建了span。在网页上选择simplebank-profile服务，单击底部的Find Traces按钮。下图展示了profile服务的链路追踪。

顶部导航菜单栏有一个Dependencies链接。单击该链接，然后在出现的页面中选择DAG（Direct Acyclic Graph）选项卡。

示例很简单，我想在业务触发的开始添加一个功能的job id(父 span id)，当流程走到每个服务生成span(子 span id)时添加job id。只要涉及异步消息处理，可以生成孙子 span。这样子最终生成整个DAG图时更真实反馈请求流走向。

摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》