具有Envoy代理的微服务模式，第三部分：分布式跟踪-CSDN博客

该博客是系列文章的一部分，该系列文章更深入地介绍了Envoy Proxy和Istio.io ，以及它如何实现更优雅的连接和管理微服务的方式。跟随我@christianposta ，紧跟这些博客文章的发布。

什么是Envoy代理，它如何工作？
如何使用Envoy Proxy实现一些基本模式？
Istio Mesh如何适合这张照片
Istio Mesh的工作方式，以及如何通过Envoy跨集群启用高阶功能
Istio Mesh身份验证的工作方式

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

断路器（第一部分）
重试/超时（第二部分）
分布式跟踪（第三部分）
普罗米修斯的度量标准收集（第四部分）
服务发现（第五部分）
接下来的部分将介绍更多的客户端功能（请求阴影，TLS等），只是不确定哪些部分将是：:)

第三部分–使用Envoy代理进行分布式跟踪

第一篇博客文章向您介绍了Envoy Proxy的断路功能实现。在第二部分中，仔细研究了如何启用其他弹性功能，例如超时和重试。在第三部分中，我们将看到如何在我们的服务网格中启用分布式跟踪。这些演示故意是简单的，因此我可以分别说明这些模式和用法。请下载此演示的源代码，然后继续！

该演示由客户端和服务组成。客户端是一个Java http应用程序，它模拟对“上游”服务进行http调用（请注意，我们在这里使用Envoys术语，并且贯穿此repo ）。客户端打包在名为docker.io/ceposta/http-envoy-client:latest的Docker映像中。 http-client Java应用程序旁边是Envoy Proxy的实例。在此部署模型中，Envoy与服务（在本例中为http客户端）一起作为边车进行了部署。当http客户端发出出站呼叫（到“上游”服务）时，所有呼叫都通过Envoy代理端进行。然后，Envoy添加在服务呼叫期间发送的跟踪标头，并发送到Zipkin（或您的跟踪提供者…Envoy目前支持Zipkin和Lightstep ）

这些示例的“上游”服务是httpbin.org 。 httpbin.org允许我们轻松模拟HTTP服务行为。太棒了，所以如果您没有看过，请检查一下。

tracing演示具有自己的 envoy.json配置文件。我绝对建议您查看配置文件各部分的参考文档，以帮助您了解完整的配置。 datawire.io的好伙伴还为Envoy及其配置提供了不错的介绍，您也应该查看一下。

运行跟踪演示

对于跟踪演示，我们将使用以下显着配置来配置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服务器：

首先停止任何现有的演示：

./docker-stop.sh

然后引导我们的zipkin服务器：

./tracing/docker-run-zipkin.sh

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

./port-forward-minikube.sh 9411

签出该命令以将其移植到您的Docker主机可能看起来像的任何东西。一旦Zipkin启动并运行，请导航至该服务（即，在minikube上，在执行端口转发之后，它将只是http：// localhost：9411）。您应该看到Zipkin：

现在我们已经启动了zipkin服务器，让我们开始我们的tracing演示：

./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过滤器中调整开始/停止时间：

在这里，我们有一个具有单个跨度的跟踪（这是我们期望的，因为具有Envoy的演示客户端正在直接与不具有Envoy的外部服务进行通信……如果上游服务也启用了zipkin的Envoy，我们d查看服务之间的完整跨度）

如果单击跨度以查看更多详细信息，则会看到类似以下内容的内容：

注意

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