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

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

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

调用链管理

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

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

关键概念

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

上游服务（消费者）

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

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

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

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

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

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

下游服务（调用方）

调用方就是服务消费者。

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

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

LevelId

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

上游服务异常

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

第一种情况

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

第二种情况

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

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

第三种情况

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

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

调用链管理的作用

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

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

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

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

生成链路Id

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

图片是公开资料的一张PPT

链路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，在分布式链路跟踪上。

---

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