前言

shenyu以前叫soul网关，我比较早关注它的，直到前不久看到它们创始人发的朋友圈，才知道现在已经是apache顶级项目了，666

今天我点了下shenyu issue里头逛逛，发现了一个老哥说能否做到对签名插件的扩展，然后我就去看了shenyu里头怎么实现验签的

加了他们创始人微信挺久了，也关注shenyu网关一段时间，因为本身在架构组也会接触网关内容

shenyu网关

shenyu跟其他网关一样，都是通过责任链的方式，这样可以灵活进行扩展，也能做到每个处理类都难处理到。

我目前项目也有鉴权功能，也看看别人是怎么实现的

首先肯定是找到对应的模块，shenyu-plugin-sign,SignPlugin 就是网关处理链条中的一环。

@Bean
public ShenyuPlugin signPlugin(final SignService signService) {
    return new SignPlugin(signService);
}
复制代码

就是你在项目里头注入哪个SignService实现类，它会塞到这插件里头来。

它会去判断规则是否存在，什么规则？就是验证签名的时候那些配置，比如说多久超时，哪些url要通过sign验签。

但是这里也暴露了一个问题，过度依赖配置，如果做到高可用，可以做一层backup备份，如果没有配置，或者配置读不到的情况下，读取上次配置的内容。

DefaultSignService

这里有个比较好的东西，就是会将一些内容封装到上下文里头，比如说a节点，处理了一个东西，还要set一个特殊的key到header里面，然后让后面的去拿，这就很不方便了，如果是放在上下文的话，这就统一处理。

验签逻辑开始，首先是对时间做验证，然后再是算法验。

这里我要直呼一声好家伙，exchange.getRequest().getQueryParams()直接拿到请求的参数，如果你在服务里面实现那得累死你，区分post、get请求，需要特殊处理。

buildParamsMap(shenyuContext, requestBody)
复制代码

这个map里头有啥？加了时间戳、url、版本号，请求参数（去除sign）

DigestUtils.md5DigestAsHex(sign.getBytes()).toUpperCase()
复制代码

这里是sign签名算法

到这里，shenyu的sign插件逻辑就差不多了，直呼好家伙，跟我现在项目里头验签逻辑一毛一样，只是签名算法有所不同。但是这里面还是有些能优化的点，比如说过度依赖shenyu现有的配置内容，需要做到网关点高可用～

shenyu这里跟其他配置中心也有所不一样，采用map来接收配置内容，我们看nacos、apolla这些框架是刷新到eventment环境变量里头去。