使用Envoy 作Sidecar Proxy的微服务模式-3.分布式追踪

本博客是深入研究Envoy Proxy和Istio.io 以及它如何实现更优雅的方式来连接和管理微服务系列文章的一部分。

这是接下来几个部分的想法（将在发布时更新链接):

• 断路器（第一部分）
• 重试/超时（第二部分）
• 分布式跟踪（第三部分）
• Prometheus的指标收集（第四部分）
• rate limiter（第五部分）

第三部分 - 使用envoy proxy 实现分布式追踪

第一篇博文向您介绍了Envoy Proxy的断路功能实现。在第二部分中，仔细研究了如何启用额外的弹性功能，如超时和重试。在第三部分中，我们将了解如何在服务网格中启用分布式跟踪。有意进行一些简单的演示，因此我可以单独说明模式和用法。请下载此演示的源代码并按照说明进行操作！

该演示由一个客户端和一个服务组成。客户端是一个Java http应用程序，模拟对“上游”服务进行http调用（注意，我们在这里使用Envoys术语，并贯穿整个repo）。客户端打包在docker.io/ceposta/http-envoy-client:latest的Docker镜像中。除了http-client Java应用程序之外，还有Envoy Proxy的一个实例。在此部署模型中，Envoy被部署为服务的sidercar（在本例中为http客户端）。当http-client进行出站调用（到“上游”服务）时，所有调用都通过Envoy Proxy sidercar。envoy会在服务调用之间添加一些追踪headers，并发送到Zipkin（或您的跟踪提供商...... Envoy目前支持Zipkin和Lightstep）。

这些示例的“上游”服务是httpbin.org。 httpbin.org允许我们轻松模拟HTTP服务行为。它很棒，所以如果你没有看到它，请查看它。

这个traceing 演示有自己的envoy.json配置文件。我绝对建议您查看配置文件每个部分的参考文档，以帮助理解完整配置。 datawire.io的优秀人员也为Envoy及其配置提供了一个很好的介绍，你也应该检查一下。

运行 tracing demo

对于跟踪演示，我们将使用以下如下的配置来配置我们的Envoy（请参阅其余上下文的完整配置）：

   "tracing": {
      "operation_name": "egress"
    },
    
    ...
    
      "tracing": {
        "http": {
          "driver": {
            "type": "zipkin",
            "config": {
              "collector_cluster": "zipkin",
              "collector_endpoint": "/api/v1/spans"
            }
          }
        }
      },
      
      ...
      
       {
          "name": "zipkin",
          "connect_timeout_ms": 1000,
          "type": "strict_dns",
          "lb_type": "round_robin",
          "hosts": [
            {
              "url": "tcp://zipkin:9411"
            }
          ]
        }
    

这里我们配置跟踪驱动程序和跟踪集群。在这种情况下，要运行此演示，我们需要启动Zipkin服务器：

首先我们停止已经存在的演示demo:

./docker-stop.sh

启动zipkin服务：

./tracing/docker-run-zipkin.sh

会将zipkin暴露在端口9411上。如果您使用minikube或类似的东西来运行这些演示，您可以直接将minikube端口导出到您的主机，如下所示：

./port-forward-minikube.sh 9411

一旦你启动并运行Zipkin，访问该服务（即，在minikube上，在进行端口转发后，它将只是http：// localhost：9411）。你应该看看Zipkin：

现在我们已经启动了zipkin服务器，让我们启动我们的跟踪演示：

/docker-run.sh -d tracing

然后让我们用客户端访问服务：

./curl.sh -vvvv localhost:15001/get

我们将看到如下的输出：

< HTTP/1.1 200 OK
* Server envoy is not blacklisted
< server: envoy
< date: Thu, 25 May 2017 06:31:02 GMT
< content-type: application/json
< access-control-allow-origin: *
< access-control-allow-credentials: true
< x-powered-by: Flask
< x-processed-time: 0.000982999801636
< content-length: 402
< via: 1.1 vegur
< x-envoy-upstream-service-time: 142
< 
{
  "args": {}, 
  "headers": {
    "Accept": "*/*", 
    "Connection": "close", 
    "Host": "httpbin.org", 
    "User-Agent": "curl/7.35.0", 
    "X-B3-Sampled": "1", 
    "X-B3-Spanid": "0000b825f82b418d", 
    "X-B3-Traceid": "0000b825f82b418d", 
    "X-Ot-Span-Context": "0000b825f82b418d;0000b825f82b418d;0000000000000000;cs"
  }, 
  "origin": "68.3.84.124", 
  "url": "http://httpbin.org/get"
}

现在，如果我们转到Zipkin服务器，我们应该看到此调用的单个跨度/跟踪（注意，您可能需要调整zipkin过滤器中的开始/停止时间：

这里我们有一个只有一个span的跟踪（这是我们所期望的，因为我们的Envoy演示客户端直接与没有Envoy的外部服务调用......如果上游服务也有启用了zipkin的Envoy，我们将看到服务之间的全部span）。

如果我们点击span以查看更多细节，我们会看到如下内容：

PS

请注意，服务体系结构中的每个服务都应该与Envoy一起部署并参与分布式跟踪。这种方法的优点在于跟踪是从应用程序带外进行的。但是，为了跟踪要正确传播的上下文，应用程序开发人员有责任正确传播正确的header，以便不同的span正确关联。检查zipkin以获取更多详细信息，但至少要传播这些header（如上所示）：

• x-request-id
• x-b3-traceid
• x-b3-spanid
• x-b3-parentspanid
• x-b3-sampled
• x-b3-flags
• x-ot-span-context