本博客是深入研究 Envoy Proxy 和 Istio.io 以及它如何实现更优雅的方式来连接和管理微服务系列文章的一部分。
这是接下来几个部分的想法（将在发布时更新链接 ):
断路器（第一部分）
重试 / 超时（第二部分）
分布式跟踪（第三部分）
Prometheus 的指标收集（第四部分）
服务发现（第五部分）
第三部分 – 使用 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