微服务应用故障定位系统实现原理剖析( 二 ) _大数据

文章插图
第二部分：后台。
探针采集了数据后需要后台分析，我们先看一个真实每天都在上演的业务场景，用户在页面发起“添加购物车”、“从购物车删除商品”、“从购物车进入商品结算”等等，其实整个系统运行的每一秒都在发生着N个用户请求，每个请求的链路调用请求不完全一致，对于添加购物车服务来说：购物车服务B调用用户服务C、C调用商品服务D；对于从购物车删除商品来说：购物车服务B调用商品服务D、商品服务D调用商品库存服务E；对从购物车进入商品结算来说，购物车服务B调用结算服务E、支付服务F….就这短短的一秒钟，产生了B->C->D、B->D->E、B->E->F….的服务链路，如果其中的某次调用C->D出了问题，那么B系统的研发人员完全不知道问题出现在哪里了。这个时候我们要引入两个专业的名词、。
对于故障问题的定位，通过就可以进行跟踪。用户的请求一发起，我们就给它打上了的标签，随着这个请求继续的往后面发生调用，就继续跟着到了下游系统中，一直到请求的调用执行完成，而所有的执行都会记录在日志中。当某次调用发生错误时，我们只要获取到这个，在整个日志中进行搜索，就可以知道它卡在哪里了，找到了问题的根本原因。
对于调用链路的梳理，通过就可以进行还原。当整个用户请求开始发生时，我们把第一次链路的调用赋值为0，每深入一次就叠加一次，比如B->C->D中，B->C是0.1、C->D是0.1.1;每进行一次同深度的调用再自加一次，比如B->D->E中，B->C是0.2、C->D是0.2.1 。后台系统通过上万笔的调用链路分析处理，最终会给到一个链路调用拓扑图。

文章插图
因为监控代码在代码的执行都进行了埋点，所以通过代码开始和代码结束的时间戳对比就能获取到整个代码执行的时间和次数，进而获取到用户请求的执行时间和执行次数，再进而获取到服务的执行时间和执行次数，再再获取到整个应用的执行时间和执行次数，后台把数据处理好了之后传递给到前端，就可以呈现给到用户整个微服务应用的执行情况了，程序员哥哥们再也不用担心微服务应用的故障问题找不到，天天996了。

文章插图
只谈微服务架构的设计，而不谈其出现的问题与解决方案便是耍流氓。
在微服务架构时代，对于整个系统的监控、调用链路的追踪、服务的熔断限流等机制都是必不可少的。
【微服务应用故障定位系统实现原理剖析】工欲善其事，必先利其器。随着云计算、5G、人工智能等的普及应用，容器技术、的广泛应用，微服务必定是会大放异彩，而其背后的助力无疑是整个监控系统～