调用链管理
调用链管理是服务架构中的一项基本职责，也是一项服务能力。主要使用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 表示请求信息所带参数集合。
程序在每个节点记录日志时，可以借助形式化描述的属性，进行记录，持久化方式可以以日志形式，也可以用数据库形式。方）时间的差值与超时时间做对比
当接口查询不到数据时，接口code应该如何设计？ 接口下游何时应该直接输出上游接口的message，或者说上游是否应该重新messgae。
参考一种实现方式，对于【上游服务异常】的状态码进行统一，而【Message】进行原样
如何检测请求超时？ 第一种方式，借助于HTTP等调用组件的超时参数设置
第二种方式，服务器（服务方）检测时间差，客户端（请求方）请求时间与服务器（服务方）时间的差值与超时时间做对比
当接口查询不到数据时，接口code应该如何设计？ 接口下游何时应该直接输出上游接口的message，或者说上游是否应该重新messgae。
参考一种实现方式，对于【上游服务异常】的状态码进行统一，而【Message】进行原样输出。
但是有一点需要保证，保证输出到本系统的返回数据json结构是完整的，即符合
data message code
的结构，缺一不可。
不完整的输出结构，就意味者更多的判断逻辑和沟通。输出完整的json结构，方便调用方的统一管理和维护通讯协议的标准化，标准化就代表着低成本和高效率。
服务雪崩效应
多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程。
淘宝鹰眼是基于网络调用日志的分布式跟踪系统，它可以分析网络请求在各个分布式系统之间的调用情况，从而得到处理请求的调用链上的入口URL、应用服务的调用关系，从而找到请求处理瓶颈，定位错误异常的根源位置。
监控做到业务无侵入
监控能做到业务无侵入，可插拔 就是最高境界了。常规的应用系统很难做到这一点，也鲜有能力维护。横切关注点，边车模式都是实现业务无侵入的一些尝试方案。
横切关注点
在软件开发过程中，横切关注点指的是散布于软件应用中多处的功能，这些功能 与业务逻辑相分离（但是往往又会直接内嵌在应用的业务逻辑之中）。把这些横切关 注点与业务逻辑进行解耦分离正是 AOP 要解决的问题。
常见的横切关注点有操作日志的生成、安全检测、事务处理等等，分布式追踪中对于追踪信息的采集记录也可以当做一个横切关注点。
#总结
本文围绕调用链管理，对相关的概念和使用场景进行描述，总体来说，调用链管理也是有生命周期和通用实施策略的。
首先使用链路Id作为串联，在各个计算节点记录完整的输入输出日志。
其次对日志进行一些常规分析，量化数据指标，对关键业务进行更加详细的记录和分析。 最后是及时的预警和反馈。
按照这样的步骤，最基础的调用链管理功能就完成了。如果要再深入研究，主要的方向就是结合日志，配合可视化UI，在分布式链路跟踪上。 #最后 下面是我总结出一个Java程序员的工作2-5年成长路线图。希望对大家有帮助！
上面都是自己整理好的！我就把资料贡献出来给有需要的人！顺便求一波关注，哈哈~各位小伙伴关注我后私信【Java】就可以免费领取哒 原文链接：segmentfault.com/a/119000002…
