分析选择器 - 一个让人感动的算法
首先分别启动 soul-admin 、soul-bootstrap , 再启动两个相同的test服务组建集群 soul-test-http.
转到后台管理页的 Divide 插件页, 已经注册了的选择器 http 中, 可以看到两个服务路径的配置:
前置工作准备就绪, 在 DividePlugin 插件这打个断点, 看看 selector 的此时内容:
SelectorData(id=1349650852775989248, pluginId=5, pluginName=divide, name=/http, matchMode=0, type=1, sort=1, enabled=true, loged=true, continued=true, handle=[{"upstreamHost":"localhost","protocol":"http://","upstreamUrl":"192.168.31.233:8187","weight":"99"},{"upstreamHost":"localhost","protocol":"http://","upstreamUrl":"192.168.31.233:8188","weight":"1"}], conditionList=[ConditionData(paramType=uri, operator=match, paramName=/, paramValue=/http/**)])
重点的是 handle 属性, 存放两个真实路径信息, 以及权重 weight .
在 DividePlugin 的 doExecute() 中, 没有直接使用这个 Selector 的内容, 而是直接在缓存查询其id的对应信息:
final List<DivideUpstream> upstreamList = UpstreamCacheManager.getInstance().findUpstreamListBySelectorId(selector.getId());
对于检索到的 DivideUpstream 集合, 有包含权重、路径等信息, 并经过负载均衡工具类, 选择出一个服务:
DivideUpstream divideUpstream = LoadBalanceUtils.selector(upstreamList, ruleHandle.getLoadBalance(), ip);
继续追溯 LoadBalanceUtils 这部分:
public static DivideUpstream selector(final List<DivideUpstream> upstreamList, final String algorithm, final String ip) {
// 通过 algorithm, 确定返回的LoadBalance的子类
LoadBalance loadBalance = ExtensionLoader.getExtensionLoader(LoadBalance.class).getJoin(algorithm);
// 调用LoadBalance的select(), 从服务集群中选择一个节点
return loadBalance.select(upstreamList, ip);
}
这里就有疑问了, algorithm 是由上面 ruleHandle.getLoadBalance() 的信息得来, 而 ruleHandle 应该是规则配置, 仔细看了后台管理页面, 选择器中并没有规则配置, 规则配置被划分在更加细粒度的路径上了.
到这基本明白选择器的玩法了, 集群间的机器, 只有权重分数不同, 具体落实到不同路径上, 可以分配不同的规则.
负载规则总共有三种, hash (哈希)、random (随机)、roundRobin (轮询). 到这又有疑问了, 后面两个我大致能猜测到怎样与权重相作用, 使得实际比率与权重分比相匹配, 但哈希怎么去分呢? 看看 HashLoadBalance 代码吧:
public DivideUpstream doSelect(final List<DivideUpstream> upstreamList, final String ip) {
final ConcurrentSkipListMap<Long, DivideUpstream> treeMap = new ConcurrentSkipListMap<>();
for (DivideUpstream address : upstreamList) {
// 每个节点*VIRTUAL_NODE_NUM(默认5), 使hash更加均匀
for (int i = 0; i < VIRTUAL_NODE_NUM; i++) {
long addressHash = hash("SOUL-" + address.getUpstreamUrl() + "-HASH-" + i);
treeMap.put(addressHash, address);
}
}
// 从当前ip得到一个hash值, 并比对treemap(有序), 找到大于此hash值的位置
long hash = hash(String.valueOf(ip));
SortedMap<Long, DivideUpstream> lastRing = treeMap.tailMap(hash);
// 只要服务节点不增减, 同一个ip得到的节点就可以保持不变
if (!lastRing.isEmpty()) {
return lastRing.get(lastRing.firstKey());
}
return treeMap.firstEntry().getValue();
}
并没有使用到 weight 属性, 可以看到, 当选用 hash 策略时, 权重就失去了其作用. 每个机器都有同等几率, 在某个ip下被访问到.
看下另一个负载均衡规则, RandomLoadBalance 是怎么实现权重的:
public DivideUpstream doSelect(final List<DivideUpstream> upstreamList, final String ip) {
// 总个数
int length = upstreamList.size();
// 总权重
int totalWeight = 0;
// 权重是否都一样
boolean sameWeight = true;
for (int i = 0; i < length; i++) {
int weight = upstreamList.get(i).getWeight();
// 累计总权重
totalWeight += weight;
if (sameWeight && i > 0
&& weight != upstreamList.get(i - 1).getWeight()) {
// 计算所有权重是否一样
sameWeight = false;
}
}
if (totalWeight > 0 && !sameWeight) {
// 如果权重不相同且权重大于0则按总权重数随机
int offset = RANDOM.nextInt(totalWeight);
// 并确定随机值落在哪个片断上
for (DivideUpstream divideUpstream : upstreamList) {
offset -= divideUpstream.getWeight();
if (offset < 0) {
return divideUpstream;
}
}
}
// 如果权重相同或权重为0则均等随机
return upstreamList.get(RANDOM.nextInt(length));
}
PS: 这些注释是官方自带的…
这里可以通过注释很明白的得知, 当使用 random 规则时, 所有节点权重分累加并随机得到数字, 看具体是落在那个节点的权重片段上; 如果分数0或者相同则很直接的随机集群长度即可.
最后看下 `RoundRobinLoadBalance` 的实现:
public DivideUpstream doSelect(final List<DivideUpstream> upstreamList, final String ip) {
String key = upstreamList.get(0).getUpstreamUrl();
ConcurrentMap<String, WeightedRoundRobin> map = methodWeightMap.get(key);
if (map == null) {
methodWeightMap.putIfAbsent(key, new ConcurrentHashMap<>(16));
map = methodWeightMap.get(key);
}
int totalWeight = 0;
long maxCurrent = Long.MIN_VALUE;
long now = System.currentTimeMillis();
DivideUpstream selectedInvoker = null;
WeightedRoundRobin selectedWRR = null;
for (DivideUpstream upstream : upstreamList) {
String rKey = upstream.getUpstreamUrl();
// 取出节点在缓存中的信息
WeightedRoundRobin weightedRoundRobin = map.get(rKey);
int weight = upstream.getWeight();
if (weightedRoundRobin == null) {
weightedRoundRobin = new WeightedRoundRobin();
weightedRoundRobin.setWeight(weight);
map.putIfAbsent(rKey, weightedRoundRobin);
}
if (weight != weightedRoundRobin.getWeight()) {
weightedRoundRobin.setWeight(weight);
}
// 这里是第一个关键: 缓存中的分数增加当前节点权重分
long cur = weightedRoundRobin.increaseCurrent();
weightedRoundRobin.setLastUpdate(now);
// 选择缓存分值高的节点
if (cur > maxCurrent) {
maxCurrent = cur;
selectedInvoker = upstream;
selectedWRR = weightedRoundRobin;
}
totalWeight += weight;
}
if (!updateLock.get() && upstreamList.size() != map.size() && updateLock.compareAndSet(false, true)) {
try {
ConcurrentMap<String, WeightedRoundRobin> newMap = new ConcurrentHashMap<>(map);
newMap.entrySet().removeIf(item -> now - item.getValue().getLastUpdate() > recyclePeriod);
methodWeightMap.put(key, newMap);
} finally {
updateLock.set(false);
}
}
if (selectedInvoker != null) {
// 这里是第二个关键: 缓存中的分数, 减少总节点权重分
selectedWRR.sel(totalWeight);
return selectedInvoker;
}
return upstreamList.get(0);
}
这个算法有点复杂, 我解释下核心计算权重的方面:
- 两个分值分别为2、100的节点进入, 缓存中保留它们各自, 分值从0开始
- 经过for循环后, 两个节点在缓存中的分值会以自身为基数增加, 假设后面步骤不进行, 则缓存第一次为2、100, 第二次为4、200, 依次类推.
- 关键的第三步, 选出节点缓存中分值最高的, 进行"处罚"措施, 减少所有节点的累计分值, 即102.
根据这个算法的步骤, 一直没有被选中的节点, 作为"成长奖励", 会持续以自身为基数自增; 而被选中的节点, 作为"惩罚", 会减少其他节点的权重分之和.
可以预见, 权重分小的节点, 要自增到很久之后, 才会等来自身被选中的一刻, 然而那一刻它被惩罚的力度会非常大, 导致它一朝回到解放前, 又要开始漫长的积蓄力量. 而权重分大的节点, 每次被选上的惩罚力度很小, 即使多次后分数太低没被选上, 他的奖励分数(自身)也特别高, 一次增加就远远超越其他节点.
(就仿佛看到了一个没有天赋但一直努力的平凡人, 然而上天仿佛给他开了玩笑, 每到一定时间, 必然降下天罚, 更可悲的是, 千百次的努力也抵不过一次惩罚, 一切又是归0… 周而往复, 这个平凡的人, 依旧还会用千百次追逐换一次短暂的露头, 可恶, 我被一个算法感动到了!)
分析 Dubbo 服务 - 中道崩殂…
启动 soul-test-alibaba-dubbo-service 项目注册Dubbo服务. 注意要在后台管理的插件管理中, 将Dubbo插件开启, 并运行 Zookeeper 服务.
启动后老习惯, 看看打印的日志里能捞出什么信息:
2021-01-17 00:08:06.702 INFO 2244 --- [pool-1-thread-1] a.d.AlibabaDubboServiceBeanPostProcessor : dubbo client register success :{} {"appName":"dubbo","contextPath":"/dubbo","path":"/dubbo/saveComplexBeanTestAndName","pathDesc":"","rpcType":"dubbo","serviceName":"org.dromara.soul.test.dubbo.api.service.DubboMultiParamService","methodName":"saveComplexBeanTestAndName","ruleName":"/dubbo/saveComplexBeanTestAndName","parameterTypes":"org.dromara.soul.test.dubbo.api.entity.ComplexBeanTest,java.lang.String","rpcExt":"{\"timeout\":10000}","enabled":true}
首先看到启动过程中陆陆续续的打出这类日志, 表示注册了相关Dubbo服务, 这里有资源名、类名方法名等信息, 关键类 AlibabaDubboServiceBeanPostProcessor 中追溯下, 发现还是与http服务的注册基本一样, 老一套也恰恰说明, soul 将dubbo服务与http服务定义了同样的元数据, 设计很好的体现. 之后可以看看元数据这方面的设计.
其他信息就没什么有价值的了, 都是Dubbo包打出来的.
分析同步配置 - Dubbo服务调不成功?!
在调用网关转发 Dubbo 服务期间发生了意外, 没有成功调取, 于是在插件祖宗类 SoulPlugin 上断点, 看下都进了哪些插件. 发现除了 WebClientPlugin 和 WebClientResponsePlugin, 其他都走了一遍. Web的不走是正确的, 本身是Dubbo服务, 但是, 最关键的是没有看到 DubboPlugin .
于是继续追溯, 检查 SoulWebHandler 中获取到的 plugins 列表, 发现还是那9个, 并没有Dubbo插件, 继续探索!
发现 soul-bootstrap 在启动时的配置 SoulConfiguration , 有获取:
@Bean("webHandler")
public SoulWebHandler soulWebHandler(final ObjectProvider<List<SoulPlugin>> plugins) {
List<SoulPlugin> pluginList = plugins.getIfAvailable(Collections::emptyList);
final List<SoulPlugin> soulPlugins = pluginList.stream()
.sorted(Comparator.comparingInt(SoulPlugin::getOrder)).collect(Collectors.toList());
soulPlugins.forEach(soulPlugin -> log.info("loader plugin:[{}] [{}]", soulPlugin.named(), soulPlugin.getClass().getName()));
return new SoulWebHandler(soulPlugins);
}
尝试重启网关并断点, 仍然只有9个插件, 疑惑十足. 这时想起, 分析源码第0期, 有在 soul-bootstrap 启动日志中, 看到和 soul-admin 建立 WebSocket 的相关类 WebsocketSyncDataService, 当时还记了一笔日后要分析它的同步配置, 没想到来的这么快…
跟踪 WebsocketSyncDataService 的构造器, 找到监听类 SoulWebsocketClient :
@Override
public void onMessage(final String result) {
handleResult(result);
}
private void handleResult(final String result) {
WebsocketData websocketData = GsonUtils.getInstance().fromJson(result, WebsocketData.class);
ConfigGroupEnum groupEnum = ConfigGroupEnum.acquireByName(websocketData.getGroupType());
String eventType = websocketData.getEventType();
String json = GsonUtils.getInstance().toJson(websocketData.getData());
websocketDataHandler.executor(groupEnum, json, eventType);
}
这个 handleResult() 方法处断点, 并在 管理后台 手动点下同步配置, 这里看到传入更新插件的json:
{
"groupType": "PLUGIN",
"eventType": "REFRESH",
"data": [
{
"id": "1",
"name": "sign",
"role": 0,
"enabled": false
},
{
"id": "2",
"name": "waf",
"config": "{\"model\":\"black\"}",
"role": 0,
"enabled": false
},
{
"id": "3",
"name": "rewrite",
"role": 0,
"enabled": false
},
{
"id": "4",
"name": "rate_limiter",
"config": "{\"master\":\"mymaster\",\"mode\":\"Standalone\",\"url\":\"192.168.1.1:6379\",\"password\":\"abc\"}",
"role": 0,
"enabled": false
},
{
"id": "5",
"name": "divide",
"role": 0,
"enabled": true
},
{
"id": "6",
"name": "dubbo",
"config": "{\"register\":\"zookeeper://localhost:2181\"}",
"role": 0,
"enabled": true
},
{
"id": "7",
"name": "monitor",
"config": "{\"metricsName\":\"prometheus\",\"host\":\"localhost\",\"port\":\"9190\",\"async\":\"true\"}",
"role": 0,
"enabled": false
},
{
"id": "8",
"name": "springCloud",
"role": 0,
"enabled": false
},
{
"id": "9",
"name": "hystrix",
"role": 0,
"enabled": false
}
]
}
可以看到, soul-admin 传来的配置信息都是正确的, 继续追溯 handleResult , 找到 WebsocketDataHandler 的抽象类 AbstractDataHandler:
public void handle(final String json, final String eventType) {
List<T> dataList = convert(json);
if (CollectionUtils.isNotEmpty(dataList)) {
DataEventTypeEnum eventTypeEnum = DataEventTypeEnum.acquireByName(eventType);
switch (eventTypeEnum) {
case REFRESH:
case MYSELF:
doRefresh(dataList);
break;
case UPDATE:
case CREATE:
doUpdate(dataList);
break;
case DELETE:
doDelete(dataList);
break;
default:
break;
}
}
}
这里就是网关的同步刷新机制核心处了, 根据debug找到 doRefresh , 找到插件相关的更新类 PluginDataHandler :
protected void doRefresh(final List<PluginData> dataList) {
// 类似清理缓存, 先跳过不管, 关注更新方法
pluginDataSubscriber.refreshPluginDataSelf(dataList);
// 追溯这个方法
dataList.forEach(pluginDataSubscriber::onSubscribe);
}
追溯到 CommonPluginDataSubscriber 类:
public void onSubscribe(final PluginData pluginData) {
BaseDataCache.getInstance().cachePluginData(pluginData);
Optional.ofNullable(handlerMap.get(pluginData.getName())).ifPresent(handler -> handler.handlerPlugin(pluginData));
}
这里的第二句, 看的出从map匹配对应的handler实现, 不为空则执行. 查看 PluginDataHandler 的实现, 包含有 AlibabaDubboPluginDataHandler 这个看上去和 Dubbo相关的数据更新类, 但为什么插件没出来呢?
debug到 handlerMap 的数据后, 终于发现问题所在! 这里的内容, 仅包含之前见到的几个插件, 根本没有 Dubbo插件的名称, 看来问题就出在这里了.
追溯 handlerMap 的来源, 又回到一切配置的源头 SoulConfiguration 类, 这里的 pluginDataSubscriber 方法, 注入了 handlerMap 的所有信息:
@Bean
public PluginDataSubscriber pluginDataSubscriber(final ObjectProvider<List<PluginDataHandler>> pluginDataHandlerList) {
return new CommonPluginDataSubscriber(pluginDataHandlerList.getIfAvailable(Collections::emptyList));
}
这是spring bean , 自然是启动时加载的数据, 那么这些可读取的插件信息, 就肯定来自与配置文件.
又是漫长的时间过去, 最终检查到 soul-bootstrap 的 pom.xml 这里, 看到 alibaba-dubbo 这里的屏蔽状态, 我立刻相通了…
<dependency>
<groupId>org.dromara</groupId>
<artifactId>soul-spring-boot-starter-plugin-alibaba-dubbo</artifactId>
<version>${project.version}</version>
</dependency>
解开真相, 找到 soul-spring-boot-starter-plugin-alibaba-dubbo 项目的 AlibabaDubboPluginConfiguration 类, 这里就有我苦苦找寻的 Dubbo插件数据更新处理类:
@Bean
public PluginDataHandler alibabaDubboPluginDataHandler() {
return new AlibabaDubboPluginDataHandler();
}
将 soul-bootstrap 网关的pom中alibaba-dubbo启用并重启项目, 它在 CommonPluginDataSubscriber 里静静躺着:
尝试 http调用网关dubbo服务, 测试通过! 太辛苦了!
分析请求类型解析
尝试调用dubbo的时候又发生了个小插曲, 调用没有走通在 DividePlugin 这里被吃掉了, 没有走到 DubboPlugin 处. 折腾了一会后 (重启等) 再次调用又好了, 在这里分析下原因:
首先 DividePlugin 插件在 DubboPlugin 插件前, 如果走入 DividePlugin 且没匹配到规则, 会直接 return 掉, 在 AbstractSoulPlugin 的 execute() 这里:
public Mono<Void> execute(final ServerWebExchange exchange, final SoulPluginChain chain) {
String pluginName = named();
final PluginData pluginData = BaseDataCache.getInstance().obtainPluginData(pluginName);
if (pluginData != null && pluginData.getEnabled()) {
final Collection<SelectorData> selectors = BaseDataCache.getInstance().obtainSelectorData(pluginName);
if (CollectionUtils.isEmpty(selectors)) {
return CheckUtils.checkSelector(pluginName, exchange, chain);
}
final SelectorData selectorData = matchSelector(exchange, selectors);
// 规则未匹配到, 进入这里
if (Objects.isNull(selectorData)) {
if (PluginEnum.WAF.getName().equals(pluginName)) {
return doExecute(exchange, chain, null, null);
}
return CheckUtils.checkSelector(pluginName, exchange, chain);
}
...
}
return chain.execute(exchange);
}
CheckUtils 类这里, 会打印规则未匹配的日志, 并return:
public static Mono<Void> checkRule(final String pluginName, final ServerWebExchange exchange, final SoulPluginChain chain) {
if (PluginEnum.DIVIDE.getName().equals(pluginName)
|| PluginEnum.DUBBO.getName().equals(pluginName)
|| PluginEnum.SPRING_CLOUD.getName().equals(pluginName)) {
LOGGER.error("can not match rule data :{}", pluginName);
Object error = SoulResultWarp.error(SoulResultEnum.RULE_NOT_FIND.getCode(), SoulResultEnum.RULE_NOT_FIND.getMsg(), null);
return WebFluxResultUtils.result(exchange, error);
}
return chain.execute(exchange);
}
所以, 如果关于 Dubbo 服务的调用, 只要走入 DividePlugin 肯定就出不去了, 正常的情况是怎样呢? 会跳过 DividePlugin 直接下一个的, 具体看 SoulWebHandler 这:
public Mono<Void> execute(final ServerWebExchange exchange) {
return Mono.defer(() -> {
if (this.index < plugins.size()) {
SoulPlugin plugin = plugins.get(this.index++);
// 如果是dubbo调用, 轮到DividePlugin时会跳过的
Boolean skip = plugin.skip(exchange);
if (skip) {
return this.execute(exchange);
} else {
return plugin.execute(exchange, this);
}
} else {
return Mono.empty();
}
});
}
继续追踪 DividePlugin 的 skip() 方法:
public Boolean skip(final ServerWebExchange exchange) {
final SoulContext soulContext = exchange.getAttribute(Constants.CONTEXT);
// 检查调用类型是否是 http
return !Objects.equals(Objects.requireNonNull(soulContext).getRpcType(), RpcTypeEnum.HTTP.getName());
}
这里得到的 RPCType 正常是 dubbo , 说明刚刚的调用时返回的上下文中 soulContext 信息有误.
查看下 rpcType 属性被谁引用, 看到 DefaultSoulContextBuilder 类有 set() 过, debug追溯, 发现每次请求, 都会进入这里的 build() 去注入相关信息给上下文:
public SoulContext build(final ServerWebExchange exchange) {
final ServerHttpRequest request = exchange.getRequest();
String path = request.getURI().getPath();
// 这里是关键, 通过链接解析元数据, 得到rpcType类型
MetaData metaData = MetaDataCache.getInstance().obtain(path);
if (Objects.nonNull(metaData) && metaData.getEnabled()) {
exchange.getAttributes().put(Constants.META_DATA, metaData);
}
return transform(request, metaData);
}
private SoulContext transform(final ServerHttpRequest request, final MetaData metaData) {
final String appKey = request.getHeaders().getFirst(Constants.APP_KEY);
final String sign = request.getHeaders().getFirst(Constants.SIGN);
final String timestamp = request.getHeaders().getFirst(Constants.TIMESTAMP);
SoulContext soulContext = new SoulContext();
String path = request.getURI().getPath();
soulContext.setPath(path);
if (Objects.nonNull(metaData) && metaData.getEnabled()) {
if (RpcTypeEnum.SPRING_CLOUD.getName().equals(metaData.getRpcType())) {
setSoulContextByHttp(soulContext, path);
// 这里将元数据的rpctype注入到上下文中
soulContext.setRpcType(metaData.getRpcType());
} else {
setSoulContextByDubbo(soulContext, metaData);
}
} else {
setSoulContextByHttp(soulContext, path);
soulContext.setRpcType(RpcTypeEnum.HTTP.getName());
}
soulContext.setAppKey(appKey);
soulContext.setSign(sign);
soulContext.setTimestamp(timestamp);
soulContext.setStartDateTime(LocalDateTime.now());
Optional.ofNullable(request.getMethod()).ifPresent(httpMethod -> soulContext.setHttpMethod(httpMethod.name()));
return soulContext;
}
继续追踪解析类 MetaDataCache:
public MetaData obtain(final String path) {
MetaData metaData = META_DATA_MAP.get(path);
if (Objects.isNull(metaData)) {
String key = META_DATA_MAP.keySet().stream().filter(k -> PathMatchUtils.match(k, path)).findFirst().orElse("");
return META_DATA_MAP.get(key);
}
return metaData;
}
其中的 PathMatchUtils 会去匹配并输出类型, 不继续跟踪了, 明日尝试下看还能否复现问题…
扫一扫
865
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
