【Soul源码阅读】20.插件灵魂之选择器和规则

目录

1.灵魂

2.数据结构

3.选择器

4.规则

---

1.灵魂

这几天一直在看插件相关的功能，一直把核心概念忽略了，那就是所有的插件都有的：selector 和 rule。

在看看官网文档 https://dromara.org/zh/projects/soul/selector-and-rule/，里面第一句就是：

选择器和规则是 soul 网关中最灵魂的东西。掌握好它，你可以对任何流量进行管理。

都这么多天过去了，眼睛里净盯着具体对接的协议和同步功能，还有插件的具体使用，就没有关心过插件到底是怎么实现的，真是惭愧。况且官网都说了，这是灵魂！（好好反思吧 :( ）

今天就先从这对核心概念谈起。

官网是这么介绍的：

一个插件有多个选择器，一个选择器对应多种规则。选择器相当于是对流量的一级筛选，规则就是最终的筛选。

作为网关，需要代理的服务可能成百上千，如果直接管理，数量大了务必会带来一定的困扰：比如，如果用户想对这些服务按照功能做分类，或者按照服务节点信息做分类，这时就没有办法分类了。为此有了选择器和规则。（这个纯个人主观猜测，如果还有其他原因，希望小伙伴积极反馈指导啊）

这样，就可以把选择器和规则分别看做一级分类和二级分类，只有流量满足一级二级分类条件后才去执行我们预设的逻辑。

 

2.数据结构

官网文档 https://dromara.org/zh/projects/soul/database-design/

好像前面文章就提过，说是要梳理下数据库表结构，好吧，今天终于兑现了，那就先来看下这几张表数据结构吧。

• 1个插件，可以包含多个选择器
• 1个选择器，可以包含多个规则
• 1个选择器，可以包含多个匹配条件
• 1个规则，可以包含多个匹配条件
• 1个规则，在对应的插件下，不同体现在 handle 字段。handle 字段是一个 JSON 字符串。

下来我们一个一个来看。

3.选择器

• 名称
  • 这个名称需要唯一，否则报错
• 类型
  • custom 是自定义流量。
  • full 是全流量。
  • 自定义流量就是请求会走下面的匹配方式与条件。
  • 全流量则不走，并且页面也不会显示。
• 匹配方式
  • and 或者 or
  • 指下面多个条件是按照 and 还是 or 的方式来组合。
• 条件
  • 条件1 - 匹配方式
    • uri：是指你根据uri的方式来筛选流量，match的方式支持模糊匹配（/**）
    • header：是指根据请求头里面的字段来筛选流量。
    • query：是指根据uri的查询条件来进行筛选流量。
    • ip：是指根据你请求的真实ip，来筛选流量。
    • host：是指根据你请求的真实host，来筛选流量。
    • post：建议不要使用。
    • req_method：有待进一步确认 //TODO
  • 条件2 - 条件匹配
    • match：模糊匹配，建议和uri条件搭配，支持 restful风格的匹配。（/test/**）
    • =：前后值相等，才能匹配。
    • regEx：正则匹配，表示前面一个值去匹配后面的正则表达式。
    • like：字符串模糊匹配。
  • 条件3 - 具体条件
    • 用户输入具体条件
• 继续后续选择器
  • 从名字上来看，后续还有选择器，是否继续执行，这个需要配合源码来分析。
• 打印日志
  • 打开的时候，当匹配上的时候，会打印匹配日志。
• 是否开启
  • 打开才会生效
• 配置
  • 具体的服务节点信息
• 执行顺序
  • 当多个选择器的时候，执行顺序小的优先执行。

官网选择器建议：可以uri 条件， match 前缀 （/contextPath），进行第一道流量筛选。

4.规则

当流量经过选择器匹配成功之后，会进入规则来进行最终的流量匹配。

• 名称
  • 方便分辨，并且保证唯一。
• 匹配方式
  • and 或者 or
  • 下面多个条件是按照 and 还是 or 的方式来组合。
• 条件
  • 条件1 - 类型
    • uri：是指你根据uri的方式来筛选流量，match的方式支持模糊匹配（/**）
    • header：是指根据请求头里面的字段来筛选流量。
    • query：是指根据uri的查询条件来进行筛选流量。
    • ip：是指根据你请求的真实ip，来筛选流量。
    • host：是指根据你请求的真实host，来筛选流量。
    • post：建议不要使用。
    • req_method：有待进一步确认 //TODO
  • 条件2 - 条件匹配
    • match : 模糊匹配，建议和uri条件搭配，支持 restful风格的匹配。（/test/**）
    • = : 前后值相等，才能匹配。
    • regEx : 正则匹配，表示前面一个值去匹配后面的正则表达式。
    • like ：字符串模糊匹配。
  • 条件3 - 具体条件
    • 用户输入具体条件
• 负载
  • 负载策略
    • hash
    • random
    • roundrobin
  • 重试次数
• 打印日志
  • 打开的时候，当匹配上的时候，会打印匹配日志。
• 是否开启
  • 打开才会生效。
• 执行顺序
  • 当多个规则的时候，执行顺序小的优先执行。

官网规则建议：可以uri 条件， match 最真实的uri路径，进行流量的最终筛选 。

 

今天先把灵魂搞清楚，明天继续从源码的角度分析为啥他俩就是灵魂，敬请期待。