解决SpringCloud(Gateway配置自定义路由404的坑)

解决SpringCloud,Gateway配置自定义路由404的坑，久久派带你了解更多相关信息。

目录

• 问题背景
• 问题现象
• 解决过程
• 1 检查网关配置
• 2 跟源码，查找可能的原因
• 3 异常原因分析
• 解决方法
• 心得

问题背景

将原有项目中的websocket模块迁移到基于SpringCloud Alibaba的微服务系统中，其中网关部分使用的是gateway。

问题现象

迁移后，我们在使用客户端连接websocket时报错：

io.netty.handler.codec.http.websocketx.WebSocketHandshakeException: Invalid subprotocol. Actual: null. Expected one of: protocol

…

同时，我们还有一个用py写的程序，用来模拟客户端连接，但是程序的websocket连接就是正常的。

解决过程

1 检查网关配置

先开始，我们以为是gateway的配置有问题。

但是在检查gateway的route配置后，发现并没有问题。很常见的那种。

...	gateway:      routes:        #表示websocket的转发        - id: user-service-websocket          uri: lb:ws://user-service          predicates:          	- Path=/user-service/mq/**          filters:            - StripPrefix=1

其中，lb指负载均衡，ws指定websocket协议。

ps，如果，这里还有其他协议的相同路径的请求，也可以直接写成：

...gateway:      routes:        #表示websocket的转发        - id: user-service-websocket          uri: lb://user-service          predicates:          	- Path=/user-service/mq/**          filters:            - StripPrefix=1

这样，其他协议的请求也可以通过这个规则进行转发了。

2 跟源码，查找可能的原因

既然gate的配置没有问题，那我们就尝试从源码的角度，看看gateway是如何处理ws协议请求的。

首先，我们要对“gateway是如何工作的”有个大概的认识：

可见，在收到请求后，要先经过多个Filter才会到达Proxied Service。其中，要有自定义的Filter也有全局的Filter，全局的filter可以通过GET请求/actuator/gateway/globalfilters来查看

{  \"org.springframework.cloud.gateway.filter.LoadBalancerClientFilter@77856cc5\": 10100,  \"org.springframework.cloud.gateway.filter.RouteToRequestUrlFilter@4f6fd101\": 10000,  \"org.springframework.cloud.gateway.filter.NettyWriteResponseFilter@32d22650\": -1,  \"org.springframework.cloud.gateway.filter.ForwardRoutingFilter@106459d9\": 2147483647,  \"org.springframework.cloud.gateway.filter.NettyRoutingFilter@1fbd5e0\": 2147483647,  \"org.springframework.cloud.gateway.filter.ForwardPathFilter@33a71d23\": 0,  \"org.springframework.cloud.gateway.filter.AdaptCachedBodyGlobalFilter@135064ea\": 2147483637,  \"org.springframework.cloud.gateway.filter.WebsocketRoutingFilter@23c05889\": 2147483646}

可以看到，其中的WebSocketRoutingFilter似乎与我们这里有关

public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {        this.changeSchemeIfIsWebSocketUpgrade(exchange);        URI requestUrl = (URI)exchange.getRequiredAttribute(ServerWebExchangeUtils.GATEWAY_REQUEST_URL_ATTR);        String scheme = requestUrl.getScheme();        if (!ServerWebExchangeUtils.isAlreadyRouted(exchange) && (\"ws\".equals(scheme) || \"wss\".equals(scheme))) {            ServerWebExchangeUtils.setAlreadyRouted(exchange);            HttpHeaders headers = exchange.getRequest().getHeaders();            HttpHeaders filtered = HttpHeadersFilter.filterRequest(this.getHeadersFilters(), exchange);            List<String> protocols = headers.get(\"Sec-WebSocket-Protocol\");            if (protocols != null) {                protocols = (List)headers.get(\"Sec-WebSocket-Protocol\").stream().flatMap((header) -> {                    return Arrays.stream(StringUtils.commaDelimitedListToStringArray(header));                }).map(String::trim).collect(Collectors.toList());            }            return this.webSocketService.handleRequest(exchange, new WebsocketRoutingFilter.ProxyWebSocketHandler(requestUrl, this.webSocketClient, filtered, protocols));        } else {            return chain.filter(exchange);        }    }

以debug模式跟踪到这里后，可以看到，客户端请求中，子协议指定为“protocol”。

netty相关：

• WebSocketClientHandshaker
• WebSocketClientHandshakerFactory

这段烂尾了。。。

直接看结论吧

最后发现出错的原因是在netty的WebSocketClientHandshanker.finishHandshake

public final void finishHandshake(Channel channel, FullHttpResponse response) {        this.verify(response);        String receivedProtocol = response.headers().get(HttpHeaderNames.SEC_WEBSOCKET_PROTOCOL);        receivedProtocol = receivedProtocol != null ? receivedProtocol.trim() : null;        String expectedProtocol = this.expectedSubprotocol != null ? this.expectedSubprotocol : \"\";        boolean protocolValid = false;        if (expectedProtocol.isEmpty() && receivedProtocol == null) {            protocolValid = true;            this.setActualSubprotocol(this.expectedSubprotocol);        } else if (!expectedProtocol.isEmpty() && receivedProtocol != null && !receivedProtocol.isEmpty()) {            String[] var6 = expectedProtocol.split(\",\");            int var7 = var6.length;            for(int var8 = 0; var8 < var7; ++var8) {                String protocol = var6[var8];                if (protocol.trim().equals(receivedProtocol)) {                    protocolValid = true;                    this.setActualSubprotocol(receivedProtocol);                    break;                }            }        }        if (!protocolValid) {            throw new WebSocketHandshakeException(String.format(\"Invalid subprotocol. Actual: %s. Expected one of: %s\", receivedProtocol, this.expectedSubprotocol));        } else {           ......        }    }

这里，当期望的子协议类型非空，而实际子协议不属于期望的子协议时，会抛出异常。也就是文章最初提到的那个。

3 异常原因分析

客户端在请求时，要求子协议为“protocol”，而我们的后台websocket组件中，并没有指定使用这个子协议，也就无法选出使用的哪个子协议。因此，在走到finishHandShaker时，netty在检查子协议是否匹配时抛出异常WebSocketHandshakeException。 py的模拟程序中，并没有指定子协议，也就不会出错。

而在springboot的版本中，由于我们是客户端直连（通过nginx转发）到websocket服务端的，因此也没有出错（猜测是客户端没有检查子协议是否合法）。。。

解决方法

在WebSocketServer类的注解@ServerEndpoint中，增加subprotocols={“protocol”}

@ServerEndpoint(value = \"/ws/asset\",subprotocols = {\"protocol\"})

随后由客户端发起websocket请求，请求连接成功，未抛出异常。

与客户端的开发人员交流后，其指出，他们的代码中，确实指定了子协议为“protocol”，当时随手写的…

心得

• 定位问题较慢，中间走了不少弯路。有优化的空间；
• 对gateway的模型有了更深刻的理解;
• idea 可以用双击Shift键来查找所有类，包括依赖包中的。

以上为个人经验，希望能给大家一个参考，也希望大家多多支持趣讯吧。