非容器应用与K8s工作负载的服务网格化实践-7 基于ASM的POD和VM可观测性实践-阿里云开发者社区

开发者社区> 阿里云容器服务 ACK> 正文

非容器应用与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),供用户使用服务网格的可观

服务网格的可观测性能力是通过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篇的组件拓扑,如下图所示。本篇的重点是确认完整的端到端链路的可追踪性。

由于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存在。示意如下。
7-1-xtrace-topology.png

Tracing

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

7-2-xtrace-tracing.png

全链路聚合

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

7-3-xtrace-aggregation.png

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

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

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
阿里云容器服务 ACK
使用钉钉扫一扫加入圈子
+ 订阅

云端最佳容器应用运行环境,安全、稳定、极致弹性

官方博客
官网链接