开发者学堂课程【服务网格技术最佳实践：使用服务网格可观测性为应用服务保驾护航】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/752/detail/13224
使用服务网格可观测性为应用服务保驾护航
内容介绍：
五、ASM 链路追踪的架构
六、实践 ASM 链路追踪
七、应用需要进行改造
八、实践 ASM 链路追踪-常见问题
五、ASM 链路追踪的架构
1、ASM 解决方案有了解之后，接下来看一下 ASM 链路追踪的架构。
可以看到，图中的数据面集群与用户的集群里面，有两个 pod，一个是 pod-1，一个是 pod-2，pod 是用户服务的应用。在 pod 里面，除 User-Container 用户的应用容器之外，各有一个叫做 istio-proxy 这样一个 container。这个 container 其实就是服务网格的 sildcar，会帮助用户 container 去接管流量，所有的流量其实最后都会走 sildcar，跟其他的 pod 通信。
2、刚才提到中间层，也就是代理 istio-proxy 他会接管消息、流量，同时也会在里面注入相关的链路追踪的信息，并且上报给链路追踪系统。他是通过 zipkin sevice 代理把所有链路追踪的上报，上报给 service。上报之后，默认用阿里云的 XTrace。如果您希望搭建自己的系统，就把 service 指向自己搭建的系统。这个架构是非常直观的架构。
六、实践 ASM 链路追踪
1、
2、介绍完了 ASM 链路追踪大致的情况之后，接下来进入实践演示的环节。演示一下如何去实践 ASM 的链路追踪。为了实践链路追踪能力，需要先部署一个演示应用叫 Bookinfo。大家可以在 istio 的 github 上面找到 bookinfo 应用部署的 YAML，下载 istio 的安装包。我已经提前下载好了 istio 的安装包，选择 istio 1.62 这个版本来演示。先切换到用户的数据面集群，这其实有一个脚本，脚本要做的事情就是把 Kubeconfig 替换了一下。先来部署一下 bookinfo 这个应用，到数据面的集群。因为有些东西已经提前部署了，所以提示的是 unchange。
3、现在有一些 pod 还在初始化，先让他初始化。还要去网格实例控制面，部署一些别的网格的 CR。切换到网格集群，来部署一个 gateway，然后再部署一个destination-rule。再检查一下用户集群是否部署好。
可以看到用户集群都已经部署好了。看一下当前网格的入口网关，网格部署之后有的流量都会通过入口网关进到网格集群里。入口网关的地址是 39.100.55.107，去访问一下，需要在后面加一个 productpage。
这个时候可以看到刚才部署上去的应用，已经可以正常运行了。
4、这是网格的控制台
需要确认一下，在进行实践之前需要把链路追踪这个功能选项打开，选择的是默认的阿里云 XTrace。如果您需要自行搭建可以点击链接自行查看，如何自建追踪系统。当前设置的采样比是100%，所有的流量都会被采样。
现在已经打开了网格的追踪能力，并且演示应用也部署好了。对应用多进行几次访问，来产生一些流量，这样的话就可以在链路追踪系统查看到访问的信息。进行一些访问之后可以到 XTrace 中查看链路追踪信息。通过服务网格的控制台，点击左边的链路追踪，就可以进入到阿里云 XTrace 的页面。在 XTrace 当中选择应用列表，就可以看到一个列出了所有应用的列表，根据刚才服务网格的 ID，筛选一下，只把这个网格里的应用筛选出来，可以看到，已经有了调用的信息。
已经出现了，曲线已经上升了。看到这个应用列表之后，接下来看一下完整的追踪信息。
5、完整的追踪信息，最后看到的会是一个树形的调用链路。
入口是 productpage 这样一个应用，后面又调用了 details，details 又调用了 reviews，是这样一个调用关系。怎么在 XTrace 上面找到呢？点击 productpage 应用，然后点击左侧的接口调用，再点击调用链路。
可以看到，刚才访问的几次调用已经被记录下来了，随便点击一个 Traceld，这个时候就会看到这个 Traceld 整个的调用关系。
这个调用关系可以看到有时间、应用名称、开始时间、结束时间、IP 地址，还有他的状态是否成功，是有一个非常直观的展示，可以看到整个调用的树形关系。
七、应用需要进行的改造
1、这样就基本上把应用部进去了，就可以实现这样一个能力，应用需要做的事情比较少，但是呢还是需要做一些小小的改造。就是应用需要去传播 B3 Header ，B3 Header 是链路追踪当中用来追踪链路信息的，就是 zipkin 当中一个固定的用来传达追踪链路信息的 header，需要在请求当中把进入的请求当中的 header 拿出来，原封不动的放到由它产生的调出的请求中。比如说应用 A 受到了一个调用，需要把收到的调用里面的信息拿出来，B3 Header 拿出来，原封不动的复制给由这个调用触发的再调下一环的，比如说服务 B。这个调出请求当中，需要把header 传过去。为什么一定让用户做这个操作呢？服务网格不能代劳这件事情吗？服务网格的代理是没办法分析，从用户应用的黑盒当中出来的请求要调其他服务的请求，是由哪一个应当的请求来触发的。这个逻辑完全是在应用当中，有可能一个请求会触发五次调用别的服务或者十次，或者一次或者不调用。这个关系网格代理是没有办法知道的，所以如果不传播这个 header，网格代理就会认为调出去的请求，他是一次独立的请求，他没有办法跟调用的请求关联起来，而这个时候，网格代理会为新的调用请求生成一个新的 Traceld。
2、如果不进行这个改造，其实也可以看到调用关系，也可以知道由网关 ingress，由网格的 ingress gateway 调用了服务 A，然后服务 A 调了服务 B，这个关系也是能看到的。但是没有办法拿到整个调用的链路，一整条链路的完整信息，只能独立的去查看。所以要形成一个完整的调用链路信息，应用就需要做这么一件事情，就是在应用当中以传播 header 的方式告诉链路追踪系统，也告诉网格代理，这个请求是有一个上下的关联关系，Traceld 是什么？这样的话，链路追踪系统和网格代理就可以把请求关联起来，作为一条完整的链路。
八、实践 ASM 链路追踪-常见问题
1、已经把 ASM 当中的链路追踪能力完整的给大家演示了一遍。还有两个常见的问题，顺便给大家解答一下。第一个问题是链路追踪会不会对性能有影响？其实对性能的影响肯定是有的。虽然上报是在网格代理中进行的，并且是异步进行的。但是当请求的数量比较大的时候，对节点的 CPU 还是会有一些影响。应该怎么去避免这个问题呢？其实在刚才演示的过程中，大家可以看到，链路追踪的比例是可以调整的，不管是由网格代理来实现，还是在应用当中集成，只要做这件事情，影响还是无法避免的。通常的解决方案就是将链路追踪比例调低，这样一来就不会对所有的流量进行追踪，可以根据自己实际的应用情况来调整一个相对合适的比例，去避免链路追踪消耗掉过多的资源。
2、第二个问题是，可以自己搭建链路追踪系统吗？是可以的。然后也讲了架构的原理，只要在 zipkin service 后面指向的是自己的系统，就可以使用自己搭建的系统来收集链路追踪的数据。唯一的要求是这个系统必须是支持 zipkin 协议的系统。如果系统不支持 zipkin 协议，但有一些系统，虽然他自己不支持 zipkin系统，但它有一个协议转换的能力，当需要用这些系统的时候，只要确保导出的是一个支持 zipkin协议的系统，就可以了。经过刚才的实践，可以对服务网格的能力已经有一个大体的感知，服务网格技术是云原生当中非常重要的一部分，而阿里云服务网格作为业界首个全托管的服务网格，已经有了大量的用户成功案例，也欢迎大家多多了解 ASM，ASM 也是一个免费的产品，有兴趣的同学不妨来创建一个网格实例，体验一下 ASM。
