shenyu数据结构设计

数据分成如下几个部分
## 1.字典数据
设计思想是管理和维护字典数据。
包含数据库表：字典表(shenyu_dict)。
E-R图如下
![](/media/202209/2022-09-22_093659_895787.png)
对应管理端图如下
![](/media/202209/2022-09-22_093840_273388.png)
由表设计可知，字典数据是分类了，查询表数据可知，一共分成如下类
![](/media/202209/2022-09-22_094105_802908.png)
如下对字典的分类整理下
algorithmName：限流算法，用于FaultTolerance中的RateLimiter插件，该插件预设Concurrent、LeakyBucket、SlidingWindow、TokenBucket这4种限流算法，扩展接口是RateLimiterAlgorithm。如果用户需要自定义限流算法，实现该接口即可。
automaticTransitionFromOpenToHalfOpenEnabled:
cacheType：缓存类型，目前支持memory(本地内存)与redis两种缓存模式，默认使用memory模式，如果网关是采用集群方式部署，则需要采用redis缓存模式。缓存数据通过websocket从admin工程同步过来。
compressAlg：压缩方式，LZ4压缩算法
degradeRuleGrade：降级规则，用于熔断限流类型中的插件，如Sentinel等，包含exception number strategy、exception ratio、slow call ratio等。
flowRuleControlBehavior：流量控制规则，即超负荷的流程处理规则，包括:CONTROL_BEHAVIOR_DEFAULT(直接拒绝)、constant speed queuing(插入队列尾部)、warm up、preheating uniformly queued(插入队列头部)。
flowRuleGrade：流量规则等级，包含QPS与number of concurrent threads(并发线程数)
gray:灰度环境，存在open于close状态
keyResolverName:
loadBalance：负载均衡方式，用于HttpProcess中的Redirect中，包含hash、random与roundRobin。
matchMode：匹配模式，包含and与or，用于selector与rule中的MatchType。
mode：集群模式，包含cluster、sentinel与standalone。
multiRuleHandle：多规则处理，用于rule的Handler，包含multiple rule与single rule。
multiSelectorHandle：多规则处理，用于selector，的Handler，包含multiple handle与single handle。
operator：操作，用于selector与rule中的Conditions中条件比对，包含=、match等
paramType：流量控制key，用于selector与rule中的Conditions中条件key，包含header、uri等
permission：权限开关，包含allow与reject两种
retryStrategy：重试策略，包含current(当前重试)、failover(故障转移)
saslMechanism：安全规则
securityProtocol：安全协议
signRequestBody：
status：状态，包含open与close
strategyName：策略
table：
threadpool：线程池
way：编解码方式，包含encrypt与decrypt。
## 2.元数据
设计思想是用于网关的泛化调用，即每个项目对应一条元数据，对外控制可以访问的资源路径(宏观路径，一般设置成工程名称路径)
包括数据库表meta_data
E-R图如下
![](/media/202209/2022-09-22_112128_815543.png)
对应管理端图如下
![](/media/202209/2022-09-22_112406_646081.png)
总结：每个工程都会有个名称(AppName)，每个工程都有接口总入口(Path，可能存在多个，目前shenyu只能设置一个)，每个工程都会有rpc方式(如http、springcloud、dubbo等)。
此处结合Authentication使用，具体参考Authentication处介绍。
## 3.认证处理
设计思想是网关统一对外服务，因此需要对请求进行签名认证，Security的插件有很多，我司采用的Sign插件，如下以Sign插件作为样例讲解。对应官方文档路径：https://shenyu.apache.org/zh/docs/plugin-center/security/sign-plugin
包含数据库表：认证表(app_auth)、
E-R图如下
![](/media/202209/2022-09-22_204709_655489.png)
添加认证页面如下
![](/media/202209/2022-09-22_210640_894326.png)
AppName：应用名称，即生成的ak与sk给这个应用使用
TelPhone：手机号，无实际作用
AppParams：应用参数
UserId：用户id，无实际作用
ExpandInfo：扩展信息，无实际意义
PathAuth：路径认证，开启后该账号只允许访问以下配置的资源路径
ResourcePath：资源路径，如/api/星星
点击确认按钮后，会生成一条认证信息，包含ak与sk，存放于app_auth表中；同时appName与AppParams存放于auth_param表中；同时ResourcePath存放于auth_path表中。
总结：一套ak与sk可以访问多个path。
具体的认证流程可以查看网关介绍。这里列举一个自己使用的场景
![](/media/202209/2022-09-22_221949_857181.png)
![](/media/202209/2022-09-22_222040_977638.png)

| 外部系统 | ak | 可访问资源 |
| --- | --- | --- |
| test1 | BD975DC728E34C9CA5C4BB29BD2BAC47 |/program1/星星,/program2/星星,/program3/星星  |
| test2 | FC5BC6E1617C484B9EAA625D9D7CDE93 |/program3/星星,/program4/星星  |

注意：test1与test2都可访问 /program3/星星 下的资源。
sign插件的selector配置如下：
![](/media/202209/2022-09-22_223225_338898.png)
此处仅仅描述了访问系统与被访问系统的标识关系，并没有涉及到访问资源路径，在rule中设置访问路径
![](/media/202209/2022-09-22_224208_950856.png)
![](/media/202209/2022-09-22_224558_738344.png)
现在外部系统1可访问的资源是

| 访问系统 | 被访问系统 | 资源路径 |
| --- | --- | --- |
| externalSystem1 | Internal_system1 | /program1/insert/user  |
| externalSystem1 | Internal_system2 | /program2/insert/user |
| externalSystem1 | Internal_system3 | /program3/insert/user |

此处Internal_system3就不截图了，跟Internal_system2一样。
同时建立外部系统2可访问的资源是

| 访问系统 | 被访问系统 | 资源路径 |
| --- | --- | --- |
| externalSystem2 | Internal_system3 | /program3/insert/user |
| externalSystem2 | Internal_system4 | /program4/insert/user |

由此处可知，DSystem=Internal_system3，两个ak与sk都可以通过签名验证。
后续的选择器，访问系统命名也与sign中一样，也是通过DSystem=Internal_system进行过滤，然后处理不同的业务。
**认证场景总结**

| 系统 | 访问方式 | 是否需要验证 | 是否走网关 | 选择器配置 | 规则配置 |
| --- | --- | --- | --- | --- | --- |
| 自研产品 | 外部访问 | 是 | 是 | /message/facade/星星| |
| 自研产品 | 内部访问 | 否 | 否 | 内部注册方式，不走网关| |
| 非自研产品 | 外部访问 | 是 | 是 | DSystem | |
## 3.访问流量控制
设计思想是插件控制流量，插件类型包括权限认证、缓存、容灾、http请求转发、RPC代理、日志等。
选择器：每个插件对应多个选择器，对流量进行初筛
规则：每个选择器对应多个规则，对流量进行再次筛
说明：一次请求可能会由多个插件联合完成。
包含数据库表：插件表(plugin)、插件资源表(plugin_handle)、选择器(selector)、选择器资源表(selector_condition)、规则表(rule)、规则资源表(rule_condition)。
E-R图如下
![](/media/202209/2022-09-23_094046_089203.png)
对应的plugin管理端图如下
![](/media/202209/2022-09-23_094244_776489.png)
对plugin表理解如下
name：插件名称
config：插件的补充信息，如下列举两件插件作为样例讲解
role：插件的分类大类，例如：sign插件属于Authentication这个大类
这里列举sign插件与divide插件的config字段理解
![](/media/202209/2022-09-23_103540_631650.png)
![](/media/202209/2022-09-23_103719_349890.png)
![](/media/202209/2022-09-23_103950_472870.png)
![](/media/202209/2022-09-23_104214_559359.png)
![](/media/202209/2022-09-23_104321_675424.png)
由上图可知，sign插件没有配置项，所有sign插件下的selector与rule没有任何额外的配置。
divide插件有handler配置项，且selector的值为1表示支持多个handler，rule的值为0表示只支持一个。
说明：插件有很多，列举不完，config的配置也有很多种类。config决定插件是否有handle。
对plugin_handle表理解如下
plugin_id：插件id
field：handle中的字段名称
lable: field字段显示在界面上的名称
data_type： field字段的数据类型，1:number,2：String
type：这条记录的类型，1:selector,2:rule,3:plugin
ext_obj：额外的配置信息，json格式
这里列举sign插件与divide插件的理解
![](/media/202209/2022-09-23_105724_921642.png)
![](/media/202209/2022-09-23_105800_807228.png)
![](/media/202209/2022-09-23_105905_812641.png)
![](/media/202209/2022-09-23_105947_369233.png)
由上图可知，sign插件只有rule中存在handle。divide插件中selector与rule中都存在handle。
selector_condition与rule_condition就是存储每个插件中用户设置的具体的handle值。
## 4.用户资源权限
设计思想是用户、角色、资源之间的关系。
包含数据库表：用户表(dashboard_user)、角色表(role)、用户角色关联表(user_role)、resource(资源表，包括菜单与按钮)、permission(权限表，包括用户权限与角色权限)。
E-R图如下
![](/media/202209/2022-09-21_232547_636224.png)
对应管理端图如下
![](/media/202209/2022-09-21_232656_646058.png)
设计原则：一个用户拥有多个角色，一个角色拥有多种资源权限，同时一个用户也拥有多种资源权限。
## 5.用户数据权限
上述的资源权限指的是用户可以查看哪些资源(菜单与按钮)，数据权限指的是用户可以查看到资源的情况下，具备这些资源下数据的访问情况。举例：用户可以查看到所有的插件下的选择器与规则，但是只能操作部分选择器与规则。
设计思想是用户与选择器、规则之间的权限关系。
包含数据库表：用户表(dashboard_user)、数据权限(data_permission)、选择器表、规则表
E-R图如下
![](/media/202209/2022-09-23_112256_336258.png)
设计原则：用户与选择器绑定、用户与规则绑定。