我去，你竟然还不会用API网关！

谁践踏了优雅 2022-10-17 01:36 242阅读 0赞

点击上方蓝色“石杉的架构笔记”，选择“设为星标”
    
    回复“PDF”获取独家整理的学习资料！

![5b5cb8b420ccdb7b6d565eda9b1212c4.png][]

**![d27c4ee4e97df4705b737bbb167e89b5.png][]**

![cb2560c163690501db81629922ed7a8e.png][]

长按扫描上方免费领取

![830c694fc63a8ee4d16cda9a2496c2b5.png][]

“

从应用程序架构的变迁过程可以发现，随着业务多变性、灵活性的不断提高，应用程序需要以更加灵活的组合来应对。

同时为了应对业务的细分以及高并发的挑战，微服务的架构被广泛使用，由于微服务架构中应用会被拆分成多个服务。

为了方便客户端对这些服务的调用于是引入了 API 的概念。今天我们就来看看API 网关的原理以及它是如何应用的。

API 网关的定义

网关一词最早出现在网络设备，比如两个相互独立的局域网之间通过路由器进行通信， 中间的路由被称之为网关。

落实在开发层面来说，就是客户端与微服务系统之间存在的网关。从业务层面来说，当客户端完成某个业务的时候，需要同时调用多个微服务。

如图 1 所示，当客户端发起下单请求需要调用：商品查询、库存扣减以及订单更新等服务。

![67f483ea60f1269ddc894041eced38c8.png][]

*图1 ：API 网关加入前后对比*

如果这些服务需要客户端分别调用才能完成，会增加请求的复杂度，同时也会带来网络调用性能的损耗。因此，针对微服务的应用场景就推出了 API 网关的调用。

在客户端与微服务之间加入下单 API 网关，客户端直接给这个 API 网关下达命令，由于后者完成对其他三个微服务的调用并且返回结果给客户端。

从系统层面来说，任何一个应用系统如果需要被其他系统调用，就需要暴露 API，这些 API 代表着的功能点。

正如上面下单的例子中提到的，如果一个下单的功能点需要调用多个服务的时候，在这个下单的 API 网关中就需要聚合多个服务的调用。

这个聚合的方式有点像设计模式中的门面模式（Facade），它为外部的调用提供了一个统一的访问入口。

不仅如此，如图 2 所示，API 网关还可以协助两个系统的通信，在系统之间加上一个中介者协助 API 的调用。

![93328ada024df67ed06a67c8fa334310.png][]

*图 2：对接两个系统的 API 网关*

从客户端类型层面来说，为了屏蔽不同客户端调用差异也可以加入 API 网关。

如图 3 所示，在实际开发过程中 API 网关还可以根据不同的客户端类型（iOS、Android、PC、小程序），提供不同的 API 网关与之对应。

![cf86201de85ef86301de414ff6dfd07e.png][]

*图 3：对接客户端和服务端的 API 网关*

由于 API 网关所处的位置是客户端与微服务交界的地方，因此从功能上它还包括：路由，负载均衡，限流，缓存，日志，发布等等。

Spring Cloud Gateway 概念与定义

API 网关的定义中我们提到了为什么要使用 API 网关，是为了解决客户端对多个微服务进行访问的问题。

由于服务的切分导致一个操作需要同时调用多个服务，因此为这些服务的聚合提供一个统一的门面，这个门面就是 API 网关。

针对于 API 网关有很多的实现方式，例如：Zuul，Kong 等等。这里我们以及 Spring Cloud Gateway 为例展开给大家介绍其具体实现。

一般来说，API 网关对内将微服务进行集合，对外暴露的统一 URL 或者接口信息供客户端调用。

那么客户端是如何与微服务进行连接，并且进行沟通的，需要引入下面几个重要概念 。

![cf419bc0abb038f11ced84046e79b436.png][]

*图 4：路由、断言和过滤器*

如图 4 所示，Spring Cloud Gateway 由三部分组成：

**①路由（Route）：**任何一个来自于客户端的请求都会经过路由，然后到对应的微服务中。

每个路由会有一个唯一的 ID 和对应的目的 URL。同时包含若干个断言（Predicate）和过滤器（Filter）。

**②断言（Predicate）：**当客户端通过 Http Request 请求进入 Spring Cloud Gateway 的时候，断言会根据配置的路由规则，对 Http Request 请求进行断言匹配。

说白了就是进行一次或者多次 if 判断，如果匹配成功则进行下一步处理，否则断言失败直接返回错误信息。

**③过滤器( Filter)：**简单来说就是对流经的请求进行过滤，或者说对其进行获取以及修改的操作。注意过滤器的功能是双向的，也就是对请求和响应都会进行修改处理 。

一般来说 Spring Cloud Gateway 中的过滤器有两种类型：

*  **Gateway Filter**
 *  **Global Filter**

Gateway Filter 用在单个路由和分组路由上。Global Filter 可以作用于所有路由，是一个全局的 Filter。

Spring Cloud Gateway 工作原理

说完了 Spring Cloud Gateway 定义和要素，再来看看其工作原理。总的来说是对客户端请求的处理过程。

![fb3d0489a583a71d0203f5a41ee4c5c1.png][]

*图 5：Spring Cloud Gateway 处理请求流程图*

如图 5 所示，当客户端向 Spring Cloud Gateway 发起请求，该请求会被 HttpWebHandlerAdapter 获取，并且对请求进行提取，从而组装成网关上下文。

将组成的上下文信息传递到 DispatcherHandler 组件。DispatcherHandler 作为请求分发处理器，主要负责将请求分发到对应的处理器进行处理。

这里请求的处理器包括 RoutePredicate HandlerMapping (路由断言处理映射器) 。

路由断言处理映射器用于路由的查找，以及找到 路由后返回对应的 FilteringWebHandler。

其负责组装 Filter 链表并执行过滤处理，之后再将请求转交给应用服务，应用服务处理完后，最后返回 Response 给客户端 。

其中 FilteringWebHandler 处理请求的时候会交给 Filter 进行过滤的处理。

这里需要注意的是由于 Filter 是双向的所以，当客户端请求服务的时候，会通过 Pre Filter 中的 Filter 处理请求。

当服务处理完请求以后返回客户端的时候，会通过 Post Filter 再进行一次处理。

Spring Cloud Gateway 最佳实践

上面介绍了 Spring Cloud Gateway 的定义和实现原理，下面根据几个常用的场景介绍一下 Spring Cloud Gateway 如何实现网关功能的。

我们会根据基本路由、权重路由、限流、动态路由几个方面给大家展开介绍。

**基本路由**

基本路由，主要功能就是在客户端请求的时候，根据定义好的路径指向到对应的 URI。这个过程中需要用到 Predicates（断言）中的 Path 路由断言处理器。

首先在 POM 文件中加入对应的依赖，如下：

<dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-gateway</artifactId>
    </dependency>

加入如下代码，其中定义的 Path 的路径“/baidu”就是请求时的路径地址。对应的 URI，http://www.baidu.com/ 就是要跳转到的目标地址。

@Bean
    public RouteLocator routeLocator(RouteLocatorBuilder builder) {
       return builder.routes()
             .route(r ->r.path("/baidu")
                   .uri("http://www.baidu.com/").id("baidu_route")
             ).build();
    }

同样上面的功能也可以在 yml 文件中实现。配置文件如下，说白了就是对 Path 和 URI 参数的设置，实现的功能和上面代码保持一致。

spring:
      cloud:
        gateway:
          routes:
          - id: baidu_route
            uri: http://baidu.com:80/
            predicates:
            - Path=/baidu

此时启动 API 网关，假设网关的访问地址是“localhost:8080/baidu”，当用户请求这个地址的时候就会自动请求“www.baidu.com”这个网站。这个配置起来很简单，有 Nginx 基础的朋友应该很快就能上手。

**权重路由**

这个使用场景相对于上面的简单路由要多一些。由于每个微服务发布新版本的时候，通常会保持老版本与新版版同时存在。

然后通过网关将流量逐步从老版本的服务切换到新版本的服务。这个逐步切换的过程就是常说的灰度发布。

此时，API 网关就起到了流量分发的作用，通常来说最开始的老版本会承载多一些的流量，例如 90% 的请求会被路由到老版本的服务上，只有 10% 的请求会路由到新服务上去。

从而观察新服务的稳定性，或者得到用户的反馈。当新服务稳定以后，再将剩下的流量一起导入过去。

![a69aabe532cc4e0fb19d36b00df23a3c.png][]

*图 6：灰度发布，路由到新/老服务*

如下代码所示，假设 API 网关还是采用 8080 端口，需要针对两个不同的服务配置路由权重。因此在 routes 下面分别配置 service\_old 和 service\_new。

server.port: 8080
    spring:
      application:
        name: gateway-test
      cloud:
        gateway:
          routes:
          - id: service_old
            uri: http://localhost:8888/v1
            predicates:
            - Path=/gatewaytest
            - Weight=service, 90
          - id: service_new
            uri: http://localhost:8888/v2
            predicates:
            - Path=/gatewaytest
            - Weight=service, 10

在两个配置中对应的 URI 分别是新老两个服务的访问地址，通过“http://localhost:8888/v1”和“http://localhost:8888/v2”来区别。

在 Predicates（断言）中定义了的 Path 是想通的都是“/gatewaytest”，也就是说对于客户端来说访问的路径都是一样的，从路径上客户不会感知他们访问的是新服务或者是老服务。

主要参数是在 Weight，针对老/新服务分别配置的是 90 和 10。也就是有 90% 的流量会请求老服务，有 10% 的流量会请求新服务。

简单点说，如果有 100 次请求，其中 90 次会请求 v1（老服务），另外的 10 次会请求 v2（新服务）。

**限流**

当服务在短时间内迎来高并发，并发量超过服务承受的范围就需要使用限流。例如：秒杀、抢购、下单服务。

通过请求限速或者对一个时间窗口内的请求进行限速来保护服务。当达到限制速率则可以拒绝请求，返回错误代码，或者定向到友好页面。

一般的中间件都会有单机限流框架，支持两种限流模式：

*  **控制速率**
 *  **控制并发**

这里通过 Guava 中的 Bucket4j 来实现限流操作。按照惯例引入 Bucket4j 的依赖：

<dependency>
        <groupId>com.github.vladimir-bukhtoyarov</groupId>
        <artifactId>bucket4j-core</artifactId>
        <version>4.0.0</version>
    </dependency>

由于需要对于用户请求进行监控，因此通过实现 GatewayFilter 的方式自定义 Filter，然后再通过 Gateway API Application 应用这个自定义的 Filter。

这里我们使用的是令牌桶的方式进行限流，因此需要设置桶的容量（capacity），每次填充的令牌数量（refillTokens）以及填充令牌的间隔时间（refillDuration）。

初始化这三个参数以后，通过 createNewBucket 方法针对请求建立令牌桶（bucket），在 Filter 方法中实现限流的主要逻辑。

通过 ServerWebExchange 获取请求的上下文中的 IP 信息，针对 IP 建立对应的令牌桶，这个 IP 与令牌桶的对应关系放到了 LOCAL\_CACHE 中。

每次请求经过的时候通过 tryConsume（1） 方法消费一个令牌，直到没有令牌的时候返回 HttpStatus.TOO\_MANY\_REQUESTS 的状态码（429），此时网关直接返回请求次数太多，即便是再有请求进来也不会路由到对应的服务了。

只有等待下一个时间间隔，一定数量的令牌放到桶里的时候，请求拿到桶中的令牌才能再次请求服务。

public class GatewayRateLimitFilterByIp implements GatewayFilter, Ordered {
        private static final Map<String, Bucket> LOCAL_CACHE = new ConcurrentHashMap<>();
        int capacity;
        int refillTokens;
        Duration refillDuration;
        public GatewayRateLimitFilterByIp() {
        }
    
        public GatewayRateLimitFilterByIp(int capacity, int refillTokens, Duration refillDuration) {
            this.capacity = capacity;
            this.refillTokens = refillTokens;
            this.refillDuration = refillDuration;
        }
    
        private Bucket createNewBucket() {
            Refill refill = Refill.of(refillTokens, refillDuration);
            Bandwidth limit = Bandwidth.classic(capacity, refill);
            return Bucket4j.builder().addLimit(limit).build();
        }
    
        @Override
        public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
            String ip = exchange.getRequest().getRemoteAddress().getAddress().getHostAddress();
            Bucket bucket = LOCAL_CACHE.computeIfAbsent(ip, k -> createNewBucket());
            if (bucket.tryConsume(1)) {
                return chain.filter(exchange);
            } else {
    exchange.getResponse().setStatusCode(HttpStatus.TOO_MANY_REQUESTS);
                return exchange.getResponse().setComplete();
            }
        }
    }

上面的代码定义了 Filter 其中针对访问的 IP 生成令牌桶，并且定义了桶的大小、每次放入桶令牌的个数、放入令牌的间隔时间。

并且通过 Filter 方法重写了过滤的逻辑，那么下面只需要将这个 Filter 应用到 Spring Cloud Gateway 的规则上去就可以了。通过下面代码定义网关的路由断言和过滤器。

在 Filters 中新建一个上面代码定义的过滤器，指定容量是 20，每两秒放入令牌，每次放入一个令牌。

那么当用户访问 rateLimit 路径的时候就会根据客制化的 Filter 进行限流。

@Bean
    public RouteLocator testRouteLocator(RouteLocatorBuilder builder) {
        return builder.routes()
                .route(r -> r.path("/rateLimit")
                        .filters(f -> f.filter(new GatewayRateLimitFilterByIp(20,1,Duration.ofSeconds(2))))
                        .uri("http://localhost:8888/rateLimit")
                        .id("rateLimit_route")
                ).build();
    }

这里的限流只是给大家提供一种思路，通过实现 GatewayFilter，重写其中的 Filter 方法，加入对流量的控制代码，然后在 Spring Cloud Gateway 中进行应用就可以了。

**动态路由**

由于 Spring Cloud Gateway 本身也是一个服务，一旦启动以后路由配置就无法修改了。

无论是上面提到的编码注入的方式还是配置的方式，如果需要修改都需要重新启动服务。

如果回到 Spring Cloud Gateway 最初的定义，我们会发现每个用户的请求都是通过 Route 访问对应的微服务，在 Route 中包括 Predicates 和 Filters 的定义。

只要实现 Route 以及其包含的 Predicates 和 Filters 的定义，然后再提供一个 API 接口去更新这个定义就可以动态地修改路由信息了。

按照这个思路需要做以下几步来实现：

**①定义 Route、Predicates 和 Filters**

其中 Predicates 和 Filters 包含在 Route 中。实际上就是 Route 实体的定义，针对 Route 进行路由规则的配置。

public class FilterDefinition {
        //Filter Name
        private String name;
        //对应的路由规则
        private Map<String, String> args = new LinkedHashMap<>();
    }
    public class PredicateDefinition {
        //Predicate Name
        private String name;
        //对应的断言规则
        private Map<String, String> args = new LinkedHashMap<>();
    }
    public class RouteDefinition {
        //断言集合
    private List<PredicateDefinition> predicates = new ArrayList<>();
    //路由集合
    private List< FilterDefinition > filters= new ArrayList<>();
    //uri
    private String uri;
    //执行次序
    private int order = 0;
    }

**②实现路由规则的操作，包括添加，更新，删除**

有了路由的定义（Route，Predicates，Filters），然后再编写针对路由定义的操作。

例如：添加路由，删除路由，更新路由之类的。编写 RouteServiceImpl 实现 ApplicationEventPublisherAware。

主要需要 override 其中的 setApplicationEventPublisher 方法，这里会传入 ApplicationEventPublisher 对象，通过这个对象发布路由定义的事件包括：add，update，delete。

贴出部分代码如下：

@Service
    public class RouteServiceImpl implements ApplicationEventPublisherAware {
        @Autowired
        private RouteDefinitionWriter routeDefinitionWriter;
        private ApplicationEventPublisher publisher;
        //添加路由规则
        public String add(RouteDefinition definition) {
            routeDefinitionWriter.save(Mono.just(definition)).subscribe();
            this.publisher.publishEvent(new RefreshRoutesEvent(this));
            return "success";
        }
        public String update(RouteDefinition definition) {
            try {
              this.routeDefinitionWriter.delete(Mono.just(definition.getId()));
            } catch (Exception e) {
    
            }
            try {
                routeDefinitionWriter.save(Mono.just(definition)).subscribe();
                this.publisher.publishEvent(new RefreshRoutesEvent(this));
                return "success";
            } catch (Exception e) {
    
            }
        }
        public String delete(String id) {
            try {
                this.routeDefinitionWriter.delete(Mono.just(id));
                return "delete success";
            } catch (Exception e) {
    
            }
    
        }
    
        @Override
        public void setApplicationEventPublisher(ApplicationEventPublisher applicationEventPublisher) {
            this.publisher = applicationEventPublisher;
        }

**③对外部提供 API 接口能够让用户或者程序动态修改路由规则**

从代码上来说就是一个 Controller。这个 Controller 中只需要调用 routeServiceImpl 就行了，主要也是用到客制化路由实现类中的 add，update，delete 方法。

说白了就是对其进行了一次包装，让外部系统可以调用，并且修改路由的配置。

经过简化以后的代码如下，这里只对 add 方法进行了包装，关于 update 和 delete 方法在这里不展开说明，调用方式类似 add。

public class RouteController {
    
        @Autowired
        private routeServiceImpl routeService;
    
        @PostMapping("/add")
        public String add(@RequestBody RouteDefinition routeDefinition) {
            try {
                RouteDefinition definition = assembleRouteDefinition(routeDefinition);
                return this.dynamicRouteService.add(definition);
            } catch (Exception e) {
                       }
            return "succss";
        }
    }

**④启动程序进行路由的添加和更新操作**

假设更新 API 网关配置的服务在 8888 端口上。于是通过 http://localhost:8888/actuator/gateway/routes 访问当前的路由信息，由于现在没有配置路由这个信息是空。

那么通过 http://localhost:8888/route/add 方式添加一条路由规则，这里选择 Post 请求，输入类型为 Json 如下：

{
        "filter":[],
        "id":"baidu_route",
        "order":0,
        "predicates":[{
            "args":{
                "pattern":"/baidu"
            },
            "name":"Path"
        }],
        "uri":"https://www.baidu.com"
    }

Json 中配置的内容和简单路由配置的内容非常相似。设置了 Route，当 Predicates 为 baidu 的时候，将请求引导到 www.baidu.com 的网站进行响应。

此时再通过访问 http://localhost:8888/baidu 的路径访问的时候，就会被路由到 www.baidu.com 的网站。

此时如果需要修改路由配置，可以通过访问 http://localhost:8888/route/update 的 API 接口，通过 Post 方式传入 Json 结构，例如：

{
        "filter":[],
        "id":"CTO_route",
        "order":0,
        "predicates":[{
            "args":{
                "pattern":"/CTO"
            },
            "name":"Path"
        }],
        "uri":"https://www.51CTO.com"
    }

在更新完成以后，再访问 http://localhost:8888/CTO 的时候就会把引导到 www.51CTO.com 的网站了。

通过上面四步操作，即使不重启 Spring Cloud Gateway 服务也可以动态更改路由的配置信息。

总结

由于微服务的盛行，API 网关悄然兴起。针对 API 网关本身讲述了其存在的原因，它不仅提供了服务的门面，而且可以协调不同的系统之间的通讯以及服务不同的客户端接口。

针对 API 网关的最佳时间 Spring Cloud Gateway 的定义和概念的解释，其实现了路由、过滤器、断言，针对不同的客户端请求可以路由到不同的微服务，以及其中几个组件是如何分工合作完成路由工作的。

在最佳实践的介绍中分别从：基本路由、权重路由、限流和动态路由几个方面进行了阐述。

![8f13bef3cbb831a1df3165dac07d36ec.png][]

[5b5cb8b420ccdb7b6d565eda9b1212c4.png]: /images/20221014/18adf82387d3426bbd2ef3c5a5da5f15.png
[d27c4ee4e97df4705b737bbb167e89b5.png]: /images/20221014/72792867052c47d58bb0c88ad111e4bc.png
[cb2560c163690501db81629922ed7a8e.png]: /images/20221014/5798b26447814e3f938724df639ddc50.png
[830c694fc63a8ee4d16cda9a2496c2b5.png]: /images/20221014/a7645da87bb44659b4b8abf604d6696f.png
[67f483ea60f1269ddc894041eced38c8.png]: /images/20221014/ee323e6ecaba46e6a2b502a40ef17af8.png
[93328ada024df67ed06a67c8fa334310.png]: /images/20221014/957e49151f704524b21561b5e5b7667a.png
[cf86201de85ef86301de414ff6dfd07e.png]: /images/20221014/b3146cf627c44564b1ec7bff9d24d181.png
[cf419bc0abb038f11ced84046e79b436.png]: /images/20221014/d31a4e4e941a473a8419f9cf663ced47.png
[fb3d0489a583a71d0203f5a41ee4c5c1.png]: /images/20221014/4450e4ee9ce24cfe8b580087d459200d.png
[a69aabe532cc4e0fb19d36b00df23a3c.png]: /images/20221014/47f1dad18a5e407e95d453a7f823fe4f.png
[8f13bef3cbb831a1df3165dac07d36ec.png]: /images/20221014/66aeb8271acd4b4fa7d9b708365d00a3.png