「连载十」分布式链路追踪 gRPC + Opentracing + Zipkin

本文将通过 gRPC + Opentracing + Zipkin 搭建一个分布式链路追踪系统来实现查看整个系统的链路、性能等指标。

转载自：https://eddycjy.com/

于原文章写的时间有点长，这里会做一些更新。

项目地址：https://github.com/EDDYCJY/go-grpc-example

在实际应用中，你做了那么多 Server 端，写了 N 个 RPC 方法。想看看方法的指标，却无处下手？

本文将通过 gRPC + Opentracing + Zipkin 搭建一个分布式链路追踪系统来实现查看整个系统的链路、性能等指标。

Opentracing

是什么

OpenTracing 通过提供平台无关、厂商无关的API，使得开发人员能够方便的添加（或更换）追踪系统的实现

不过 OpenTracing 并不是标准。因为 CNCF 不是官方标准机构，但是它的目标是致力为分布式追踪创建更标准的 API 和工具

名词解释

Trace

一个 trace 代表了一个事务或者流程在（分布式）系统中的执行过程

Span

一个 span 代表在分布式系统中完成的单个工作单元。也包含其他 span 的 “引用”，这允许将多个 spans 组合成一个完整的 Trace

每个 span 根据 OpenTracing 规范封装以下内容：

• 操作名称
• 开始时间和结束时间
• key:value span Tags
• key:value span Logs
• SpanContext

Tags

Span tags（跨度标签）可以理解为用户自定义的 Span 注释。便于查询、过滤和理解跟踪数据

Logs

Span logs（跨度日志）可以记录 Span 内特定时间或事件的日志信息。主要用于捕获特定 Span 的日志信息以及应用程序本身的其他调试或信息输出

SpanContext

SpanContext 代表跨越进程边界，传递到子级 Span 的状态。常在追踪示意图中创建上下文时使用

Baggage Items

Baggage Items 可以理解为 trace 全局运行中额外传输的数据集合

一个案例

图中可以看到以下内容：

• 执行时间的上下文
• 服务间的层次关系
• 服务间串行或并行调用链

结合以上信息，在实际场景中我们可以通过整个系统的调用链的上下文、性能等指标信息，一下子就能够发现系统的痛点在哪儿

Zipkin

是什么

Zipkin 是分布式追踪系统。它的作用是收集解决微服务架构中的延迟问题所需的时序数据。它管理这些数据的收集和查找

Zipkin 的设计基于 Google Dapper 论文。

备注：Zipkin 是 Twitter 的一个开源项目，允许开发者收集 Twitter 各个服务上的监控数据，并提供查询接口。

运行

docker run -d -p 9411:9411 openzipkin/zipkin

其他方法安装参见：https://github.com/openzipkin/zipkin

验证

访问 http://127.0.0.1:9411/zipkin/ 检查 Zipkin 是否运行正常

gRPC + Opentracing + Zipkin

在前面的小节中，我们做了以下准备工作：

• 了解 Opentracing 是什么
• 搭建 Zipkin 提供分布式追踪系统的功能

接下来实现 gRPC 通过 Opentracing 标准 API 对接 Zipkin，再通过 Zipkin 去查看数据

目录结构

新建 simple_zipkin_client、simple_zipkin_server 目录，目录结构如下：

go-grpc-example
├── LICENSE
├── README.md
├── client
│   ├── ...
│   ├── simple_zipkin_client
├── conf
├── pkg
├── proto
├── server
│   ├── ...
│   ├── simple_zipkin_server
└── vendor

安装

$ go get -u google.golang.org/grpc
$ go get -u github.com/openzipkin/zipkin-go
$ go get -u github.com/openzipkin-contrib/zipkin-go-opentracing
$ go get -u github.com/grpc-ecosystem/grpc-opentracing/go/otgrpc
$ go get -u github.com/grpc-ecosystem/go-grpc-middleware

• google.golang.org/grpc：grpc的包，主要的
• github.com/openzipkin/zipkin-go：zipkin官方提供的go语言的支持包
• github.com/openzipkin-contrib/zipkin-go-opentracing：OpenTracing bridge for the native Zipkin tracing implementation Zipkin Go.谷歌翻译：用于本机Zipkin跟踪实现Zipkin Go的OpenTracing桥。大白话解释：将zipkin-go包采集出来的信息，提供给zipkin去可视化呈现的一个中间件，相当于一个桥梁的作用。
• github.com/grpc-ecosystem/grpc-opentracing/go/otgrpc：OpenTracing is a set of consistent, expressive, vendor-neutral APIs for distributed tracing and context propagation.谷歌翻译：OpenTracing是一组一致的，可表达的，与供应商无关的API，用于分布式跟踪和上下文传播。大白话解释：也是一个桥梁的作用
• github.com/grpc-ecosystem/go-grpc-middleware：go-grpc-middleware封装了认证（auth）, 日志（ logging）, 消息（message）, 验证（validation）, 重试（retries） 和监控（retries）等拦截器。

gRPC

Server

package main

import (
	"context"
	"log"
	"net"

	"github.com/grpc-ecosystem/go-grpc-middleware"
	"github.com/grpc-ecosystem/grpc-opentracing/go/otgrpc"
	zipkinot "github.com/openzipkin-contrib/zipkin-go-opentracing"
	"github.com/openzipkin/zipkin-go"
	zipkinhttp "github.com/openzipkin/zipkin-go/reporter/http"
	"google.golang.org/grpc"

	"grpc-demo/pkg/gtls"
	pb "grpc-demo/proto"
)

type SearchService struct{}

func (s *SearchService) Search(ctx context.Context, r *pb.SearchRequest) (*pb.SearchResponse, error) {
	return &pb.SearchResponse{Response: r.GetRequest() + " Server"}, nil
}

const (
	PORT = "9005"

	SERVICE_NAME              = "simple_zipkin_server"
	ZIPKIN_HTTP_ENDPOINT      = "http://127.0.0.1:9411/api/v2/spans"
	ZIPKIN_RECORDER_HOST_PORT = "127.0.0.1:9000"
)

func main() {
	// set up a span reporter
	reporter := zipkinhttp.NewReporter(ZIPKIN_HTTP_ENDPOINT)
	defer reporter.Close()

	// create our local service endpoint
	endpoint, err := zipkin.NewEndpoint(SERVICE_NAME, ZIPKIN_RECORDER_HOST_PORT)
	if err != nil {
		log.Fatalf("unable to create local endpoint: %+v\n", err)
	}
	// initialize our tracer
	nativeTracer, err := zipkin.NewTracer(reporter, zipkin.WithLocalEndpoint(endpoint))
	if err != nil {
		log.Fatalf("unable to create tracer: %+v\n", err)
	}
	// use zipkin-go-opentracing to wrap our tracer
	tracer := zipkinot.Wrap(nativeTracer)

	tlsServer := gtls.Server{
		CaFile:   "../../conf/ca.pem",
		CertFile: "../../conf/server/server.pem",
		KeyFile:  "../../conf/server/server.key",
	}
	c, err := tlsServer.GetCredentialsByCA()
	if err != nil {
		log.Fatalf("GetTLSCredentialsByCA err: %v", err)
	}

	opts := []grpc.ServerOption{
		grpc.Creds(c),
		grpc_middleware.WithUnaryServerChain(
			otgrpc.OpenTracingServerInterceptor(tracer, otgrpc.LogPayloads()),
		),
	}
	server := grpc.NewServer(opts...)
	pb.RegisterSearchServiceServer(server, &SearchService{})

	lis, err := net.Listen("tcp", ":"+PORT)
	if err != nil {
		log.Fatalf("net.Listen err: %v", err)
	}

	server.Serve(lis)

}

• zipkinhttp.NewReporter：创建一个 Zipkin HTTP 后端收集器
• zipkin.NewEndpoint：创建一个基于 Zipkin 收集器的记录器
• zipkin.NewTracer：创建一个 OpenTracing 跟踪器（兼容 Zipkin Tracer）
• zipkinot.Wrap：使用zipkin-go-opentracing来包装我们的跟踪器
• otgrpc.OpenTracingClientInterceptor：返回 grpc.UnaryServerInterceptor，不同点在于该拦截器会在 gRPC Metadata 中查找 OpenTracing SpanContext。如果找到则为该服务的 Span Context 的子节点
• otgrpc.LogPayloads：设置并返回 Option。作用是让 OpenTracing 在双向方向上记录应用程序的有效载荷（payload）

总的来讲，就是初始化 Zipkin，其又包含收集器、记录器、跟踪器。再利用拦截器在 Server 端实现 SpanContext、Payload 的双向读取和管理

Client

func main() {
	// the same as zipkin server
	// ...
	conn, err := grpc.Dial(":"+PORT, grpc.WithTransportCredentials(c),
		grpc.WithUnaryInterceptor(
			otgrpc.OpenTracingClientInterceptor(tracer, otgrpc.LogPayloads()),
		))
	...
}

• otgrpc.OpenTracingClientInterceptor：返回 grpc.UnaryClientInterceptor。该拦截器的核心功能在于：

（1）OpenTracing SpanContext 注入 gRPC Metadata

（2）查看 context.Context 中的上下文关系，若存在父级 Span 则创建一个 ChildOf 引用，得到一个子 Span

其他方面，与 Server 端是一致的，先初始化 Zipkin，再增加 Client 端特需的拦截器。就可以完成基础工作啦

验证

启动 Server.go，执行 Client.go。查看 http://127.0.0.1:9411/zipkin/ 的示意图：

复杂点

来，自己实践一下

总结

在多服务下的架构下，串行、并行、服务套服务是一个非常常见的情况，用常规的方案往往很难发现问题在哪里（成本太大）。而这种情况就是分布式追踪系统大展拳脚的机会了

希望你通过本章节的介绍和学习，能够了解其概念和搭建且应用一个追踪系统。

参考

本系列示例代码

• go-grpc-example

资料

• opentracing
• zipkin