开发者学堂课程【服务网格技术最佳实践：使用服务网格可观测性为应用服务保驾护航】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/752/detail/13224
使用服务网格可观测性为应用服务保驾护航
内容介绍：
一、服务网格简介
二、可观测性
三、链路追踪的传统解决方案
四、ASM 链路追踪解决方案
一、服务网格简介
1、服务网格是分布式应用的通信层，抽象了通信层的通用能力，例如路由管理、限流、链路追踪等等。
2、本课程将分享使用服务网格可观测性为应用服务保驾护航主题。
这个主题其实就是带领大家在阿里云 ASM 服务网格产品上面进行可观测性能力的实践。服务网格对一部分同学来说可能还是一个比较新的概念，所以在这里为大家简单的介绍一下，什么是服务网格？为什么要使用服务网格？简单的来说，服务网格是一个应用之间的通信层，他把应用之间的的流量都接管，然后把一些能力比如说路由、服务发现、限流、熔断等等这些能力抽象出来，放在了通信层之间。在传统的分布式系统当中，服务应用之间是通过 TCP、 UEP 然后再加上应用层协议进行通信。为了适应现在日新月异的架构发展，服务团队经常需要集成很多与业务无关的代码逻辑。比如说处理刚才提到的服务发现，或路由管理，或者限流等等，包括链路追踪，这样一些第三方的东西需要把它集成进去，或者跟业务逻辑无关的需要把它集成进去，来去实现这些能力。
3、容器编排服务一定程度上解决了提到的这些问题当中的一部分。比如说服务发现这个能力，就可以通过容器编排服务当中的 K8s 里面的 service 这些来解决。但是对于其他很多的流量管理的能力，都还是没有能够很好的抽象出来统一解决。例如说想做一些灰度发布、蓝绿发布，或者说一些服务的限流、熔断，还有链路追踪等等这些比较普遍的，其实也是很常见的，仍然没有很好的抽象出来在应用之外去解决掉。而服务网格就是把上面的这些问题通通抽象出来，在服务网格层面，帮助大家解决这些问题。服务网格除了能解决这些看起来较大的问题，还能做到一些非常精细的管理。比如说想把某个用户的请求路由到特定的应用版本，这些很精细的服务管理，服务网格都是可以做到的。
二、可观测性
1、流量管理是服务网格中非常直观的一个能力,很容易理解。
可观测性其实也是一个非常重要的，在一个复杂的微服务系统中，通常充满了很多应用，由很多应用来构成，每次调用也会经常一个非常复杂的路径，才能返回得到结果。在传统的开发过程中，其实也是经常需要对一些复杂的系统做一些观测，比如说集成一些监控，集成一些追踪等等。这些东西都是为了观测这个复杂系统，当前是如何运行的？有了这些信息就可以更好地开发故障，或分析应用的热点；有了这些可以提升开发运维人员对整个系统的理解，也可以提升响应的速度，发现问题的速度。所以可观测性也是一个非常非常重要的能力。
2、可观测性实际在 istio 主页上面有一个很明确的定义。
它分为三个方面，一个是监控，一个是追踪，还有一个是日志，这三个方面。监控是大家经常接触到的，监控一些服务的延迟、流量状况、报错等这种数据。追踪就是展示服务调用链路，能把整个调用的树形关系展示出来，同时也能看到每次调用的信息，对于大家去理解自己的系统是有非常重大的意义的。日志会把所有 workload 层面的、每个 workload 独立的日志记录下来，日志里面也包含了调用的源、目标以及元信息，使用户可以从 workload 维度审视 workload 的行为。在这三个特性里面主要为大家介绍和演示一下链路追踪这个能力。
3、三个方面
监控：服务延迟、流量状况、报错情况、负载状态
链路追踪：展示服务调用链路、单次调用信息，帮助运维人员梳理调用关系，帮助开发者更深入地理解自己的服务。
日志：网格内的所有 workload 的请求均会被日志记录，日志包含调用的源、目标以及元信息，使用户可以从 workload 维度审视服务行为。
三、链路追踪的传统解决方案
1、 ·应用修改代码，集成链路追踪 SDK，增加上报逻辑
·多语言集成困难、人力成本高
·需要自行搭建、维护链路追踪系统
2、通常情况下，如果要在微服务中集成链路追踪这个能力，需要开发人员在每个应用中都去集成链路追踪的 SDK，以便实现链路追踪上报的逻辑。这样的做法效率较低，每个应用都需要修改代码，微服务中通常有多个应用，每一个应用都需要投入人力去集成链路追踪 SDK 等等这些相关的逻辑，需要去实现，这样对应用的入侵也比较大。通常很多应用都是用不同的语言去实现，这个事情也没有办法统一的去做，每个语言都要去集成相应的 SDK，甚至有些语言 SDK 还不全，这样可能会带来很多麻烦，给开发团队造成很多不必要的困扰。除了这两个之外，可能还需要自己搭建、维护链路追踪系统。这样下来整个开发团队和运维都需要学习很多相关知识，会花费很多时间。那么 ASM 服务网格如何去解决刚才提到的这些问题呢？
四、ASM 链路追踪解决方案
1、对应用代码侵入极低、不需要考虑多语言问题、配合阿里云 XTrace，不需要搭建追踪系统，开箱即用
2、刚才也提到了服务网格是一个通信的中间层，接管所有的应用流量，部署在网格里的应用都会被网格的代理把流量劫持，网格代理在转发这些消息的时候，会在消息中注入一些链路追踪相关的人员信息，包括上报给链路追踪的系统的逻辑全部都已经集成在中间层里面了。应用需要做的事情仅仅是在进入请求，和出的请求当中传播一个简单的追踪信息。这样一来，对应用代码的入侵是非常低的，而且因为把所有的链路追踪都集成在了中间层，也就是网格的代理当中。其实就不需要再去考虑多语言的问题，应用也不需要去集成各种各样的 SDK，去实现这些能力。配合阿里云的 XTrace，甚至不需要去搭建一个追踪系统，实现了一个开箱即用的追踪能力。如果希望自己去搭建一个追踪系统，也是没有问题的，这个在 ASM 文档中都有非常详细的介绍，一步一步引导该怎么去搭建自己的追踪系统。
