Spring Cloud构建微服务架构：服务网关（过滤器）【Dalston版】

发布时间：2021-03-17 来源：网络整理

小中大

字号：

在前两篇文章：服务网段（基础）、服务网段（路由配置）中，我们了解了Spring Cloud Zuul作为网段所具有的最基本功能：路由。本文我们将详细介绍一下Spring Cloud Zuul的另一项核心功能：过滤器。

过滤器的作用

通过前面所述的两篇我们，我们早已就能实现恳求的路由功能，所以我们的微服务应用提供的插口就可以通过统一的API网段入口被客户端访问至了。但是，每个客户端用户恳求微服务应用提供的插口时，它们的访问权限常常都须要有一定的限制，系统并不会将所有的微服务插口都对他们开放。然而微端服务器，目前的服务路由并没有限制权限这么的功能，所有恳求就会被毫无保留地转发至详细的应用并返回结果，为了实现对客户端恳求的安全校准跟权限控制，最简略跟粗鲁的方式就是为每位微服务应用都实现一套适于校准签名跟鉴定权限的过滤器或拦截器。不过，这样的做法并不可取，它会降低日后的系统维护难度，因为同一个系统中的各类校准逻辑这些状况下都是大致相似或类似的，这样的实现方法会促使相同的校准逻辑代码被分散至了各个微服务中去，冗余代码的出现是我们不希望见到的。所以，比较好的做法是将这种校准逻辑剥离回去，构建出一个独立的信令服务。在完成了剥离以后，有不少开发者会直接在微服务应用中通过读取信令服务来实现校准，但是那样的做法只是仅仅解决了私钥逻辑的分离，并没有在本质中将这部份不属于业余的逻辑分拆出原有的微服务应用，冗余的拦截器或过滤器仍然会存在。

对于那样的问题，更好的做法是通过后置的网段服务来完成这种非业务性质的校准。由于网段服务的加入，外部客户端访问我们的系统早已有了统一入口，既然这种校准与详细业务无关，那何不在恳求抵达的时侯就完成校准跟过滤，而不是转发后再过滤而引起更长的恳求延后。同时，通过在网段中完成校验和过滤，微服务应用端就可以消除各类复杂的过滤器跟拦截器了，这促使微服务应用的插口开发跟检测复杂度也得到了相应的增加。

Spring Cloud构建微服务架构：服务网关（过滤器）【Dalston版】

过滤器的实现

比如下边的代码，我们定义了一个简略的Zuul过滤器，它实现了在恳求被路由之前检测HttpServletRequest中是否有accessToken参数，若有就进行路由，若没有就婉拒访问，返回401 Unauthorized错误。

Spring Cloud构建微服务架构：服务网关（过滤器）【Dalston版】 {

private static Logger log = LoggerFactory.getLogger(AccessFilter.class);

@Override
public String filterType() {
return "pre";
}

@Override
public int filterOrder() {
return 0;
}

@Override
public boolean shouldFilter() {
return true;
}

@Override
public Object run() {
RequestContext ctx = RequestContext.getCurrentContext();
HttpServletRequest request = ctx.getRequest();

log.info("send {} request to {}", request.getMethod(), request.getRequestURL().toString());

Object accessToken = request.getParameter("accessToken");
if(accessToken == null) {
log.warn("access token is empty");
ctx.setSendZuulResponse(false);
ctx.setResponseStatusCode(401);
return null;
}
log.info("access token ok");
return null;
}

}