系统化服务构建 - 调用链管理
这篇文章探讨应用开发中的调用链管理,涉及到的主要知识有日志,接口及服务的定义,监控和微服务注册。
调用链管理
调用链管理是服务架构中的一项基本职责,也是一项服务能力。主要使用 TraceId 和 SpanId,跟踪服务的调用依赖关系,串起整个服务调用路径,方便上下游服务的监控,管理。
先不用说微服务这么高大上的系统,通常的应用系统,在实现某项功能时,会涉及到各种外部依赖,或接口,或服务,或组件,整个调用链条的生命周期就是调用链管理。
关键概念
本文在谈论调用链管理时,有几个概念明确如下
上游服务(消费者)
上游服务是 调用者所依赖的服务的统称,这里的服务可以是单独的接口,也可以是一组接口组成的功能集合。
实际上这里有一个核心问题是如何定义服务。
从接口数量的纬度,无论单个接口,多个接口组成的功能集合,多个功能组成的组件,都可以叫做服务。
从服务必备的属性来看,主要包括服务名(接口名),域名,URL(地址),方法和参数。
从微服务的概念纬度来看,服务包括提供者服务,和消费者服务。再深度一点,就涉及到服务注册中心的相关理论了。
本小节的上游服务,特指提供者服务。
下游服务(调用方)
调用方就是服务消费者。
在某一项功能的调用链过程中,调用方就不局限在前端 Js 了,调用方更多的是下游服务。这里涉及到计算机网络的两种通信方式,C/S 方式和 P2P(点对点对等方式)。
P2P 点对点的核心解释就是网络上的计算节点既是服务的提供者,为其它计算节点提供服务,又是消费者,依赖于其它服务。
LevelId
调用链的唯一编号,一般由首次调用的发起者生成,全局唯一。
上游服务异常
下游业务基于上游服务做业务,如何定义上游服务异常?
第一种情况
上游地址错误,造成访问异常,简单来说,接口没有返回,接口域名错误,接口地址错误 404,http 通道直接报错
第二种情况
上游地址域名正确,接口地址正确,但是服务停止了,接口返回 Null,尤其是基于 Java 的服务,有的人喜欢默认 Null
以上两种情况 下游在处理时,可以以 ["message"] 的形式,统一定义【上游服务异常】状态码,进行错误直接输出,来标记服务没有获取到数据的情况。基于一个准则,做对外输出的统一化。
第三种情况
上游服务访问相应时间长,造成超时。
作为调用方如何捕获接口调用方的请求超时,是个值得研究的问题。
调用链管理的作用
进行调用链管理的目的是维护程序稳定,功能可用,保证应用系统的弹性。
通过调用链管理,可以快速定位问题,通过自定义【上游服务异常】状态码的方式,定位问题出现在上游服务层面,还是本服务的数据处理层面。
如果接口是跨部门调用的,那么这就是其他部门的责任了。责任更明确。
下面阐述下如何做调用链管理,主要包括生成链路 Id,记录请求输出日志,分析和预警。
生成链路 Id
链路 Id 由前端生成还是后端生成?
图片是公开资料的一张 PPT
链路 Id
链路 Id 由一次调用的入口方生成,不一定是前端。
以下代码是 YII2 中链路 Id 生成示例
记录日志
形式化描述监控模型
以下描述摘录自一篇论文,文中的形式化描述的五元组的过程,实际上就是监控建模的过程。
一次追踪有全局的 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,在分布式链路跟踪上。
推荐阅读
本文已同步到 公众号《图南日晟》欢迎关注
版权声明: 本文为 InfoQ 作者【图南日晟】的原创文章。
原文链接:【http://xie.infoq.cn/article/e51bbcf4863a429e906e1b398】。文章转载请联系作者。
评论