微服务平台之全链路追踪 _微服务

文章插图

转载本文需注明出处：微信公众号EAWorld，违者必究。

前言：

随着微服务架构技术的普及和广泛在企业应用中落地，由于微服务架构本身的特性，架构由一系列相对独立的细粒度的服务组成，一个完整的业务逻辑调用请求的背后可能牵涉后端几个、几十个甚至上百个服务接口，每个服务可能是由不同的团队开发，使用了不同的编程语言，还有可能部署在不同的机器上，分布在不同的数据中心，对于这样的一个逻辑调用关系，如果在调用过程中发生问题，比如说调用失败，或者调用过程响应很慢，如何在这样一个分布式环境下快速定位问题所在、快速分析业务处理中的响应慢的瓶颈在哪？多个微服务之间存在调用关系，如何在系统运行时总览一个系统中微服务间的拓扑关系？如何完整还原一次请求的链路情况？
以上这些问题可以借助链路追踪技术进行解决。链路追踪组件通过在微服务应用中以代码侵入或者非侵入的方式进行数据表示、埋点、传递、收集、存储、展示等技术手段，达到将一次分布式请求还原成调用链路，将一次分布式请求的调用情况集中展示，比如各个服务节点上的耗时、请求具体到达哪台机器上、每个服务节点的请求状态等等。

目录：

1.链路追踪的应用场景
2.链路追踪基本原理
3.链路追踪的Demo实现
4.普元微服务平台的链路追踪应用

1.链路追踪的应用场景移动平台8.0打开了以往eclipse平台的枷锁，全面拥抱了主流的VSCode编辑器，包括支持实用的cli命令行支持、及优秀的跨平台开发框架ReactNative 。

文章插图

在微服务架构下，分布式系统变得日趋复杂，越来越多的组件开始走向分布式化，如微服务、分布式数据库、分布式缓存等，使得后台服务构成了一种复杂的分布式网络，这样一个场景下，对于用户的每一次请求调用，后端执行了多少组件间的调用无法知晓，由于分布式的调用，增加了程序调用异常的错误率，在这样的应用场景下，新的架构技术带来了新的问题。
场景下的关键问题
1. 如何在请求发生异常时快速定义问题所在
2. 如何在请求响应慢的时候快速找出慢的原因
3. 如何通过日志文件快速定位问题的根本原因
传统的问题排查手段
一般在系统发生问题时，比如系统异常或者系统性能出现问题时，通常都是从系统记录的日志文件中找出蛛丝马脚，而对于微服务架构下的分布式部署，日志文件的分散，想从日志中查找问题工作量很大。对于用户某一次请求调用后端哪些服务，每个服务执行情况，想从日志中获得更是不可能的事。
对于传统的监控告警平台也紧针对平台资源的监控包括cpu、内存、网络带宽情况等，对业务微服务应用的指标（平均响应时间、慢端点情况等）的监控显得无从下手。

文章插图

在这样的背景下，新的监控体系下的细分领域-链路追踪问世了。

文章插图

首先，我们来看看在系统监控的体系下具体的细分领域的专注点：
Logging - 用于记录离散的事件。例如，应用程序的调试信息或错误信息。它是我们诊断问题的依据。
Metrics - 用于记录可聚合的数据。例如，队列的当前深度可被定义为一个度量值，在元素入队或出队时被更新；HTTP 请求个数可被定义为一个计数器，新请求到来时进行累加。
Tracing - 用于记录请求范围内的信息。例如，一次远程方法调用的执行过程和耗时。它是我们排查系统性能问题的利器。
2.链路追踪基本原理在每个请求调用的入口和出口进行代码埋点记录调用之间的关系、每个调用处理时间点信息。
通过调用关系梳理出一次请求的完整链路还原、请求具体到达哪台机器。
通过每次处理记录的时间点，计算出相关的调用执行时间、响应时间、网络延时。
对调用请求量进行统计。
显示链路拓扑结构、应用依赖关系。