关于微服务:微服务网关Gateway实践总结

有多少申请，被网关截胡；

一、Gateway简介

微服务架构中，网关服务通常提供动静路由，以及流量管制与申请辨认等外围能力，在之前的篇幅中有说过Zuul组件的应用流程，然而当下Gateway组件是更惯例的抉择，上面就围绕Gateway的实际做详细分析；

从架构模式上看，网关不论采纳什么技术组件，都是在客户端与业务服务两头提供一层拦挡与校验的能力，然而相比拟Zuul来说，Gateway提供了更弱小的性能和卓越的性能；

基于实际的场景来看，在性能上网关更偏重申请方的非法校验，流量管控，以及IP级别的拦挡，从架构层面看，通常须要提供灵便的路由机制，比方灰度，负载平衡的策略等，并基于音讯机制，进行零碎级的平安告诉等；

上面围绕客户端、网关层、门面服务的三个节点，剖析Gateway的应用细节，即客户端向网关发出请求，通过网关路由到门面服务解决；

二、动静路由

1、根底概念

路由：作为网关中最外围的能力，从源码构造上看，包含ID、申请URI、断言汇合、过滤汇合等组成；

public class RouteDefinition {    private String id;    private URI uri;    private List<PredicateDefinition> predicates = new ArrayList<>();    private List<FilterDefinition> filters = new ArrayList<>();}

断言+过滤：通常在断言中定义申请的匹配规定，在过滤中定义申请的解决动作，构造上看都是名称加参数汇合，并且反对快捷的形式配置；

public class PredicateDefinition {    private String name;    private Map<String, String> args = new LinkedHashMap<>();}public class FilterDefinition {    private String name;    private Map<String, String> args = new LinkedHashMap<>();}

2、配置路由

以配置的形式，增加facade服务路由，以门路匹配的形式，如果申请门路谬误则断言失败，StripPrefix设置为1，即在过滤中去掉第一个/facade参数；

spring:  application:    name: gateway  cloud:    gateway:      routes:        - id: facade          uri: http://127.0.0.1:8082          predicates:            - Path=/facade/**          filters:            - StripPrefix=1

执行原理如下：

这里是以配置文件的形式，设置facade服务的路由策略，其中指定了门路形式，在Gateway文档中提供了多种路由样例，比方：Header、Cookie、Method、Query、Host等断言形式；

3、编码方式

基于编码的形式治理路由策略，在Gateway文档同样提供了多种参考样例，如果路由服务少并且固定，配置的形式能够解决，如果路由服务很多，并且须要动静增加，那基于库表形式更适宜；

@Configurationpublic class GateConfig {    @Bean    public RouteLocator customRouteLocator(RouteLocatorBuilder builder) {        return builder.routes()                .route("facade",r -> r.path("/facade/**").filters(f -> f.stripPrefix(1))                .uri("http://127.0.0.1:8082")).build();    }}

4、库表加载

在惯例的利用中，从库表中读取路由策略是比拟常见的形式，定义路由工厂类并实现RouteDefinitionRepository接口，波及加载、增加、删除三个外围办法，而后基于服务类从库中读取数据转换为RouteDefinition对象即可；

@Componentpublic class DefRouteFactory implements RouteDefinitionRepository {    @Resource    private ConfigRouteService routeService ;    // 加载    @Override    public Flux<RouteDefinition> getRouteDefinitions() {        return Flux.fromIterable(routeService.getRouteDefinitions());    }    // 增加    @Override    public Mono<Void> save(Mono<RouteDefinition> route) {        return route.flatMap(routeDefinition -> { routeService.saveRouter(routeDefinition);            return Mono.empty();        });    }    // 删除    @Override    public Mono<Void> delete(Mono<String> idMono) {        return idMono.flatMap(routeId -> { routeService.removeRouter(routeId);            return Mono.empty();        });    }}

在源码仓库中采纳的就是库表治理的形式，代码逻辑的更多细节能够移步Git参考，此处不再过多粘贴；

三、自定义路由策略

自定义断言，继承AbstractRoutePredicateFactory类，留神命名以RoutePredicateFactory结尾，重写apply办法，即可执行特定的匹配规定；

@Componentpublic class DefCheckRoutePredicateFactory extends AbstractRoutePredicateFactory<DefCheckRoutePredicateFactory.Config> {    public DefCheckRoutePredicateFactory() {        super(Config.class);    }    @Override    public Predicate<ServerWebExchange> apply(Config config) {        return new GatewayPredicate() {            @Override            public boolean test(ServerWebExchange serverWebExchange) {                log.info("DefCheckRoutePredicateFactory：" + config.getName());                return StrUtil.equals("butte",config.getName());            }        };    }    @Data    public static class Config { private String name; }    @Override    public List<String> shortcutFieldOrder() { return Collections.singletonList("name"); }}

自定义过滤，继承AbstractNameValueGatewayFilterFactory类，留神命名以GatewayFilterFactory结尾，重写apply办法，即可执行特定的过滤规定；

@Componentpublic class DefHeaderGatewayFilterFactory extends AbstractNameValueGatewayFilterFactory {    @Override    public GatewayFilter apply(AbstractNameValueGatewayFilterFactory.NameValueConfig config) {        return (exchange, chain) -> {            log.info("DefHeaderGatewayFilterFactory："+ config.getName() + "-" + config.getValue());            return chain.filter(exchange);        };    }}

配置加载形式，此处断言与过滤即快捷的配置形式，所以在命名上要恪守Gateway的约定；

spring:  cloud:    gateway:      routes:        - id: facade          uri: http://127.0.0.1:8082          predicates:            - Path=/facade/**            - DefCheck=butte          filters:            - StripPrefix=1            - DefHeader=cicada,smile

通常来说，在利用级的零碎中都须要进行断言和过滤的策略自定义，以提供业务或者架构层面的撑持，实现更加粗疏的规定校验，尤其在雷同服务多版本并行时，能够更好的治理路由策略，从而防止分支之间的影响；

四、全局过滤器

在路由中采纳的过滤是GatewayFilter，理论Gateway中还提供了GlobalFilter全局过滤器，尽管从构造上看十分相似，然而其职责是有本质区别的；

全局过滤器1：打印申请ID

@Component@Order(1)public class DefOneGlobalFilter implements GlobalFilter {    @Override    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {        log.info("request-id:{}",exchange.getRequest().getId()) ;        return chain.filter(exchange);    }}

全局过滤器2：打印申请URI

@Component@Order(2)public class DefTwoGlobalFilter implements GlobalFilter {    @Override    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {        log.info("request-uri:{}",exchange.getRequest().getURI()) ;        return chain.filter(exchange);    }}

Gateway网关作为微服务架构零碎中最先接管申请的一层，能够定义许多策略来爱护零碎的平安，比方高并发接口的限流，第三方受权验证，受到歹意攻打时的IP拦挡等等，尽量将非法申请在网关中拦挡掉，从而保证系统的平安与稳固。

五、参考源码

利用仓库：https://gitee.com/cicadasmile/butte-flyer-parent组件封装：https://gitee.com/cicadasmile/butte-frame-parent