非容器应用与K8s工作负载的服务网格化实践-7 基于ASM的POD和VM可观测性实践

服务网格的可观测性能力是通过Sidecar实现的,对于业务服务源代码来说是近零侵入的。可观测性包括数据采集、数据存储、数据展示和聚合分析。主要有三个维度:Metrics、Logging、Tracing,分别用于可聚合数据、离散事件、请求链路的可观测性。相应地,阿里云生态下,ASM打通了ARMS(https://www.aliyun.com/product/arms)、Log Service(https://www.aliyun.com/product/sls)、TracingAnalysis(https://www.aliyun.com/product/xtrace),供用户使用服务网格的可观测性能力。

本篇只涉及请求链路,这个维度最容易展示VM中非容器应用网格化带来的增益,以抛砖引玉。

1 近零侵入

本篇示例容器中的微服务源代码依然使用http_springboot_demo。抛开云原生,单看这个springboot开发的微服务,如果要实现全链路请求的采集,需要有一行主动打点的日志,维护并记录requestId作为全链路唯一键的请求和响应信息。这个信息由日志采集agent上报,然后由日志系统根据requestid提供查询和聚合。代码示意如下:

@GetMapping(path = "/hello/{msg}")
public String sayHello(@PathVariable String msg) {
    String url = "http://" + HTTP_HELLO_BACKEND + ":8001/hello/" + msg;
    String backServiceResult = helloService.sayHello(url);
    String result = HELLO + " " + msg;
    log.info("打点日志...")
    return result + backServiceResult;
}
public String sayHello(String url) {
    Request request = new Request.Builder()
            .url(url)
            .build();
    try (Response response = client.newCall(request).execute()) {
      ...

这个微服务网格化后,微服务源代码不再需要主动打点,相应地也无需维护全链路唯一键。这些工作Sidecar都已经实现了,而且是基于CNCF云原生生态下的OpenTracing(/OpenTelemetry)标准实现的,无论从专业性还是标准上,都优于业务代码自己打点。而这个『近零侵入』的地方就是“propagate tracing headers”——需要业务代码传递如下header到下游。仅此而已。代码示意如下:

@GetMapping(path = "/hello/{msg}")
public String sayHello(@PathVariable String msg, @RequestHeader Map<String, String> headers) {
    String url = "http://" + HTTP_HELLO_BACKEND + ":8001/hello/" + msg;
    String backServiceResult = helloService.sayHello(url, headers);
    String result = HELLO + " " + msg;
    return result + backServiceResult;
}

上面这段代码,较之前述一段,少了第6行主动打点,多了RequestHeader参数。传递给下游的代码示意如下:

public String sayHello(String url, Map<String, String> headers) {
    Map<String, String> tracingHeaders = buildTracingHeaders(headers,
            "x-request-id",
            "x-b3-traceid",
            "x-b3-spanid",
            "x-b3-parentspanid",
            "x-b3-sampled",
            "x-b3-flags",
            "x-ot-span-context");
    Request request = new Request.Builder()
            //propagate tracing headers
            .headers(Headers.of(tracingHeaders))
            .url(url)
            .build();
    try (Response response = client.newCall(request).execute()) {

之所以说是『近零侵入』是因为RequestHeader参数在多数业务代码中本身就存在,就算不存在也可以直接从spring容器context中直接拿到,因此侵入的代价就是构造并传递上面代码段中的header map。而这带来的好处是省去了主动打点代码及其维护成本。

2 搭建实验环境

本篇实验继续使用第2篇的组件拓扑,如下图所示。本篇的重点是确认完整的端到端链路的可追踪性。

非容器应用与K8s工作负载的服务网格化实践-7 基于ASM的POD和VM可观测性实践

由于Sidecar负责上报链路追踪的数据,业务代码无需感知具体的链路追踪系统。ASM支持阿里云链路追踪产品TracingAnalysis,也支持用户自建Zipkin。对于虚拟机的网格化链路追踪而言,只需在启动参数中提供链路追踪系统即可。余文详述。

TracingAnalysis

由于ASM已经在数据平面创建了TracingAnalysis相关的POD,我们只需为虚拟机提供一个链路追踪服务即可。示意如下:

apiVersion: v1
kind: Service
metadata:
  labels:
    app: tracing
    component: zipkin
  name: zipkin-slb
  namespace: istio-system
spec:
  ports:
    - name: zipkin
      port: 9411
      protocol: TCP
      targetPort: 9411
  selector:
    app: tracing
    component: zipkin
  type: LoadBalancer
k get svc zipkin-slb -n istio-system
NAME         TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)          AGE
zipkin-slb   LoadBalancer   172.19.10.62   39.107.229.139   9411:31170/TCP   178m

通过如下命令模拟dns将链路追踪服务提供给虚拟机:

zipkin_clusterIp=$(k get svc zipkin-slb -n istio-system | grep zipkin | awk -F ' ' '{print $4}')
echo "$zipkin_clusterIp zipkin.istio-system" >dns_record

VMS=("$VM_PUB_1" "$VM_PUB_2" "$VM_PUB_3")
for vm in "${VMS[@]}"; do
  ssh root@"$vm" "sed -i '/zipkin.istio-system/d' /etc/hosts"
  ssh root@"$vm" "cat >> /etc/hosts" <dns_record
done
rm -rf dns_record

最后在VM中向/var/lib/istio/envoy/sidecar.env追加一行:

ISTIO_AGENT_FLAGS="--zipkinAddress zipkin.istio-system:9411 --serviceCluster vm1-hello2-en"

Zipkin

自建zipkin的方式参见文档:向自建系统导出ASM链路追踪数据,其他步骤与TracingAnalysis一致。

实验环境

与第2篇类似,通过如下脚本启动本篇实验实例的相关各组件:

sh asm/ack.deploy.sh
sh asm/asm.deploy.sh
sh asm/asm_traffic_shift.sh
sh asm/dns.fake.sh

3 链路追踪验证

使用如下脚本发起端到端调用:

IP=$(k -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
for i in {1..1000}; do
  resp=$(curl -s "$IP":8008/hello/eric)
  echo "$resp" >>test_traffic_shift_result
done

全局拓扑

TracingAnalysis提供了全局拓扑,通过这个拓扑图,我们可以一目了然地看到VM中的应用和ack容器中的POD一样,作为端到端链路上的一个endpoint存在。示意如下。
非容器应用与K8s工作负载的服务网格化实践-7 基于ASM的POD和VM可观测性实践

Tracing

登录TracingAnalysis或者自建zipkin系统查看tracing。如下图所示,VM中的Sidecar上报了hello2应用链路的inboundoutbound数据,与hello1/hello3 POD形成完整的调用链路。

非容器应用与K8s工作负载的服务网格化实践-7 基于ASM的POD和VM可观测性实践

全链路聚合

通过TracingAnalysis的全链路聚合,可以完整地看到hello2的三个版本vm1-hello2-en/vm2-hello2-fr/vm3-hello2-es链路追踪数据的聚合信息。

非容器应用与K8s工作负载的服务网格化实践-7 基于ASM的POD和VM可观测性实践

到此,基于ASM的POD和VM可观测性实践验证完毕。通过本篇实验,我们可以看到,非容器应用网格化后直接具备了强大的服务可观测性能力。

由于时间和精力关系,本系列到此结束。希望在云原生之下,服务网格能为我们的产品带来一些不同和惊喜。

上一篇:非容器应用与K8s工作负载的服务网格化实践-4 基于ASM的POD和VM互访实践-GRPC协议篇


下一篇:非容器应用与K8s工作负载的服务网格化实践-5 基于ASM的POD和VM混合流量转移实践