使用 Ocelot 匹配路由的方法匹配路由
使用 ocelot 匹配路由的方法匹配路由
intro
之前我们在 ocelot 网关的基础上自定义了一个认证授权的 ocelot 中间件，根据请求的路径和 method 进行匹配，找到对应的权限配置，并判断是否可以拥有访问资源的角色，如果没有则返回 401/403，如果有权限则转发到下游服务。
原来的匹配方式是首先根据请求路径和方法完全匹配，如果匹配不到则尝试使用正则匹配。
我们这次要做的就是将原来的正则匹配替换成 ocelot 內部的路由匹配方式，这样我们在配置的时候就不再需要配置两套了，一边写 ocelot 路由的配置，一边写权限的配置，这样能减少不少工作量
深入 ocelot 路由匹配
我们想使用 ocelot 的路由匹配，首先应该了解 ocelot 的执行过程，然后找到对应的路由匹配的地方，看路由匹配使用到了哪一个服务，用这个服务在我们自己的业务逻辑里匹配即可。
先来看一下 ocelot 的服务注册，ocelot 的服务注册
可以看到主要的服务注册代码应该在 ocelotbuilder 中，查看 ocelotbuilder https://github.com/threemammals/ocelot/blob/13.5.2/src/ocelot/dependencyinjection/ocelotbuilder.cs
可以看到，ocelot 的服务注册都在这里， ocelot 内部好多都是基于接口的，所以需要找对应的实现的话可以看它的服务注册是注册的哪一个服务即可。
简单分析一下，ocelot 的路由匹配过程一定在寻找下游地址的时候，根据上游的请求信息（直接请求网关的请求）匹配，所以我们首先找到 downstreamroutefindermiddleware https://github.com/threemammals/ocelot/blob/13.5.2/src/ocelot/downstreamroutefinder/middleware/downstreamroutefindermiddleware.cs
由上面的代码，我们可以看到，下游路由地址是通过 idownstreamroutefinder 来找下游路由的，转到对应的实现代码： https://github.com/threemammals/ocelot/blob/13.5.2/src/ocelot/downstreamroutefinder/finder/downstreamroutefinder.cs
这里我们可以看到是通过 iurlpathtourltemplatematcher 来进行路由匹配的，所以我们需要用到这个服务，然后看这个 match 方法的参数，前两个参数比较明确，第一个参数是上游请求的地址，第二个参数是请求的 querystring，第三个参数则是 ocelot 内部构建出来的路由模板信息 upstreampathtemplate，然后我们就需要知道怎么构建一个 upstreampathtemplate 对象，继续探索
直接看 upstreampathtemplate，表示一脸懵逼，不知道怎么构建， 全局搜素了一下，发现有一个 iupstreamtemplatepatterncreator 里面定义了一个 create 的方法
这个方法看上去简单了好多，查看 ireroute 的定义 https://github.com/threemammals/ocelot/blob/13.5.2/src/ocelot/configuration/file/ireroute.cs
我们只需要根据路径模板构建一个 ireroute 对象即可，ocelot 中有一个实现了 ireroute 的类 filereroute，但是感觉有些复杂，就没有用，自定义了一个类型实现了 ireroute
自此，我们就已经找到了要使用 ocelot 路由匹配所需要的服务了：
iurlpathtourltemplatematcheriupstreamtemplatepatterncreator
使用 ocelot 路由匹配
上面提到了我们没有使用 filereroute 对象，所以我们就需要自定义一个 ireroute 对象：
private class fakereroute : ireroute
{
public string upstreampathtemplate { get; set; }
public bool rerouteiscasesensitive { get; set; }
public int priority { get; set; }
}
使用 ocelot 路由匹配示例：
public class urlbasedauthenticationmiddleware : ocelot.middleware.ocelotmiddleware
{
private readonly gatewayoptions _gatewayoptions;
private readonly imemorycache _memorycache;
private readonly ocelotrequestdelegate _next;
private readonly iurlpathtourltemplatematcher _urltemplatematcher;
private readonly iupstreamtemplatepatterncreator _templatepatterncreator;
public urlbasedauthenticationmiddleware(ocelotrequestdelegate next, ioptions<gatewayoptions> options, imemorycache memorycache, iocelotloggerfactory loggerfactory,
iurlpathtourltemplatematcher urltemplatematcher,
iupstreamtemplatepatterncreator templatepatterncreator)
: base(loggerfactory.createlogger<urlbasedauthenticationmiddleware>())
{
_next = next;
_gatewayoptions = options.value;
_memorycache = memorycache;
_urltemplatematcher = urltemplatematcher;
_templatepatterncreator = templatepatterncreator;
}
public async task invoke(downstreamcontext context)
{
var permissions = await _memorycache.getorcreateasync(_gatewayoptions.apipermissionscachekey, async entry =>
{
using (var conn = new sqlconnection(_gatewayoptions.permissionsconnectionstring))
{
entry.absoluteexpirationrelativetonow = timespan.fromhours(1);
return (await conn.queryasync<apipermission>(@"")).select(_ => _.getviewmodel()).toarray();
}
});
var request = context.httpcontext.request;
var permission = permissions.firstordefault(p =>
request.path.value.equals(p.pathpattern, stringcomparison.ordinalignorecase) &&
p.method == request.method.toupper());
if (null == permission)
{
permission = permissions.firstordefault(p =>
p.method == request.method.toupper() &&
_urltemplatematcher.match(request.path.value, request.querystring.value,
_templatepatterncreator.create(new fakereroute()
{
upstreampathtemplate = p.pathpattern
})).data.match
);
}
// ...
await _next.invoke(context);
}
private class fakereroute : ireroute
{
public string upstreampathtemplate { get; set; }
public bool rerouteiscasesensitive { get; set; }
public int priority { get; set; }
}
}
more
这样，apipermission 的 path 配置基本可以使用和 ocelot 配置一样的路由，可以更方便的配置，避免 996 咯