前言

如果对springcloud-gateway有了解的同学，应该会知道springcloud-gateway默认提供了一个基于内存的路由定义仓库。

org.springframework.cloud.gateway.route.InMemoryRouteDefinitionRepository

基于内存的好处，就是快，但是缺点就是网关重启路由就丢失了。为了方便管理网关路由以及保证网关重启，路由不丢失，于是业务部门做了形如图的改造

就是会有一个gateway的portal面板来管理路由，然后路由规则是保存在redis，gateway从redis取路由规则。其中portal面板由一个小组负责，gateway的路由读取以及相关其他功能（比如协议转换、参数转换等）又是由另外一个小组负责，portal小组使用了redisson来进行redis相关操作，而gateway小组采用redisTemplate进行操作。redis的存储数据结构为hash。以上是业务背景介绍，接下来我们进入正文

正文

gateway小组的redisTemplate的bean定义如下

    @Bean
    @ConditionalOnMissingBean
    public RedisTemplate<String, Object> routeRedisTemplate(LettuceConnectionFactory lettuceConnectionFactory) {
    
        RedisTemplate<String, Object> redisTemplate = new RedisTemplate<String, Object>();
        redisTemplate.setConnectionFactory(lettuceConnectionFactory);
        redisTemplate.setValueSerializer(RedisSerializer.json());
        redisTemplate.setKeySerializer(RedisSerializer.string());
        redisTemplate.setHashKeySerializer(RedisSerializer.string());
        redisTemplate.afterPropertiesSet();
        Jackson2JsonRedisSerializer<Object> serializer = new Jackson2JsonRedisSerializer<>(Object.class);
        ObjectMapper objectMapper = new ObjectMapper()
                .registerModule(new ParameterNamesModule())
                .registerModule(new Jdk8Module())
                .registerModule(new JavaTimeModule());
        objectMapper.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
        // 指定序列化输入的类型，类必须是非final修饰的。序列化时将对象全类名一起保存下来
        objectMapper.activateDefaultTyping(LaissezFaireSubTypeValidator.instance, ObjectMapper.DefaultTyping.NON_FINAL);
        serializer.setObjectMapper(objectMapper);
        redisTemplate.setValueSerializer(serializer);
        redisTemplate.setHashValueSerializer(serializer);
        return redisTemplate;
    }

注： portal小组的redission这边就不贴了，这个redisson，portal小组有进行浅浅的封装，而上面的redisTemplate配置，属于地摊货，百度一抓一大把，因此也没啥敏感，就贴一下。

前面说过，这边路由规则保存的数据结构为hash，其portal小组初版的保存代码形如下

  RBatch batch = redissonClient.createBatch();

        batch.getMap(ROUTE_DEFINITION_REDIS_KEY, new JsonJacksonCodec()).putAllAsync(routeDefinitionMap).onComplete((result, e)->{
    
            if(e!= null){
    
                log.error(">>>>>>>>>>>>>>>>> Redis save batch fail",e);
            }
        });
        batch.execute();

结合上面redisTemplate的配置

思考题一：当gateway从redis读取规则，会出现什么情况？

答案是会出现读取转换报错，原因是JsonJacksonCodec()默认生成的hash结构，会带@class：全限定类名，而上面redisTemplate通过Jackson2JsonRedisSerializer反序列化，并没@class：全限定类名。

解法： redisson的序列化方式可以改成用TypedJsonJacksonCodec，这种序列化方式有如下效果

Json Jackson Type codec. Doesn't include `@class` field during data encoding, and doesn't require it for data decoding.

大白话就是忽略@class

思考题二：当改成TypedJsonJacksonCodec后，gateway能正常从redis读取规则吗？

答案是仍然不能，原因是redisTemplate和TypedJsonJacksonCodec使用的objectMapper设置的规则属性不一样

解法： 让redisTemplate和TypedJsonJacksonCodec保持相同的objectMapper设置规则。因此我们可以定义一个JsonJacksonCodec工厂。工厂如下示例代码

public final class JsonJacksonCodecFactory {
    

    private JsonJacksonCodecFactory() {
    
    }


    public static TypedJsonJacksonCodec getTypedJsonJacksonCodec(Class<?> mapKeyClass, Class<?> mapValueClass) {
    
        return new TypedJsonJacksonCodec(mapKeyClass, mapValueClass, getObjectMapper());
    }

    public static TypedJsonJacksonCodec getTypedJsonJacksonCodec(Class<?> mapValueClass) {
    
        return new TypedJsonJacksonCodec(Object.class, mapValueClass, getObjectMapper());
    }

    private static ObjectMapper getObjectMapper() {
    
        ObjectMapper objectMapper = new ObjectMapper()
                .registerModule(new ParameterNamesModule())
                .registerModule(new Jdk8Module())
                .registerModule(new JavaTimeModule());
        objectMapper.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
        // 指定序列化输入的类型，类必须是非final修饰的。序列化时将对象全类名一起保存下来
        objectMapper.activateDefaultTyping(LaissezFaireSubTypeValidator.instance, ObjectMapper.DefaultTyping.NON_FINAL);
        return objectMapper;
    }
}

然后将redisson的序列化切换成用工厂来获取

思考题三：当改成我们自定义的序列化后，gateway能正常从redis读取规则吗？改造后，还有没有其他问题？

答案是因为现在redisTemplate和redisson的value序列化规则保持一致了，而因为网关读取路由规则，是读取整个列表，因此可以正常读取。

改造后，根据key进行路由删除会存在问题，因为redisson使用Jackson进行序列化时，其redis key默认也是用了Jackson进行序列化，这样会造成，key保存在redis，会出现“key”，即会多了双引号。而上面的redisTemplate key的序列化方式，是通过RedisSerializer.string()，这个方式可以保证key是原样输出。

解法： 可以将redisTemplate key的序列化方式也改成用Jackson，不过正常不会这么干。因此解法就是将redisson key序列化方式也改成通过string。那我们要怎么做，我们可以通过再次自定义序列化来解决，不过这种方案我们不推荐了，毕竟如无必要，勿增实体，我们可以直接利用redisson提供的序列化组合器（CompositeCodec）来实现。

示例代码如下

 batch.getMap(ROUTE_DEFINITION_REDIS_KEY, new CompositeCodec(new StringCodec(),JsonJacksonCodecFactory.getTypedJsonJacksonCodec(RouteDefinition.class))).putAllAsync(routeDefinitionMap).onComplete((result, e)->{
    
            if(e!= null){
    
                log.error(">>>>>>>>>>>>>>>>> Redis save batch fail",e);
            }
        });

总结

本文的采坑主要就是双方的key，value的编解码没对应上，就是事先没沟通好，其次不知道大家会不会疑问，为什么一个小组用redisTemplate，另一个小组用redission，其实也没别的啥原因，因为一个小组对redisTemplate使用比较多，另一个小组使用redission比较多，大白话就是擅长什么用什么。最后redisson是一个好东西，毕竟是redis son，虎父无犬子