赵化冰,腾讯云高级工程师,Istio Member,ServiceMesher 管理委员,Istio 项目贡献者,热衷于开源、网络和云计算。目前主要从事服务网格的开源和研发工作。
TCM(Tencent Cloud Mesh)是腾讯云上提供的基于Istio 进行增强,和 Istio API 完全兼容的 Service Mesh 托管服务,可以帮助用户以较小的迁移成本和维护代价快速利用到 Service Mesh 提供的流量管理和服务治理能力。本系列文章将介绍 TCM 上的最佳实践,本文将介绍如何利用 Spring 和 OpenTracing 简化应用程序的Tracing 上下文传递,以及如何在 Istio 提供的进程间调用跟踪基础上实现方法级别的细粒度调用跟踪。
相比传统的“巨石”应用,微服务的一个主要变化是将应用中的不同模块拆分为了独立的进程。在微服务架构下,原来进程内的方法调用成为了跨进程的RPC调用。相对于单一进程的方法调用,跨进程调用的调试和故障分析是非常困难的,很难用传统的调试器或者日志打印来对分布式调用进行查看和分析。
如上图所示,一个来自客户端的请求经过了多个微服务进程。如果要对该请求进行分析,则必须将该请求经过的所有服务的相关信息都收集起来并关联在一起,这就是“分布式调用跟踪”。
OpenTracing[1]是CNCF[2](云原生计算基金会)下的一个项目,其中包含了一套分布式调用跟踪的标准规范,各种语言的API,编程框架和函数库。OpenTracing 的目的是定义一套分布式调用跟踪的标准,以统一各种分布式调用跟踪的实现。目前已有大量支持OpenTracing 规范的 Tracer 实现[3],包括Jager,Skywalking,LightStep 等。在微服务应用中采用OpenTracing API实现分布式调用跟踪,可以避免 vendor locking,以最小的代价和任意一个兼容 OpenTracing 的基础设施进行对接。
OpenTracing的概念模型参见下图:
图源自 https://opentracing.io/
如图所示,OpenTracing 中主要包含下述几个概念:
一个Trace可以看成由多个相互关联的 Span 组成的有向无环图(DAG图)。下图是一个由8个 Span 组成的 Trace:
[Span A] ←←←(the root span)
|
+------+------+
| |
[Span B] [Span C] ←←←(Span C is a `ChildOf` Span A)
| |
[Span D] +---+-------+
| |
[Span E] [Span F] >>> [Span G] >>> [Span H]
↑
↑
↑
(Span G `FollowsFrom` Span F)
上图的trace也可以按照时间先后顺序表示如下:
––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–> time
[Span A···················································]
[Span B··············································]
[Span D··········································]
[Span C········································]
[Span E·······] [Span F··] [Span G··] [Span H··]
Span 的数据结构中包含以下内容:
SpanContext 是 OpenTracing 中一个让人比较迷惑的概念。在 OpenTracing 的概念模型中提到 SpanContext 用于跨进程边界传递分布式调用的上下文。但实际上 OpenTracing 只定义一个 SpanContext 的抽象接口,该接口封装了分布式调用中一个 Span 的相关上下文内容,包括该 Span 所属的 Trace id,Spanid 以及其它需要传递到 downstream 服务的信息。SpanContext自身并不能实现跨进程的上下文传递,需要由 Tracer(Tracer是一个遵循OpenTracing 协议的实现,如 Jaeger,Skywalking 的 Tracer)将 SpanContext 序列化后通过 Wire Protocol 传递到下一个进程中,然后在下一个进程将 SpanContext 反序列化,得到相关的上下文信息,以用于生成 Child Span。
为了为各种具体实现提供最大的灵活性,OpenTracing 只是提出了跨进程传递 SpanContext 的要求,并未规定将 SpanContext 进行序列化并在网络中传递的具体实现方式。各个不同的 Tracer 可以根据自己的情况使用不同的Wire Protocol 来传递 SpanContext。
在基于HTTP协议的分布式调用中,通常会使用 HTTP Header 来传递SpanContext 的内容。常见的 Wire Protocol 包含Zipkin使用的b3 HTTP header[4],Jaeger 使用的uber-trace-id HTTP Header[5],LightStep 使用的"x-ot-span-context" HTTP Header 等。Istio/Envoy 支持b3 header 和 x-ot-span-context header,可以和 Zipkin,Jaeger 及 LightStep 对接。其中 b3 HTTP header 的示例如下:
X-B3-TraceId: 80f198ee56343ba864fe8b2a57d3eff7
X-B3-ParentSpanId: 05e3ac9a4f6e3b90
X-B3-SpanId: e457b5a2e4d86bd1
X-B3-Sampled: 1
Istio/Envoy 为微服务提供了开箱即用的分布式调用跟踪功能。在安装了 Istio 和 Envoy 的微服务系统中,Envoy 会拦截服务的入向和出向请求,为微服务的每个调用请求自动生成调用跟踪数据。通过在服务网格中接入一个分布式跟踪的后端系统,例如 zipkin 或者 Jaeger,就可以查看一个分布式请求的详细内容,例如该请求经过了哪些服务,调用了哪个 REST 接口,每个 REST 接口所花费的时间等。
需要注意的是,Istio/Envoy 虽然在此过程中完成了大部分工作,但还是要求对应用代码进行少量修改:应用代码中需要将收到的上游 HTTP 请求中的b3 header 拷贝到其向下游发起的 HTTP 请求的 header 中,以将调用跟踪上下文传递到下游服务。这部分代码不能由 Envoy 代劳,原因是 Envoy 并不清楚其代理的服务中的业务逻辑,无法将入向请求和出向请求按照业务逻辑进行关联。这部分代码量虽然不大,但需要对每一处发起 HTTP 请求的代码都进行修改,非常繁琐而且容易遗漏。当然,可以将发起 HTTP 请求的代码封装为一个代码库来供业务模块使用,来简化该工作。
下面以一个简单的网上商店示例程序来展示Istio如何提供分布式调用跟踪。该示例程序由 eshop,inventory,billing,delivery 几个微服务组成,结构如下图所示:
eshop 微服务接收来自客户端的请求,然后调用 inventory,billing,delivery 这几个后端微服务的REST接口来实现用户购买商品的checkout业务逻辑。
本例的代码可以从 github 下载:https://github.com/aeraki-framework/method-level-tracing-with-istio
如下面的代码所示,我们需要在 eshop 微服务的应用代码中传递b3 HTTP Header。
@RequestMapping(value = "/checkout")
public String checkout(@RequestHeader HttpHeaders headers) {
String result = "";
// Use HTTP GET in this demo. In a real world use case,We should use HTTP POST
// instead.
// The three services are bundled in one jar for simplicity. To make it work,
// define three services in Kubernets.
result += restTemplate.exchange("http://inventory:8080/createOrder", HttpMethod.GET,
new HttpEntity<>(passTracingHeader(headers)), String.class).getBody();
result += "<BR>";
result += restTemplate.exchange("http://billing:8080/payment", HttpMethod.GET,
new HttpEntity<>(passTracingHeader(headers)), String.class).getBody();
result += "<BR>";
result += restTemplate.exchange("http://delivery:8080/arrangeDelivery", HttpMethod.GET,
new HttpEntity<>(passTracingHeader(headers)), String.class).getBody();
return result;
}
private HttpHeaders passTracingHeader(HttpHeaders headers) {
HttpHeaders tracingHeaders = new HttpHeaders();
extractHeader(headers, tracingHeaders, "x-request-id");
extractHeader(headers, tracingHeaders, "x-b3-traceid");
extractHeader(headers, tracingHeaders, "x-b3-spanid");
extractHeader(headers, tracingHeaders, "x-b3-parentspanid");
extractHeader(headers, tracingHeaders, "x-b3-sampled");
extractHeader(headers, tracingHeaders, "x-b3-flags");
extractHeader(headers, tracingHeaders, "x-ot-span-context");
return tracingHeaders;
}
下面我们来测试一下 eshop 实例程序。我们可以自己搭建一个 Kubernetes集群并安装Istio以用于测试。这里为了方便,直接使用腾讯云上提供的全托管的服务网格 TCM[6],并在创建的 Mesh 中加入了一个容器服务TKE[7] 集群来进行测试。
在 TKE 集群中部署该程序,查看Istio分布式调用跟踪的效果。
git clone git@github.com:aeraki-framework/method-level-tracing-with-istio.git
cd method-level-tracing-with-istio
git checkout without-opentracing
kubectl apply -f k8s/eshop.yaml
TCM 图形界面直观地展示了这次调用的详细信息,可以看到客户端请求从 Ingressgateway 进入到系统中,然后调用了eshop 微服务的 checkout 接口,checkout 调用有三个 child span,分别对应到 inventory,billing 和 delivery 三个微服务的REST接口。
OpenTracing 提供了基于 Spring 的代码埋点,因此我们可以使用 OpenTracing Spring 框架来提供 HTTP header 的传递,以避免这部分硬编码工作。在 Spring 中采用 OpenTracing 来传递分布式跟踪上下文非常简单,只需要下述两个步骤:
@Bean
public io.opentracing.Tracer zipkinTracer() {
String zipkinEndpoint = System.getenv("ZIPKIN_ENDPOINT");
if (zipkinEndpoint == null || zipkinEndpoint == ""){
zipkinEndpoint = "http://zipkin.istio-system:9411/api/v2/spans";
}
OkHttpSender sender = OkHttpSender.create(zipkinEndpoint);
Reporter spanReporter = AsyncReporter.create(sender);
Tracing braveTracing = Tracing.newBuilder()
.localServiceName("my-service")
.propagationFactory(B3Propagation.FACTORY)
.spanReporter(spanReporter)
.build();
Tracing braveTracer = Tracing.newBuilder()
.localServiceName("spring-boot")
.spanReporter(spanReporter)
.propagationFactory(B3Propagation.FACTORY)
.traceId128Bit(true)
.sampler(Sampler.ALWAYS_SAMPLE)
.build();
return BraveTracer.create(braveTracer);
}
部署采用 OpenTracing 进行 HTTP header 传递的程序版本,其调用跟踪信息如下所示:
从上图中可以看到,相比在应用代码中直接传递 HTTP header 的方式,采用OpenTracing 进行代码埋点后,相同的调用增加了7个名称前缀为 spring-boot 的Span,这7个 Span 是由 OpenTracing 的 tracer 生成的。虽然我们并没有在代码中显示创建这些Span,但 OpenTracing 的代码埋点会自动为每一个 REST 请求生成一个Span,并根据调用关系关联起来。
OpenTracing 生成的这些 Span 为我们提供了更详细的分布式调用跟踪信息,从这些信息中可以分析出一个 HTTP 调用从客户端应用代码发起请求,到经过客户端的 Envoy,再到服务端的 Envoy,最后到服务端接受到请求各个步骤的耗时情况。从图中可以看到,Envoy 转发的耗时在1毫秒左右,相对于业务代码的处理时长非常短,对这个应用而言,Envoy 的处理和转发对于业务请求的处理效率基本没有影响。
Istio/Envoy 提供了跨服务边界的调用链信息,在大部分情况下,服务粒度的调用链信息对于系统性能和故障分析已经足够。但对于某些服务,需要采用更细粒度的调用信息来进行分析,例如一个REST请求内部的业务逻辑和数据库访问分别的耗时情况。在这种情况下,我们需要在服务代码中进行埋点,并将服务代码中上报的调用跟踪数据和 Envoy 生成的调用跟踪数据进行关联,以统一呈现 Envoy 和服务代码中生成的调用数据。
在方法中增加调用跟踪的代码是类似的,因此我们用 AOP + Annotation 的方式实现,以简化代码。首先定义一个 Traced 注解和对应的AOP实现逻辑:
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
@Documented
public @interface Traced {
}
@Aspect
@Component
public class TracingAspect {
@Autowired
Tracer tracer;
@Around("@annotation(com.zhaohuabing.demo.instrument.Traced)")
public Object aroundAdvice(ProceedingJoinPoint jp) throws Throwable {
String class_name = jp.getTarget().getClass().getName();
String method_name = jp.getSignature().getName();
Span span = tracer.buildSpan(class_name + "." + method_name).withTag("class", class_name)
.withTag("method", method_name).start();
Object result = jp.proceed();
span.finish();
return result;
}
}
然后在需要进行调用跟踪的方法上加上 Traced 注解:
@Component
public class DBAccess {
@Traced
public void save2db() {
try {
Thread.sleep((long) (Math.random() * 100));
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
@Component
public class BankTransaction {
@Traced
public void transfer() {
try {
Thread.sleep((long) (Math.random() * 100));
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
demo 程序的 master branch 已经加入了方法级代码跟踪,可以直接部署。
git checkout master
kubectl apply -f k8s/eshop.yaml
效果如下图所示,可以看到trace中增加了transfer和save2db两个方法级的 Span。
可以打开一个方法的Span,查看详细信息,包括Java类名和调用的方法名等,在AOP代码中还可以根据需要添加出现异常时的异常堆栈等信息。
Istio/Envoy为微服务应用提供了分布式调用跟踪功能,提高了服务调用的可见性。我们可以使用OpenTracing来代替应用硬编码,以传递分布式跟踪的相关http header;还可以通过OpenTracing将方法级的调用信息加入到Istio/Envoy缺省提供的调用链跟踪信息中,以提供更细粒度的调用跟踪信息。
除了同步调用之外,异步消息也是微服务架构中常见的一种通信方式。在下一篇文章中,我将继续利用eshop demo程序来探讨如何通过OpenTracing将Kafka异步消息也纳入到Istio的分布式调用跟踪中。
[1]
OpenTracing: 【http://https//opentracing.io】
[2]
CNCF:【 https://www.cncf.io/】
[3]
OpenTracing规范的Tracer实现:【 https://opentracing.io/docs/supported-tracers/】
[4]
b3 HTTP header: 【https://github.com/openzipkin/b3-propagation】
[5]
uber-trace-id HTTP Header: 【https://www.jaegertracing.io/docs/1.7/client-libraries/#trace-span-identity】
[6]
TCM: 【https://console.cloud.tencent.com/tke2/mesh?rid=16】
[7]
TKE: 【https://console.cloud.tencent.com/tke2/cluster/startUp】
[8]
本文中eshop示例程序的源代码: 【https://github.com/aeraki-framework/method-level-tracing-with-istio】
[9]
Opentracing docs: 【https://opentracing.io/docs/】
[10]
Opentracing specification: 【https://github.com/opentracing/specification/blob/master/specification.md】
[11]
Opentracing wire protocols: 【https://github.com/opentracing/specification/blob/master/rfc/trace_identifiers.md】
[12]
Istio Trace context propagation: 【https://istio.io/docs/tasks/telemetry/distributed-tracing/overview/#trace-context-propagation】
[13]
Zipkin-b3-propagation: 【https://github.com/apache/incubator-zipkin-b3-propagation】
[14]
OpenTracing Project Deep Dive: 【https://www.youtube.com/watch?v=ySR_FVNX4bQ&t=184s】
往期精选推荐
插播福利!!!
腾讯云原生后台回复关键字“手册”即可获取
《腾讯云原生路线图手册》和《腾讯云原生最佳实践》