一、相关背景

在上一篇关于API暴露等级的文章中，我们提到：

首先，很多时候服务的接口会在自身不知情的情况下被其他服务调用，这种情况其实比较常见。这是由于服务接口本身并没有注册到网关，同时也没有做非常详细的白名单限制，从而造成：
可能服务A本身给服务B提供了某个接口的使用，但是服务B发现服务A的另一个接口也比较有用，于是使用了同样的认证方法去直接调用了服务A的这个接口，但服务A此时是不知情的。
首先服务A可能会对该接口做不兼容修改、甚至可能会直接将该接口下线掉，但服务B在不知情的情况下依赖于该接口的业务就会受损。
更严重的，服务B并不清服务A对于该接口的性能承载极限，当调用量达到一定程度后，服务A可能直接会由于该接口的调用将整个系统拖垮（例如数据库连接数持续维持在极限而挤压其他正常业务）。

在接服务对外暴露的接口中，其存在目的就是为了能够被其他服务所调用。但是如果服务不知道谁在调用、调用频率是什么、流量有多大、调用时间段是什么，则是一个非常严重的问题：如果不加以识别、管控，很轻易就会将服务的相关资源耗尽、引发严重的现网问题，这其中还包含接口的异常调用、大象流/老鼠流等问题，都是我们需要格外关注的。

一般而言，如果接口妥善的在API网关注册、开放授权，并提供合理的流控与熔断措施，上述问题是不会发生的。但是理想很丰满、现实很骨感，很多时候服务接口在被调用时根本不知道是在被谁调，有时在出现现网事故后都要优先去找到接口调用方、手动限流，不仅机械、而且响应被动缓慢。

针对这种情况，笔者基于APM调用链数据，对服务调用情况进行了逆向获取与分析，解析每个接口的调用者与被调用者，再根据服务的归属关系，就能够分析出接口调用方。

二、基于调用链的逆向分析举措

在调用链层面，每一个节点所代表的就是一个个实例、也即包含环境信息的微服务，而连接节点之间的箭头则代表了每一个接口。
因此，原理上其实很简单，我们只需要找到实际的后端节点（一般是Tomcat类型），然后找到节点的接口提供信息、以及主动调用者信息，再结合以公司层级的服务树信息，判断二者是否处在不同服务划分下，就能够获悉接口的具体暴露情况、以及被调用者情况。

同时，结合接口对外暴露基本属性做辅助分析：

如果被定义为OpenAPI，那么被调用是没有问题的，我们可以从APIG注册的维度来做二次分析，看接口在调用上是否没有走网关、是否是直接被调用的。
- 如果接口调用没有走网关，本身也是存在高风险的，需要尽快敦促服务将接口注册到网关之上、并推动调用方进行调用方式整改。
如果接口并没有被定义为OpenAPI，那么根据我们上一篇文章所说，就应当从逆向评估的维度将接口基础属性定义为OpenAPI。