微服务间服务(接口)调用关系你还在手工记录吗

前言

微服务已经在越来越多的企业开花。企业在享受微服务优势的同时，会产生一些问题。如随着企业的业务发展，相依的服务数量不断增加，服务调用关系越来越错综复杂。

// money资金服务
@RequestMapping("/getById")
public Dto getById(Long id) {
    User user = userFeignClient.getUserById(userId); // 调用user用户服务
    return productFeignClient.getById(userId); // 调用product商品服务
}

复制代码上述代码是企业web应用中常见的代码，使用spring cloud实现服务间调用。那么，对这个代码，你是否联想到以下场景的问题。

以下对话是软件开发人员经常遇到的。
场景一：我的接口都谁在调用呢

小张：小王，user服务的获取getById()接口被哪些服务使用呢？
小王：原来业务不多的时候，我还知道。现在业务太复杂了，调用方太多，我已经记不清了。
小张：那么办，我接了一个需求，涉及原接口逻辑的变动，这个接口的调用方都要评估下影响面
小王：那你只能挨个负责服务的同事问下了
小张：太麻烦了，时间都用在寻找调用方上了

RD每天的宝贵时间都浪费在了维护服务和接口的调用关系上，为此失去了专研更有价值的业务的精力

场景二：我的服务都调了谁的服务的哪些接口

小姚：小修，我接手了一个product服务，为了尽量熟悉，我需要知道这个服务都依赖哪些服务，调了哪些接口？
小修：这个···，服务有个wiki文档，你看看呢
小姚：我看了，最新的更新时间是一年前
小修：恐怕你只能翻代码了
小姚：一行一行看代码!，我嚎哭

RD每天的宝贵时间都浪费在了维护服务和接口的调用关系上，为此失去了学习新技术的时间

本项目产生的意义就是为了收集和展示服务的调用关系，特别是服务中接口的调用关系。带来的价值为很好的避免了以往只能通过开发人员头脑记忆，要知道记忆是会减退的。所以利于准备评估后续需求开发涉及的影响面。
从而维护项目上线的稳定，增强服务可用性。所以，项目name:微服务梳子。意在自动化理清微服务体系下的服务间关系调用

业务背景

微服务架构的流行，在业务分隔，服务复用，敏捷开