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

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

调用链管理

调用链管理是服务架构中的一项基本职责，也是一项服务能力。主要使用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，在分布式链路跟踪上。

---