把如图2.13所示的这些调用链路关系合并，可以构建一个如图2.11右边所示的完整的方法级别的调用矩阵，微服务间的调用是这个调用矩阵的一个子集。
图2.14是一个真实静态调用链的示例，以一个类方法为起点，找到它调用的所有其他方法，逐层遍历后，就能得到图中所显示的调用层级关系。图2.14-①是这种调用关系的文本描述，从图中可以清晰地看到方法间调用的先后和层级关系。
要注意的是类的实现和继承关系。接口类方法或者抽象类方法是没有具体实现逻辑的，所以在程序扫描时，还需维护类直接的继承和实现关系。接口方法往往用具体的实现类方法来代替，这样就能顺利地找到它的下一层引用关系。
如果引入诸如mxGraph这类图形化展示组件，可以将图2.14-①中类方法间的调用关系用一棵从上至下、从左至右的调用树图来展示，如图2.14-②所示。调用树上每一个节点就是一个类方法，节点间的箭头连线就是一个调用关系。通过JDT能够识别出方法注释，还可以将方法注释在每一个类方法节点的右边列出。如果系统注释完整，那么通过一张图就可以基本读清楚一个微服务入口方法的完整实现细节。
如果一个方法类的结构比较复杂，例如它有IF…ELSE关系或者FOR循环等嵌套调用关系，也可以用JDT识别，将这种关系在调用线条上列出。这样就能清楚地知道这是一种分支调用关系还是一种循环调用关系。
由于扫描的是所有相关工程的代码，一张图上就包含了所有层级的服务或系统之间的RPC调用关系。通过包名来对不同的业务层级（前台、中台、后台）进行识别，并为不同包名的图形单元赋予不同的颜色，通过颜色的区分可以清楚地知道一个方法的调用究竟涉及多少个系统，在每个系统中的入口是什么、出口又是什么等。
这里存在一个问题，就是如何将源码扫描获取到的类方法（微服务的API）与需求/开发任务管理系统中的UserStory和Task关联上？可以强制要求在微服务API入口方法（或者微服务类声明）的注解（例如JavaDoc）上标注UserStory和Task的ID，扫描源码时通过对注解的解析即可将方法和需求或任务进行关联。不用担心开发人员不标注或者忘了标注，因为我们可以通过比对需求列表和源码的映射关系来监控开发人员是否贯彻了注解标注规范，如果有需求没有找到对应的方法或API入口，即可自动通知相应的开发人员及时修改。
有了以上信息，通过对最终构建出来的大调用矩阵不同维度的分析，可以获得很多微服务的开发及设计质量方面的度量信息，包括请求的调用链深度、服务间的依赖程度、服务的粒度等。这些度量信息将会作为微服务治理的度量及判定依据。
小贴士
笔者另外准备了一个更完整的JDT-AST源码解析示例，能够详细展示如何通过对一个Java类文件的解析来获得类的相关调用关系，限于篇幅，就不在本书中贴出其详细源码了，请读者自行从本书的GitHub源码下载站点中下载并运行，体验解析过程。
