soul源码解读（十五）-- springcloud插件原理分析

准备工作

照着之前的文章启动好服务

sprincloud插件初体验

1.启动 admin ，打开 springcloud 插件开关

2.启动 eureka 服务

3.在 bootstrap 的 pom.xml 文件中放开 springcloud plugin 和 eureka 依赖的注释，加上 eureka 配置，然后启动 bootstrap 服务

4.启动两个 soul-examples-springcloud 项目，端口分别为8884和8885

eureka 上的服务节点如下：

sprigncloud插件分析

用 postman 调用接口 http://localhost:9195/springcloud/order/findById?id=3

在 SoulWebHandler$DefaultSoulPluginChain#execute 打断点

发现，一个 springcloud 的请求过来之后，会经过 soul 的插件链处理。

第一个插件是 GlobalPlugin ,用来设置请求的一些参数，比如下面的 rpcType

// GlobalPlugin.java
soulContext = builder.build(exchange);

// DefaultSoulContextBuilder.java
public SoulContext build(final ServerWebExchange exchange) {
	...
	return transform(request, metaData);
}

// DefaultSoulContextBuilder.java
private SoulContext transform(final ServerHttpRequest request, final MetaData metaData) {
 	...
 	if (RpcTypeEnum.SPRING_CLOUD.getName().equals(metaData.getRpcType())) {
                setSoulContextByHttp(soulContext, path);
                soulContext.setRpcType(metaData.getRpcType());
}

这样后面的插件，会根据请求里的参数，去判断需不需要跳过。

GlobalPlugin 插件之后，我们继续往后执行插件链，其他插件链跳过，当执行到 SpringCloudPlugin 的时候，会去匹配选择器和规则

// AbstractSoulPlugin.java
public Mono<Void> execute(final ServerWebExchange exchange, final SoulPluginChain chain) {
    ...
    // 判断插件是否为空，是否开启
    if (pluginData != null && pluginData.getEnabled()) {
        // 从缓存获取选择器
        final Collection<SelectorData> selectors = BaseDataCache.getInstance().obtainSelectorData(pluginName);
        // 匹配选择器
        final SelectorData selectorData = matchSelector(exchange, selectors);

        // 从缓存获取规则
        final List<RuleData> rules = BaseDataCache.getInstance().obtainRuleData(selectorData.getId());
        // 匹配规则
        RuleData rule;
        if (selectorData.getType() == SelectorTypeEnum.FULL_FLOW.getCode()) {
            rule = rules.get(rules.size() - 1);
        } else {
            rule = matchRule(exchange, rules);
        }
        // 执行具体插件里的逻辑
        return doExecute(exchange, chain, selectorData, rule);
    }
    // 跳到下一个插件
    return chain.execute(exchange);
}

然后进入到具体插件里的逻辑里

// SpringCloudPlugin.java
protected Mono<Void> doExecute(final ServerWebExchange exchange, final SoulPluginChain chain, final SelectorData selector, final RuleData rule) {
	...
    final SoulContext soulContext = exchange.getAttribute(Constants.CONTEXT);
    
	// 负载均衡，这里的负载均衡和divide插件不一样，用的是SpringCloudP自带的
    final ServiceInstance serviceInstance = loadBalancer.choose(selectorHandle.getServiceId());
    final URI uri = loadBalancer.reconstructURI(serviceInstance, URI.create(soulContext.getRealUrl()));
	
    String realURL = buildRealURL(uri.toASCIIString(), soulContext.getHttpMethod(), exchange.getRequest().getURI().getQuery());
    // 设置服务真实请求的地址
    exchange.getAttributes().put(Constants.HTTP_URL, realURL);
	...
    return chain.execute(exchange);
}

springCloud 服务的负载均衡策略是在自己服务的配置文件里配置的

// soul-examples-springcloud  application.yml
springCloud-test:
  ribbon.NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

springCloud 插件执行完之后，后面的逻辑就和 divide 插件一样了，通过 webClient 插件执行请求，最后通过 webClientResponse 插件返回数据。

我们多次调用接口，发现看到网关调用的实际地址是在8884和8885之间随机的，说明 springCloud 配置的负载均衡算法是真生效的。

总结

springCloud 插件和 divide 插件其实逻辑差不多，只是负载均衡那里有些不一样，divide 插件是自己实现的负载均衡算法，springCloud 插件用的是自己生态体系里自带的负载均衡组件。