Soul网关 之SpringMvc 接口注册网关流程
在上一节我们已经大概看到了在SpringMvc体系下，Soul是如何实现对接口的查找以及注册，接下来让我们接着追踪一下，接口地址在注册网关后到底发生了什么。
流程跟踪
根据上一章所讲，soul是通过http将接口注册的，这个接口地址如下图（/soul-client/springmvc-register）
public ContextRegisterListener(final SoulSpringMvcConfig soulSpringMvcConfig) {
ValidateUtils.validate(soulSpringMvcConfig);
this.soulSpringMvcConfig = soulSpringMvcConfig;
url = soulSpringMvcConfig.getAdminUrl() + "/soul-client/springmvc-register";
}
在soul的admin中查找这个接口
@RestController
@RequestMapping("/soul-client")
public class SoulClientController {
/**
* SpringMvc 接口注册
* @param springMvcRegisterDTO
* @return
*/
@PostMapping("/springmvc-register")
public String registerSpringMvc(@RequestBody final SpringMvcRegisterDTO springMvcRegisterDTO) {
return soulClientRegisterService.registerSpringMvc(springMvcRegisterDTO);
}
}
再查找service层对应方法 由于再传递时没有要求注册元数据 所以直接进入了if的下层逻辑
public String registerSpringMvc(final SpringMvcRegisterDTO dto) {
//判断是否需要注册元数据
logger.info("SpringMvc 传递的注册DTO为 {}",dto.toString());
if (dto.isRegisterMetaData()) {
//此处if逻辑并没有执行
//判断是否有该数据的元数据
MetaDataDO exist = metaDataMapper.findByPath(dto.getPath());
if (Objects.isNull(exist)) {
//没有直接注册
saveSpringMvcMetaData(dto);
}
}
//处理传递的dto 返回选择器ID
String selectorId = handlerSpringMvcSelector(dto);
//根据选择器ID 和对应的dto 进行数据处理
handlerSpringMvcRule(selectorId, dto);
return SoulResultMessage.SUCCESS;
}
确认handlerSpringMvcSelector方法的具体作用 处理程序Spring Mvc选择器 返回了选择器的ID，在此方法逻辑中涉及到了对handle的处理，首先是判断当前选择器的handle是否为空，为空的化将此次更新的值重新刷新到表中，如果不为空的话，判断接入的项目真实地址是否和当前地址一致，如果一致直接返回ID（可能涉及到多个的负载？），不一致的话进行修改库操作，还有服务的加载内存进行监听操作（ upstreamCheckService.submit），最后通过Spring的事件机制发送了一个选择器变更的事件
private String handlerSpringMvcSelector(final SpringMvcRegisterDTO dto) {
String contextPath = dto.getContext();
SelectorDO selectorDO = selectorService.findByName(contextPath);
String selectorId;
//拼装出真实路径
String uri = String.join(":", dto.getHost(), String.valueOf(dto.getPort()));
//判断是否存在该选择器 不存在直接入库
if (Objects.isNull(selectorDO)) {
//注册方法是公有方法，内部还涉及到了服务监控状态的监听
selectorId = registerSelector(contextPath, dto.getRpcType(), dto.getAppName(), uri);
} else {
selectorId = selectorDO.getId();
//update upstream
String handle = selectorDO.getHandle();
String handleAdd;
DivideUpstream addDivideUpstream = buildDivideUpstream(uri);
SelectorData selectorData = selectorService.buildByName(contextPath);
if (StringUtils.isBlank(handle)) {
handleAdd = GsonUtils.getInstance().toJson(Collections.singletonList(addDivideUpstream));
} else {
List<DivideUpstream> exist = GsonUtils.getInstance().fromList(handle, DivideUpstream.class);
for (DivideUpstream upstream : exist) {
if (upstream.getUpstreamUrl().equals(addDivideUpstream.getUpstreamUrl())) {
return selectorId;
}
}
exist.add(addDivideUpstream);
handleAdd = GsonUtils.getInstance().toJson(exist);
}
selectorDO.setHandle(handleAdd);
selectorData.setHandle(handleAdd);
// 修改数据库
selectorMapper.updateSelective(selectorDO);
// 加入到服务监测的队列
upstreamCheckService.submit(contextPath, addDivideUpstream);
// 事件发布 发布类型是选择器，操作类型为修改
eventPublisher.publishEvent(new DataChangedEvent(ConfigGroupEnum.SELECTOR, DataEventTypeEnum.UPDATE,
Collections.singletonList(selectorData)));
}
return selectorId;
}
再看handlerSpringMvcRule的逻辑，基本就是将返回的选择器ID和对应传入的springMvcDto进行了规则组合，最后进行了入库，最终在下面的这个方法中可以看到publishEvent方法，发布了一个 规则相关的变更通知事件。
@Override
public String register(final RuleDTO ruleDTO) {
RuleDO ruleDO = RuleDO.buildRuleDO(ruleDTO);
List<RuleConditionDTO> ruleConditions = ruleDTO.getRuleConditions();
if (StringUtils.isEmpty(ruleDTO.getId())) {
ruleMapper.insertSelective(ruleDO);
ruleConditions.forEach(ruleConditionDTO -> {
ruleConditionDTO.setRuleId(ruleDO.getId());
ruleConditionMapper.insertSelective(RuleConditionDO.buildRuleConditionDO(ruleConditionDTO));
});
}
publishEvent(ruleDO, ruleConditions);
return ruleDO.getId();
}
private void publishEvent(final RuleDO ruleDO, final List<RuleConditionDTO> ruleConditions) {
//省略代码
// publish change event.
eventPublisher.publishEvent(new DataChangedEvent(ConfigGroupEnum.RULE, DataEventTypeEnum.UPDATE,
Collections.singletonList(RuleDO.transFrom(ruleDO, pluginDO.getName(), conditionDataList))));
}
到此 这个关于SpringMvc接口注册的逻辑已经写完了，大概可以看出来，首先是判断有没有当前的contextPath的选择器，registerSelector没有的话直接注册，并且将该服务的地址加载到内存中，实现服务的监测，如果存在就判断是否为空，为空的化直接覆盖，不为空比对当前的contextPath下的地址是否已经存在，如果存在直接跳出，不存在进行统一的改库、服务检测、发布一个选择器相关的修改事件，接下来就是对注册规则的处理，也是大概的逻辑进行改库，然后最后发布一个规则相关的修改事件。
