共计 8242 个字符，预计需要花费 21 分钟才能阅读完成。
前言
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 压抑。
这个可视化剖析工具能够提供可量化的指标，能够突破领导对大厂教训的科学，刹住行业的歪风邪气，让行业风尚从新回到纯正的感性探讨技术气氛。