Spring依赖可视化分析与微服务模块划分

前言

19年的时候，主要负责微服务治理平台BOMS交付工作，期间客户提到在微服务模块拆分方面需要咨询。

当时我还只是技术负责人，没有深入了解这方面的需求，只是网上找了点资料发给客户，再结合材料简单讲一下“正交分解”等原则。

后来听说客户找到埃森哲做培训，每天的培训费用大概是好几千，后面领导打算让我当架构师，可惜我拒绝了，现在想想非常可惜，但我并不是想做培训老师， 而是想能不能制作一款可视化的分析工具，给微服务模块拆分提供可量化的拆分依据，以及评估拆分前后的性能指标变化。

Spring依赖分析

我首先想到基于代码扫描的静态分析，得益于 Spring 的架构优势，做起来并不难，只需要把 Spring IoC 容器保存的 Bean 信息导出来即可，而正好 Spring Boot Actuator 模块刚好提供 /beans 接口用于导出Bean信息，Bean信息结构大概如下：

{
    "contexts": {
        "school-service": {
            "beans": {
                "spring.jpa-org.springframework.boot.autoconfigure.orm.jpa.JpaProperties": {
                    "aliases": [],
                    "scope": "singleton",
                    "type": "org.springframework.boot.autoconfigure.orm.jpa.JpaProperties",
                    "resource": null,
                    "dependencies": []
                }
            }
        }
    }
}

对于没有使用 Spring Boot 的老旧项目，以下就是参考 Actuator 源码实现的替代实现：

package com.springcloud.school;

import com.fasterxml.jackson.annotation.JsonProperty;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.config.BeanDefinition;
import org.springframework.beans.factory.config.ConfigurableBeanFactory;
import org.springframework.beans.factory.config.ConfigurableListableBeanFactory;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ConfigurableApplicationContext;
import org.springframework.stereotype.Component;
import org.springframework.util.StringUtils;
import java.util.HashMap;
import java.util.Map;

@Component()
public class CustomBeansEndpoint {
@Autowired
ConfigurableApplicationContext context;

public ApplicationBeans beans() {
    Map contexts = new HashMap<>();

    for(ConfigurableApplicationContext context = this.context; context != null; context = getConfigurableParent(context)) {
        contexts.put(context.getId(), ContextBeans.describing(context));
    }

    return new ApplicationBeans(contexts);
}

static ConfigurableApplicationContext getConfigurableParent(ConfigurableApplicationContext context) {
    ApplicationContext parent = context.getParent();
    return parent instanceof ConfigurableApplicationContext ? (ConfigurableApplicationContext)parent : null;
}

public static class BeanDescriptor {
    @JsonProperty("aliases")
    String[] aliases;
    @JsonProperty("scope")
    String scope;
    @JsonProperty("type")
    Class type;
    @JsonProperty("resource")
    String resource;
    @JsonProperty("dependencies")
    String[] dependencies;

    private BeanDescriptor(String[] aliases, String scope, Class type, String resource, String[] dependencies) {
        this.aliases = aliases;
        this.scope = StringUtils.hasText(scope) ? scope : "singleton";
        this.type = type;
        this.resource = resource;
        this.dependencies = dependencies;
    }
}

public static class ContextBeans {
    @JsonProperty("beans")
    Map beans;
    @JsonProperty("parentId")
    String parentId;

    ContextBeans(Map beans, String parentId) {
        this.beans = beans;
        this.parentId = parentId;
    }

    static ContextBeans describing(ConfigurableApplicationContext context) {
        if (context == null) {
            return null;
        } else {
            ConfigurableApplicationContext parent = getConfigurableParent(context);
            return new ContextBeans(describeBeans(context.getBeanFactory()), parent != null ? parent.getId() : null);
        }
    }

    static Map describeBeans(ConfigurableListableBeanFactory beanFactory) {
        Map beans = new HashMap<>();
        String[] var2 = beanFactory.getBeanDefinitionNames();
        int var3 = var2.length;

        for(int var4 = 0; var4 < var3; ++var4) {
            String beanName = var2[var4];
            BeanDefinition definition = beanFactory.getBeanDefinition(beanName);
            if (isBeanEligible(beanName, definition, beanFactory)) {
                beans.put(beanName, describeBean(beanName, definition, beanFactory));
            }
        }

        return beans;
    }

    static BeanDescriptor describeBean(String name, BeanDefinition definition, ConfigurableListableBeanFactory factory) {
        return new BeanDescriptor(factory.getAliases(name), definition.getScope(), factory.getType(name), definition.getResourceDescription(), factory.getDependenciesForBean(name));
    }

    static boolean isBeanEligible(String beanName, BeanDefinition bd, ConfigurableBeanFactory bf) {
        return bd.getRole() != 2 && (!bd.isLazyInit() || bf.containsSingleton(beanName));
    }
}

public static class ApplicationBeans {
    @JsonProperty("contexts")
    Map contexts;

    ApplicationBeans(Map contexts) {
        this.contexts = contexts;
    }

    public Map getContexts() {
        return this.contexts;
    }
}

}

新建 CustomBeansEndpoint.java 文件，然后把以上Java代码复制粘贴进文件中，最后新增 BeanController

package com.springcloud.school.controller;

import com.springcloud.school.CustomBeansEndpoint;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController@RequestMapping("/beans")
public class BeanController {
    @Autowired()
    CustomBeansEndpoint beansEndpoint;
    @GetMapping("/")
    public Object beans() {
        return beansEndpoint.beans();
    }
}

把代码修改完再运行起来，在浏览器打开 https://localhost:8080/beans 就会返回JSON内容，然后复制JSON字符串保存到 beans.json 文件。

切记：为了稳妥起见，建议只在开发环境运行，不要提交或部署到生产/预生产环境，以免造成不可挽回的损失。

可视化分析

有了JSON数据，就可以进行可视化分析，首先去下载安装 Spring Module Analyzer 工具。

这是一款基于Qwik + Echarts 打造，专门用于Spring模块可视化分析的工具。目前该工具使用 tauri 打包成Web App，支持 Windows Mac Linux 等平台（暂不支持win7、xp），可以根据实际需求下载安装后进行使用。

打开工具后，在首页点击中间的 开始 按钮，选中上一步导出的 beans.json 文件，然后就自动跳转到 依赖分析 页面

看到满屏密密麻麻的文字先别慌，因为actuator导出的bean很多是spring框架自带的，可以在左上方 类名 右侧的输入框，输入你的 package 包名，然后点击最右侧的 过滤 按钮就可以把多余的bean过滤掉。比如输入 com.springclcoud 再点击 过滤 按钮：

现在可以看到不相干的bean已经被过滤掉，还可以通过鼠标滚轮来缩放画面。

如果你的项目包含的bean数量非常多，可以追加子包名进行过滤，比如说 com.springcloud.school ，

随着包名的不断变长，原来连成一片的点集，会分割成几个相互独立的小点集，这些小点集就相当于划分好的微服务模块。

以上基于代码的静态分析，实际上就是基于包名进行微服务模块划分，有一个非常重要的前提就是先前的项目结构需要非常合理，而实际情况却是大部分项目结构非常混乱，因此以包名作为微服务模块划分的依据并不合理。

但是有这么一个工具，可以非常直观了解现有的项目结构，评估微服务模块拆分之前的代码质量还是很有帮助的，尤其是当你刚接手一个完全陌生的项目，spring 依赖分析是快速了解项目结构的有力工具。

调用链分析

前面说到的静态分析虽然非常直观，但明显缺乏量化指标。

比方说 A模块 同时依赖于 B模块 和 C模块 ，A模块 每分钟会调用 B模块 上百次，但只会调用 C模块 一次，这种情况静态分析是无法进行有效的模块划分，因此我们需要在运行时收集数据才能正确划分。

简单来说，就是通过 Spring AOP 给特定包下的所有方法织入一段代码逻辑，用于统计各模块之间相互调用的次数以及耗时，具体做法就是新建 Profile.java 文件，然后写入以下代码：

package com.springcloud.school;

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.springframework.stereotype.Component;
import java.util.Stack;

@Aspect
@Component
public class Profile {
    // ThreadLocal用于解决线程安全问题，每个线程的方法栈是独占的，因此可以避免冲突
    ThreadLocal> methodStack = new ThreadLocal<>() {
        @Override
        protected Stack initialValue() {
            return new Stack<>();
        }
    };

    @Around("execution(* com.springcloud.school..*.*(..)) && !bean(profile)")
    public void count(ProceedingJoinPoint pj) {
        Stack stack = methodStack.get();
        String peak = stack.empty() ? "root" : stack.peek();
        String className = pj.getSignature().getDeclaringTypeName();
        stack.push(className);
        long start = System.currentTimeMillis();
        try {
            pj.proceed();
        } catch (Throwable e) {
            throw new RuntimeException(e);
        } finally {
            long end = System.currentTimeMillis();
            long gap = end - start;
            // 这里选择直接把调用记录输出到日志，有条件的可以选发送到消息队列进一步处理
            System.out.println("trace: " + peak + " -> " + className + " : " + gap);
            stack.pop();
        }
    }
}

解释一下统计调用次数以及耗时的思路：

首先初始化一个栈，然后每当方法被调用之前，就把方法名称入栈，方法调用结束后就出栈，然后把结果输出到日志文件或者消息队列，这里为了方便演示直接用 System.out.println。

这里记得把 @Around("execution(* com.springcloud.school..*.*(..)) && !bean(profile)") 的 com.springcloud.school 换成你项目所用的包名，至于最右边的 !bean(profile) 就是把 Profile 类给排除，因为我把 Profile.java 也保存到 com.springcloud.school 下。

接着把修改后的代码放到环境上运行，然后跑一下全量接口测试，测试尽可能覆盖所有的业务模块，根据实际情况调整收集时长，等积累足够多的调用记录，就可以进行下一步：处理收集结果。

切记：为了安全起见，建议只在开发环境运行，不要提交或部署到生产/预生产环境，以免料

这里只说输出到日志的处理方法，首先根据前缀 trace: 过滤得到相关的调用记录，然后把每行的箭头 -> 和 冒号 : 替换成逗号 , ，然后保存到 trace.csv 文件，最终的文件结构如下：

com.springcloud.school.controller.BeanController,com.springcloud.school.CustomBeansEndpoint,10
root,com.springcloud.school.controller.BeanController,39
com.springcloud.school.service.BaseServiceImpl,org.springframework.data.repository.PagingAndSortingRepository,323

第一列是调用方，第二列是被调用方，第三列是耗时，三者通过逗号分割，只要符合这个规则的csv文件就可以被用于可视化分析。

因此微服务模块划分的粒度最小也是类，很少到方法级别，所以调用方和被调用方其实是方法所属的类，而不是方法名。

可视化分析

我们重新打开之前的 Spring Module Analyzer 工具，然后点击右边 链路分析 按钮，再点击下方 开始 按钮，选择之前保存 trace.csv 文件，然后点击 确定 按钮

进入 链路分析 页面，左上角 起点 和 终点 两个输入框，可以根据包名进行过滤，和之前的依赖分析大同小异

和前面不同的是多了 求值 下拉框，以及 范围 输入框。

“求值” 有五个选项：计数、平均值、求和、最小值 和 最大值 。以下是各选项适用的场景：

• 计数 ：就是累计两个模块之间的调用次数，可以配合调高范围的下界，来过滤掉某些出现次数很少的调用记录，从而分离出更多的点集，自动完成模块划分；也可以调低范围的上限，过滤某些因为循环或递归调用频繁出现的记录；
• 平均值：就是用总的耗时除以总的调用次数，得出每次调用方法的平均耗时，可用于评估微服务模块划分前的实际延迟，一般平均耗时低于100毫秒的模块不宜拆分，因为微服务模块之间RESTful接口调用基本上都大于100毫秒，把原本平均耗时大于100毫秒的模块拆分到不同微服务并不会显著增加系统延迟；
• 求和 ：两个模块之间相互调用所需要的总耗时
• 最小值 ：两个模块之间相互调用耗时的最小值
• 最大值 ：两个模块之间相互调用耗时的最大值

总结

基于Spring依赖的可视化分析，可以快速大概掌握项目结构的基本情况，同时也能直观地感受代码架构是否符合 低耦合高内聚 的要求，对后续的代码重构优化也有一定的指导作用；在对项目结构有基本的了解后，就可以结合调用链分析，在微服务模块拆分之前，对系统整体的性能指标有确切的数据，也能通过和图表的交互，大致预估微服务模块拆分后的项目结构以及系统性能的变化。

我做这个工具的初衷，是因为职业生涯中，经常遇到空降的大厂架构师之类的人物，在没有充分了解项目现况的情况下，强行推行从别的企业生搬硬套的软件架构，结果往往导致项目进展受阻的情况；而熟悉项目的低级开发人员却没有任何发言权，但凡提出质疑总会被大厂光环的title压制。

这个可视化分析工具可以提供可量化的指标，可以打破领导对大厂经验的迷信，刹住行业的歪风邪气，让行业风气重新回到纯粹的理性探讨技术氛围。