实际上Spring Cloud已经废弃zuul了,改用gateway,但是webflux的技术并没在实际项目大规模普及,还有很多servlet NIO的应用,所以zuul还是很有必要改造的,实测zuul调优(调节转发的连接池)跟gateway性能上差不多,所以研究了下zuul,发现设计理念很不错。
zuul的原理,笔者的上一章已经大致说过,参考Spring Cloud zuul与CloseableHttpClient连接池,TLS证书认证_fenglllle的博客-CSDN博客
说了连接池部分,包括是怎么关闭的,但是zuul的数据怎么传递的呢
zuul的核心理念实际上是线程变量的传递,threadlocal,所以如果需要子线程或者其他线程池,那么需要对传递的变量进行改造,使用
InheritableThreadLocal
简单翻译
请求上下文保存请求、响应、状态信息和数据,供ZuulFilters访问和共享。RequestContext在请求的持续时间内存在,并且是ThreadLocal。
可以通过设置contextClass来替换RequestContext的扩展。这里大多数方法都是方便扩展的方法; RequestContext是ConcurrentHashMap的扩展(继承)
如果自定义线程池,那么需要InheritableThreadLocal,实际上Spring和日志框架都是定制的,threadlocal需要注意自己管理生命周期,线程结束必须clear,否则会造成内存泄漏,有点C++编程的思维。
zuul提供全局配置和每个route的配置,全局配置根据自己需要定制,但是全局生效,适合明确的需求,相对而言扩展自定义route更加灵活,自定义route的解析
org.springframework.cloud.netflix.zuul.filters.pre.PreDecorationFilter
在pre的filter中解析,SpringCloud的zuul starter自带
只需要对org.springframework.cloud.netflix.zuul.filters.Route和org.springframework.cloud.netflix.zuul.filters.ZuulProperties.ZuulRoute加入自定义的属性即可,Spring cloud会自定载入属性
这种实现思路来源于8. Router and Filter: Zuul
Spring cloud官方文档,Spring cloud对于Cookies and Sensitive Headers 的设计
zuul:
routes:
users:
path: /myusers/**
sensitiveHeaders: Cookie,Set-Cookie,Authorization
url: https://downstream
扩展filter,实际上非常简单,继承zuulfilter即可,但是建议所有的filter放在PreDecorationFilter之后,PreDecorationFilter的order为5,order越小优先级越高
因为PreDecorationFilter有很多前置的条件判断,不过使用if else判断的,而且route的解析也在这里
public Object run() {
//上下文设计,threadlocal,后面的结果设计就是这个传递的数据回写的
RequestContext ctx = RequestContext.getCurrentContext();
final String requestURI = this.urlPathHelper
.getPathWithinApplication(ctx.getRequest());
if (insecurePath(requestURI)) {
throw new InsecureRequestPathException(requestURI);
}
//解析route,刚刚写的自定义属性可以在这里使用,同时SpringCloud的敏感header也是这里配置的
Route route = this.routeLocator.getMatchingRoute(requestURI);
if (route != null) {
String location = route.getLocation(); //目标地址
//这里的设计理念,根据关键字匹配,类似重定向 转发等等
if (location != null) {
ctx.put(REQUEST_URI_KEY, route.getPath());
ctx.put(PROXY_KEY, route.getId());
if (!route.isCustomSensitiveHeaders()) {
this.proxyRequestHelper.addIgnoredHeaders(
this.properties.getSensitiveHeaders().toArray(new String[0]));
}
else {
this.proxyRequestHelper.addIgnoredHeaders(
route.getSensitiveHeaders().toArray(new String[0]));
}
if (route.getRetryable() != null) {
ctx.put(RETRYABLE_KEY, route.getRetryable());
}
//HTTP转发,HTTPS同理
if (location.startsWith(HTTP_SCHEME + ":")
|| location.startsWith(HTTPS_SCHEME + ":")) {
ctx.setRouteHost(getUrl(location));
ctx.addOriginResponseHeader(SERVICE_HEADER, location);
}//forward转发,可以根据这个设计,设计mock能力
else if (location.startsWith(FORWARD_LOCATION_PREFIX)) {
ctx.set(FORWARD_TO_KEY,
StringUtils.cleanPath(
location.substring(FORWARD_LOCATION_PREFIX.length())
+ route.getPath()));
ctx.setRouteHost(null);
return null;
}
else {
// set serviceId for use in filters.route.RibbonRequest
ctx.set(SERVICE_ID_KEY, location);
ctx.setRouteHost(null);
ctx.addOriginResponseHeader(SERVICE_ID_HEADER, location);
}
if (this.properties.isAddProxyHeaders()) {
addProxyHeaders(ctx, route);
String xforwardedfor = ctx.getRequest()
.getHeader(X_FORWARDED_FOR_HEADER);
String remoteAddr = ctx.getRequest().getRemoteAddr();
if (xforwardedfor == null) {
xforwardedfor = remoteAddr;
}
else if (!xforwardedfor.contains(remoteAddr)) { // Prevent duplicates
xforwardedfor += ", " + remoteAddr;
}
ctx.addZuulRequestHeader(X_FORWARDED_FOR_HEADER, xforwardedfor);
}
if (this.properties.isAddHostHeader()) {
ctx.addZuulRequestHeader(HttpHeaders.HOST,
toHostHeader(ctx.getRequest()));
}
}
}
else {
log.warn("No route found for uri: " + requestURI);
String forwardURI = getForwardUri(requestURI);
ctx.set(FORWARD_TO_KEY, forwardURI);
}
return null;
}
比如可以根据forward转发的设计,设计mock能力,可以在数据库、配置中心等配置返回结果,也可以通过流量的录制,录制返回结果 ,比如bpf录制。
那么设计一个初步的mock response能力
修改PreDecorationFilter,要是PreDecorationFilter提供扩展能力就好了,直接扩展,但是PreDecorationFilter写的if else,可以重构代码,把if else变成SPI,实现自定义扩展。
简单写了,其中
ctx.setRouteHost(null);
极为关键,比如HTTP(S)转发的filter,就是根据Host判断的,但是Host就是一个信号量,如果明确信号量的概念,并且抽象,那么代码就更明晰了。
设计mock,需要根据现有的返回数据逻辑,可以看到post filter根据servlet response回写的方式
那么这个response哪里初始化的呢,zuulrunner里面,通过包装类实现的
手写route filter实现mock
package org.springframework.cloud.netflix.zuul.filters.route;
import com.netflix.zuul.ZuulFilter;
import com.netflix.zuul.context.RequestContext;
import com.netflix.zuul.exception.ZuulException;
import org.springframework.cloud.netflix.zuul.filters.ProxyRequestHelper;
import static org.springframework.cloud.netflix.zuul.filters.support.FilterConstants.ROUTE_TYPE;
public class MockHostRoutingFilter extends ZuulFilter {
private ProxyRequestHelper helper;
public MockHostRoutingFilter(ProxyRequestHelper helper) {
this.helper = helper;
}
@Override
public String filterType() {
return ROUTE_TYPE;
}
@Override
public int filterOrder() {
return 0;//自定义
}
@Override
public boolean shouldFilter() {
//可以在PreDecorationFilter埋点设计
//同时在@Bean,可以通过conditional on properties开启mock的bean
return RequestContext.getCurrentContext().get("mock.path") != null;
}
@Override
public Object run() throws ZuulException {
String fullPath = RequestContext.getCurrentContext().get("mock.path") != null;
// 自定义实现,取http code;body;headers
return this.helper.setResponse(statusCode(),
responseBody(),
headers());
}
}
SpringCloud实际上是链式设计,通过threadlocal连接数据,基于servlet逻辑,那么整个链路就可以自定义,实际上应该设计比较完善的filter,通过filter的基础上扩展,比如SPI的方式,可以提供各种能力比较方便,不过Spring Cloud zuul通过filter扩展也不错,但是需要threadlocal设置各种数据,尤其是标签数据,在
PreDecorationFilter
中,这个filter尤其重要,如果做成SPI模式就更好了。zuul相对简单,而且贴合servlet,如果使用gateway,那么需要使用webflux技术(netty异步能力),通信原理就是NIO和AIO的区别,数据传递就复杂很多,线程之间传递数据,使用
InheritableThreadLocal
不过,不需要太多的调优,使用角度会简单一些,但是定制化过程难度会增加,取舍而已,如果不定制,那么gateway是比较优的选择,如果追求极致性能,那么这2者都不建议,建议使用nginx+lua的方案,性能会强很多,而且可定制。