Spring Cloud Gateway动态路由实现

Gateway上线部署分析

当你的网关程序开发完成之后，需要部署到生产环境，这个时候你的程序不能是单点运行的，肯定是多节点启动(独立部署或者docker等容器部署)，防止单节点故障导致整个服务不能访问，网关是对客户端的入口与出口，在生产运行中极为重要，哪怕是简单的重启也会导致部分请求的丢失。

网关的路由配置这个时候就是一个大问题，是代码里面编写还是配置文件配置？

他们都有一个致命的缺点，当有新的程序需要接入到网关进行路由或者有服务需要下线时候需要修改代码或者配置，然后重启整个网关程序，导致其他正常的服务路由受到了影响。各个网关是否都进行了配置更新？又如何查看当前有哪些配置呢？

Spring Boot Admin对Gateway的支持

Spring Boot Admin是一个管理和监控Spring Boot应用程序的开源软件。它与应用中的Spring Boot Actuator的无缝对接，提供了方便的管理界面直接管理应用程序，支持客户端直连模式与注册中心配置模式。本文暂不介绍Spring Boot Admin的相关配置，会在其他的文档中单独讲解。
SpringBoot Admin很好的支持了Gateway，可以直接在管理界面中查看相关的路由配置，添加或者删除。

路由列表

添加路由

为什么Spring Boot Admin程序中能有这些功能，是因为Gateway提供了相应的Actuator Endpoint接口来管理路由配置，那又为什么不用呢？下面一步一步分析

Gateway提供的Actuator接口

接口列表

官方默认提供了这些接口进行网关的管理，例如获取所有的路由：
GET http://ip:port/actuator/gateway/routes

问题分析

在Spring Boot Admin的管理平台中删除路由，会发现删除失败，添加的成功后路由配置又是存放到了哪里呢？配置文件？
如果添加的路由配置不能够落地，就会在网关重启之后丢失，这样明显没法实现稳定的动态路由。

Spring Gateway Actuator源码分析

在GatewayControllerEndpoint类中，定义了相关的api，比如新增或者删除

@PostMapping("/routes/{id}")
@SuppressWarnings("unchecked")
public Mono<ResponseEntity<Void>> save(@PathVariable String id,
        @RequestBody Mono<RouteDefinition> route) {
    return this.routeDefinitionWriter.save(route.map(r -> {
        r.setId(id);
        log.debug("Saving route: " + route);
        return r;
    })).then(Mono.defer(() -> Mono
            .just(ResponseEntity.created(URI.create("/routes/" + id)).build())));
}

@DeleteMapping("/routes/{id}")
public Mono<ResponseEntity<Object>> delete(@PathVariable String id) {
    return this.routeDefinitionWriter.delete(Mono.just(id))
            .then(Mono.defer(() -> Mono.just(ResponseEntity.ok().build())))
            .onErrorResume(t -> t instanceof NotFoundException,
                    t -> Mono.just(ResponseEntity.notFound().build()));
}

这里面的核心是routeDefinitionWriter这个对象，他是一个RouteDefinitionWriter接口的对象，RouteDefinitionWriter唯一的继承是RouteDefinitionRepository类，RouteDefinitionRepository唯一的继承是InMemoryRouteDefinitionRepository，在InMemoryRouteDefinitionRepository中有这样的一段代码

//创建了一个以路由id为key的路由存储Map
private final Map<String, RouteDefinition> routes = synchronizedMap(
            new LinkedHashMap<String, RouteDefinition>());

在GatewayAutoConfiguration自动配置类中，有这样的一段代码，就是routeDefinitionWriter的申明。

@Bean
@ConditionalOnMissingBean(RouteDefinitionRepository.class)
public InMemoryRouteDefinitionRepository inMemoryRouteDefinitionRepository() {
    return new InMemoryRouteDefinitionRepository();
}

原来我们通过actuator接口在新增或者删除路由配置的时候，都是对routeDefinitionWriter对象中的routes这个Map进行操作。
为什么我们能看到在配置文件中配置的路由，但是又删除不了呢？如果你仔细的阅读源码，你会发现/actuator/gateway/routes这个接口获取的是routeDefinitionLocator中的路由配置，routeDefinitionLocator的类型是CompositeRouteDefinitionLocator，并且他的逻辑是把其他的所有RouteDefinitionLocator类型的都包含进去了，读取接口/actuator/gateway/routes时，你获取的是整个系统的全部路由配置。

routes中的routeDefinitionLocator

RouteDefinitionLocator子类

@Bean
@Primary
public RouteDefinitionLocator routeDefinitionLocator(
        List<RouteDefinitionLocator> routeDefinitionLocators) {
    return new CompositeRouteDefinitionLocator(
            Flux.fromIterable(routeDefinitionLocators));
}

根据上面的分析，我们现在有几个问题需要处理
1、增加的路由配置是保存在内存中的，我们没有办法保存它
2、删除只能删除通过接口增加的路由配置，配置文件中定义的不能删除

自定义路由配置存储

我们需要自定义自己的路由存储，统一管理，全部路由配置都放在一起，除了一个默认的路由用于最后的默认拦截(其他路由断言匹配不上的统一走默认的格式返回)

你可以将你的路由配置放到数据库、mongo、redis等等你方便的地方，这里我已文件系统为例介绍如何自定义路由配置存储。

@Component
public class FileRouteDefinitionRepository implements RouteDefinitionRepository, ApplicationEventPublisherAware {
    private static final Logger LOGGER = LoggerFactory.getLogger(FileRouteDefinitionRepository.class);
    private ApplicationEventPublisher publisher;
    private List<RouteDefinition> routeDefinitionList = new ArrayList<>();

    @Value("${gateway.route.config.file}")
    private String file;

    @Override
    public void setApplicationEventPublisher(ApplicationEventPublisher publisher) {
        this.publisher = publisher;
    }

    @PostConstruct
    public void init() {
        load();
    }

    /**
     * 监听事件刷新配置
     */
    @EventListener
    public void listenEvent(RouteConfigRefreshEvent event) {
        load();
        this.publisher.publishEvent(new RefreshRoutesEvent(this));
    }

    /**
     * 加载
     */
    private void load() {
        try {
            String jsonStr = Files.lines(Paths.get(file)).collect(Collectors.joining());
            routeDefinitionList = JSON.parseArray(jsonStr, RouteDefinition.class);
            LOGGER.info("路由配置已加载,加载条数:{}", routeDefinitionList.size());
        } catch (Exception e) {
            LOGGER.error("从文件加载路由配置异常", e);
        }
    }

    @Override
    public Mono<Void> save(Mono<RouteDefinition> route) {
        return Mono.defer(() -> Mono.error(new NotFoundException("Unsupported operation")));
    }

    @Override
    public Mono<Void> delete(Mono<String> routeId) {
        return Mono.defer(() -> Mono.error(new NotFoundException("Unsupported operation")));
    }

    @Override
    public Flux<RouteDefinition> getRouteDefinitions() {
        return Flux.fromIterable(routeDefinitionList);
    }
}

这里我们对于save与delete的操作都返回了拒绝的操作，因为我们的路由配置是统一的管理，同一份配置对应的是n个Gateway节点，增删需要额外的统一操作，对于路由的获取根据Event事件加载，这是因为修改了路由配置并不是需要立即发布到运行环境中，可能还需要在某一个测试节点上验证过后在统一的进行上线。

新增的Actuator Endpoint，刷新路由的时候，先加载路由配置到内存中，然后再使用RefreshRoutesEvent事件刷新内存中路由配置。

@Component
@RestControllerEndpoint(id = "demoGateway")
public class CustomGatewayControllerEndpoint implements ApplicationEventPublisherAware {
    private ApplicationEventPublisher publisher;

    @Override
    public void setApplicationEventPublisher(ApplicationEventPublisher publisher) {
        this.publisher = publisher;
    }

    @PostMapping("/refreshRouteConfig")
    public Mono<Void> refreshRoutes() {
        this.publisher.publishEvent(new RouteConfigRefreshEvent(this));
        return Mono.empty();
    }
}

官方文档配置与json的转换

[
  {
    "filters": [
      {
        "args": {
          "name": "hystrix",
          "fallbackUri": "forward:/hystrix"
        },
        "name": "Hystrix"
      },
      {
        "args": {},
        "name": "RateLimit"
      }
    ],
    "id": "DEMO_API_ROUTE",
    "order": 1,
    "predicates": [
      {
        "args": {
          "_genkey_0": "/demoApi/**"
        },
        "name": "Path"
      }
    ],
    "uri": "lb://demo-api"
  }
]

其实路由的定义就是RouteDefine对象的创建，根据json反序列化成一个对象即可
id 路由配置的id名字
uri 跳转的地址，lb://表示基于服务注册的负载均衡
order 路由的顺序，越小越先匹配
predicates 断言列表，比如根据post并且path是什么开头
filters 过滤器列表，匹配后需要做的一些操作，比如增加一个请求头字段

_genkey_0这个name很奇怪，是因为官方在定义各种各样的PredicateFactory时，有些PredicateFactory并没有字段名称

genkey名字生成

其实这个算是官方的不规范

线上的推荐方案

路由配置已经统一的进行管理了，可能你放到稳妥的数据库中，你必须得有一个完善的管理界面来管理路由配置，并且支持一键发布到所有节点，在这之前你还需要读取发布到一台测试机验证所有的路由配置都是ok的，路由的配置存储应该加入版本控制。