Java教程

系统化服务构建-调用链管理

本文主要是介绍系统化服务构建-调用链管理,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

素材200102.jpeg

这篇文章探讨应用开发中的调用链管理,涉及到的主要知识有日志,接口及服务的定义,监控和微服务注册。

调用链管理

调用链管理是服务架构中的一项基本职责,也是一项服务能力。主要使用TraceId和SpanId,跟踪服务的调用依赖关系,串起整个服务调用路径,方便上下游服务的监控,管理。

先不用说微服务这么高大上的系统,通常的应用系统,在实现某项功能时,会涉及到各种外部依赖,或接口,或服务,或组件,整个调用链条的生命周期就是调用链管理。

关键概念

本文在谈论调用链管理时,有几个概念明确如下

上游服务(消费者)

上游服务是 调用者所依赖的服务的统称,这里的服务可以是单独的接口,也可以是一组接口组成的功能集合。

实际上这里有一个核心问题是如何定义服务。

从接口数量的纬度,无论单个接口,多个接口组成的功能集合,多个功能组成的组件,都可以叫做服务。

从服务必备的属性来看,主要包括服务名(接口名),域名,URL(地址),方法和参数。

从微服务的概念纬度来看,服务包括提供者服务,和消费者服务。再深度一点,就涉及到服务注册中心的相关理论了。

本小节的上游服务,特指提供者服务。

下游服务(调用方)

调用方就是服务消费者。

在某一项功能的调用链过程中,调用方就不局限在前端Js了,调用方更多的是下游服务。这里涉及到计算机网络的两种通信方式,C/S方式和 P2P(点对点对等方式)。

P2P点对点的核心解释就是网络上的计算节点既是服务的提供者,为其它计算节点提供服务,又是消费者,依赖于其它服务。

LevelId

调用链的唯一编号,一般由首次调用的发起者生成,全局唯一。

上游服务异常

下游业务基于上游服务做业务,如何定义上游服务异常?

第一种情况

上游地址错误,造成访问异常,简单来说,接口没有返回,接口域名错误,接口地址错误404,http通道直接报错

第二种情况

上游地址域名正确,接口地址正确,但是服务停止了,接口返回Null,尤其是基于Java的服务,有的人喜欢默认Null

以上两种情况 下游在处理时,可以以 ["message"] 的形式,统一定义【上游服务异常】状态码,进行错误直接输出,来标记服务没有获取到数据的情况。基于一个准则,做对外输出的统一化。

第三种情况

上游服务访问相应时间长,造成超时。

作为调用方如何捕获接口调用方的请求超时,是个值得研究的问题。

调用链管理的作用

进行调用链管理的目的是维护程序稳定,功能可用,保证应用系统的弹性。

通过调用链管理,可以快速定位问题,通过自定义【上游服务异常】状态码的方式,定位问题出现在上游服务层面,还是本服务的数据处理层面。

如果接口是跨部门调用的,那么这就是其他部门的责任了。责任更明确。

下面阐述下如何做调用链管理,主要包括生成链路Id,记录请求输出日志,分析和预警。

生成链路Id

链路Id 由前端生成还是后端生成?

图片是公开资料的一张PPT

TrackId.png

链路Id 由一次调用的入口方生成,不一定是前端。

以下代码是YII2中链路Id生成示例

public static function createRequestId()
    {
        //$prefix = $module; 
        $prefix = Yii::$app->controller->module->id;
        session_create_id(date('YmdHis'));
        // 使用uniqid()方法创建唯一id
        $requestId = strtoupper(md5(uniqid($prefix, true)));
        return $requestId;
    }

记录日志

形式化描述监控模型

以下描述摘录自一篇论文,文中的形式化描述的五元组的过程,实际上就是监控建模的过程。

一次追踪有全局的 TraceId 来标识,追踪中的每个调用请求都有唯一的 LevelId, 为了更好地描述后续概念,这里我们首先对每个调用请求进行形式化描述。

LevelId就是上文中的TraceId或者链路Id

定义 五元组𝑅=(𝐿𝑒𝑣𝑒𝑙𝐼𝑑,𝑆𝑒𝑟𝑣𝑖𝑐𝑒,𝑀𝑒𝑡h𝑜𝑑,𝑃𝑎𝑟𝑎𝑚𝑠)来描述每个请求信息 所包含的特征信息,称之为特征向量。LevelId 用来标识请求信息,LevelId 在一次追 踪中唯一,为多级编号。
Service 表示请求信息所请求的服务名称,
Method 表示请求信息调用的方法名称,
Params 表示请求信息所带参数集合。

程序在每个节点记录日志时,可以借助形式化描述的属性,进行记录,持久化方式可以以日志形式,也可以用数据库形式。

如何检测请求超时?

第一种方式,借助于HTTP等调用组件的超时参数设置

第二种方式,服务器(服务方)检测时间差,客户端(请求方)请求时间与服务器(服务方)时间的差值与超时时间做对比

当接口查询不到数据时,接口code应该如何设计?

接口下游何时应该直接输出上游接口的message,或者说上游是否应该重新messgae。

参考一种实现方式,对于【上游服务异常】的状态码进行统一,而【Message】进行原样输出。

但是有一点需要保证,保证输出到本系统的返回数据json结构是完整的,即符合

data
message
code

的结构,缺一不可。

不完整的输出结构,就意味者更多的判断逻辑和沟通。输出完整的json结构,方便调用方的统一管理和维护通讯协议的标准化,标准化就代表着低成本和高效率。

服务雪崩效应

多个服务层调用,基础服务的故障可能会导致级联故障,进而造成整个系统不可用的情况,这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程。

淘宝鹰眼是基于网络调用日志的分布式跟踪系统,它可以分析网络请求在各个分布式系统之间的调用情况,从而得到处理请求的调用链上的入口URL、应用服务的调用关系,从而找到请求处理瓶颈,定位错误异常的根源位置。

监控做到业务无侵入

监控能做到业务无侵入,可插拔 就是最高境界了。常规的应用系统很难做到这一点,也鲜有能力维护。横切关注点,边车模式都是实现业务无侵入的一些尝试方案。

横切关注点

在软件开发过程中,横切关注点指的是散布于软件应用中多处的功能,这些功能
与业务逻辑相分离(但是往往又会直接内嵌在应用的业务逻辑之中)。把这些横切关
注点与业务逻辑进行解耦分离正是 AOP 要解决的问题。

常见的横切关注点有操作日志的生成、安全检测、事务处理等等,分布式追踪中对于追踪信息的采集记录也可以当做一个横切关注点。

总结

本文围绕调用链管理,对相关的概念和使用场景进行描述,总体来说,调用链管理也是有生命周期和通用实施策略的。

首先使用链路Id作为串联,在各个计算节点记录完整的输入输出日志。

其次对日志进行一些常规分析,量化数据指标,对关键业务进行更加详细的记录和分析。
最后是及时的预警和反馈。

按照这样的步骤,最基础的调用链管理功能就完成了。如果要再深入研究,主要的方向就是结合日志,配合可视化UI,在分布式链路跟踪上。


图南日晟.jpg

这篇关于系统化服务构建-调用链管理的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!