使用Envoy和Jaeger实现分布式追踪

2018年12月11日 | 作者 Arvind Thangamani | 译者 马若飞 | 审校者 杨传胜 | 2200字 | 阅读大约需要5分钟
查看原文 | 归档于 envoy | 标签 #envoy #jaeger

如果你是初次接触服务网格和Envoy,我这里有一篇文章可以帮助你入门。

在微服务架构中,可观测性变得越加重要。我认为这是选择微服务这条路的必要条件之一。我的一位前同事列出了一份非常棒的需求清单,如果你想做微服务,那么你需要满足提到的这些要求。

可观测性有许多事要做:

  • 监控
  • 报警
  • 日志集中化
  • 分布式追踪

本文只讨论Envoy下的分布式追踪,我尽量给出一个全貌来描述分布式追踪、OpenTracing、Envoy和Jaeger是如何整合在一起工作的。在下一篇文章中,我们将讨论使用Envoy、prometheus和grafana做监控。

分布式追踪

随着大量的服务和请求的流转,你需要能够快速发现哪里出了问题。分布式追踪最早由谷歌的Dapper普及开来,它本质上具有在微服务的整个生命周期中追踪请求的能力。

最简单的实现方法是在前端代理生成一个唯一的请求id(x-request-id),并将该请求id传递给与其交互的所有服务。基本上可以向所有的日志追加这一请求id。因此,如果你在kibana这样的系统中搜索唯一id,你会看到针对该特定请求的所有相关的日志。

这非常有用,但是它不能告诉你每个服务中请求完成的顺序、是否是并行完成的或者花费了多少时间。

让我们看看OpenTracing和Envoy如何帮助我们解决这一问题。

OpenTracing

与其只传递一个id(x-request-id),不如传递更多的数据,比如哪个服务位于请求的根级别,哪个服务是哪个服务的子服务等等。这可以帮我们找出所有的答案。标准的做法是使用OpenTracing,它是分布式追踪的规范,和语言无关。你可以在这里阅读更多关于此规范的信息。

Envoy

服务网格就像微服务的通信层,服务之间的所有通信都是通过网格进行的。它可以实现负载均衡、服务发现、流量转移、速率限制、指标(metrics)收集等功能,Envoy就是这样的一个服务网格。在我们的例子中,Envoy将帮助我们生成唯一根请求id (x-request-id),生成子请求id,并将它们发送到JaegerZipkin这样的追踪系统,这些系统存储、聚合追踪数据并为其提供可视化的能力。

这篇文章中我们会使用Jaeger作为追踪系统,Envoy用来生成基于zipkin或lighstep格式的追踪数据。我们会使用zipkin的标准来兼容Jaeger。

只要给我看代码就好

下面的图展示了我们尝试构建的系统全貌:

service setup

服务安装

我们将使用docker-compose来部署Envoy。你需要向Envoy提供一份配置文件。这里我不打算解释如何配置Envoy,只集中讨论与追踪相关的部分。。你可以在这里找到更多关于配置Envoy的信息。

前端Envoy

前端Envoy的作用是生成根请