《完美世界》txt全集,好看的电视剧

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

我去，你竟然還不會用API網(wǎng)關(guān)！

【稿件】從應(yīng)用程序架構(gòu)的變遷過程可以發(fā)現(xiàn)，隨著業(yè)務(wù)多變性、靈活性的不斷提高，應(yīng)用程序需要以更加靈活的組合來應(yīng)對。

創(chuàng)新互聯(lián)建站是少有的網(wǎng)站設(shè)計、成都網(wǎng)站建設(shè)、營銷型企業(yè)網(wǎng)站、成都微信小程序、手機APP,開發(fā)、制作、設(shè)計、賣友情鏈接、推廣優(yōu)化一站式服務(wù)網(wǎng)絡(luò)公司,成立于2013年,堅持透明化,價格低,無套路經(jīng)營理念。讓網(wǎng)頁驚喜每一位訪客多年來深受用戶好評

圖片來自 Pexels

同時為了應(yīng)對業(yè)務(wù)的細(xì)分以及高并發(fā)的挑戰(zhàn)，微服務(wù)的架構(gòu)被廣泛使用，由于微服務(wù)架構(gòu)中應(yīng)用會被拆分成多個服務(wù)。

為了方便客戶端對這些服務(wù)的調(diào)用于是引入了 API 的概念。今天我們就來看看API 網(wǎng)關(guān)的原理以及它是如何應(yīng)用的。

API 網(wǎng)關(guān)的定義

網(wǎng)關(guān)一詞最早出現(xiàn)在網(wǎng)絡(luò)設(shè)備，比如兩個相互獨立的局域網(wǎng)之間通過路由器進(jìn)行通信，中間的路由被稱之為網(wǎng)關(guān)。

落實在開發(fā)層面來說，就是客戶端與微服務(wù)系統(tǒng)之間存在的網(wǎng)關(guān)。從業(yè)務(wù)層面來說，當(dāng)客戶端完成某個業(yè)務(wù)的時候，需要同時調(diào)用多個微服務(wù)。

如圖 1 所示，當(dāng)客戶端發(fā)起下單請求需要調(diào)用：商品查詢、庫存扣減以及訂單更新等服務(wù)。

圖1 ：API 網(wǎng)關(guān)加入前后對比

如果這些服務(wù)需要客戶端分別調(diào)用才能完成，會增加請求的復(fù)雜度，同時也會帶來網(wǎng)絡(luò)調(diào)用性能的損耗。因此，針對微服務(wù)的應(yīng)用場景就推出了 API 網(wǎng)關(guān)的調(diào)用。

在客戶端與微服務(wù)之間加入下單 API 網(wǎng)關(guān)，客戶端直接給這個 API 網(wǎng)關(guān)下達(dá)命令，由于后者完成對其他三個微服務(wù)的調(diào)用并且返回結(jié)果給客戶端。

從系統(tǒng)層面來說，任何一個應(yīng)用系統(tǒng)如果需要被其他系統(tǒng)調(diào)用，就需要暴露 API，這些 API 代表著的功能點。

正如上面下單的例子中提到的，如果一個下單的功能點需要調(diào)用多個服務(wù)的時候，在這個下單的 API 網(wǎng)關(guān)中就需要聚合多個服務(wù)的調(diào)用。

這個聚合的方式有點像設(shè)計模式中的門面模式(Facade)，它為外部的調(diào)用提供了一個統(tǒng)一的訪問入口。

不僅如此，如圖 2 所示，API 網(wǎng)關(guān)還可以協(xié)助兩個系統(tǒng)的通信，在系統(tǒng)之間加上一個中介者協(xié)助 API 的調(diào)用。

圖 2：對接兩個系統(tǒng)的 API 網(wǎng)關(guān)

從客戶端類型層面來說，為了屏蔽不同客戶端調(diào)用差異也可以加入 API 網(wǎng)關(guān)。

如圖 3 所示，在實際開發(fā)過程中 API 網(wǎng)關(guān)還可以根據(jù)不同的客戶端類型(iOS、Android、PC、小程序)，提供不同的 API 網(wǎng)關(guān)與之對應(yīng)。

圖 3：對接客戶端和服務(wù)端的 API 網(wǎng)關(guān)

由于 API 網(wǎng)關(guān)所處的位置是客戶端與微服務(wù)交界的地方，因此從功能上它還包括：路由，負(fù)載均衡，限流，緩存，日志，發(fā)布等等。

Spring Cloud Gateway 概念與定義

API 網(wǎng)關(guān)的定義中我們提到了為什么要使用 API 網(wǎng)關(guān)，是為了解決客戶端對多個微服務(wù)進(jìn)行訪問的問題。

由于服務(wù)的切分導(dǎo)致一個操作需要同時調(diào)用多個服務(wù)，因此為這些服務(wù)的聚合提供一個統(tǒng)一的門面，這個門面就是 API 網(wǎng)關(guān)。

針對于 API 網(wǎng)關(guān)有很多的實現(xiàn)方式，例如：Zuul，Kong 等等。這里我們以及 Spring Cloud Gateway 為例展開給大家介紹其具體實現(xiàn)。

一般來說，API 網(wǎng)關(guān)對內(nèi)將微服務(wù)進(jìn)行集合，對外暴露的統(tǒng)一 URL 或者接口信息供客戶端調(diào)用。

那么客戶端是如何與微服務(wù)進(jìn)行連接，并且進(jìn)行溝通的，需要引入下面幾個重要概念。

圖 4：路由、斷言和過濾器

如圖 4 所示，Spring Cloud Gateway 由三部分組成：

①路由(Route)：任何一個來自于客戶端的請求都會經(jīng)過路由，然后到對應(yīng)的微服務(wù)中。

每個路由會有一個唯一的 ID 和對應(yīng)的目的 URL。同時包含若干個斷言(Predicate)和過濾器(Filter)。

②斷言(Predicate)：當(dāng)客戶端通過 Http Request 請求進(jìn)入 Spring Cloud Gateway 的時候，斷言會根據(jù)配置的路由規(guī)則，對 Http Request 請求進(jìn)行斷言匹配。

說白了就是進(jìn)行一次或者多次 if 判斷，如果匹配成功則進(jìn)行下一步處理，否則斷言失敗直接返回錯誤信息。

③過濾器( Filter)：簡單來說就是對流經(jīng)的請求進(jìn)行過濾，或者說對其進(jìn)行獲取以及修改的操作。注意過濾器的功能是雙向的，也就是對請求和響應(yīng)都會進(jìn)行修改處理。

一般來說 Spring Cloud Gateway 中的過濾器有兩種類型：

Gateway Filter
Global Filter

Gateway Filter 用在單個路由和分組路由上。Global Filter 可以作用于所有路由，是一個全局的 Filter。

Spring Cloud Gateway 工作原理

說完了 Spring Cloud Gateway 定義和要素，再來看看其工作原理?？偟膩碚f是對客戶端請求的處理過程。

圖 5：Spring Cloud Gateway 處理請求流程圖

如圖 5 所示，當(dāng)客戶端向 Spring Cloud Gateway 發(fā)起請求，該請求會被 HttpWebHandlerAdapter 獲取，并且對請求進(jìn)行提取，從而組裝成網(wǎng)關(guān)上下文。

將組成的上下文信息傳遞到 DispatcherHandler 組件。DispatcherHandler 作為請求分發(fā)處理器，主要負(fù)責(zé)將請求分發(fā)到對應(yīng)的處理器進(jìn)行處理。

這里請求的處理器包括 RoutePredicate HandlerMapping (路由斷言處理映射器) 。

路由斷言處理映射器用于路由的查找，以及找到路由后返回對應(yīng)的 FilteringWebHandler。

其負(fù)責(zé)組裝 Filter 鏈表并執(zhí)行過濾處理，之后再將請求轉(zhuǎn)交給應(yīng)用服務(wù)，應(yīng)用服務(wù)處理完后，最后返回 Response 給客戶端。

其中 FilteringWebHandler 處理請求的時候會交給 Filter 進(jìn)行過濾的處理。

這里需要注意的是由于 Filter 是雙向的所以，當(dāng)客戶端請求服務(wù)的時候，會通過 Pre Filter 中的 Filter 處理請求。

當(dāng)服務(wù)處理完請求以后返回客戶端的時候，會通過 Post Filter 再進(jìn)行一次處理。

Spring Cloud Gateway 最佳實踐

上面介紹了 Spring Cloud Gateway 的定義和實現(xiàn)原理，下面根據(jù)幾個常用的場景介紹一下 Spring Cloud Gateway 如何實現(xiàn)網(wǎng)關(guān)功能的。

我們會根據(jù)基本路由、權(quán)重路由、限流、動態(tài)路由幾個方面給大家展開介紹。

基本路由

基本路由，主要功能就是在客戶端請求的時候，根據(jù)定義好的路徑指向到對應(yīng)的 URI。這個過程中需要用到 Predicates(斷言)中的 Path 路由斷言處理器。

首先在 POM 文件中加入對應(yīng)的依賴，如下：

 
 
 
   
  
  
     
  
  
      org.springframework.cloud   
  
  
      spring-cloud-starter-gateway

加入如下代碼，其中定義的 Path 的路徑“/baidu”就是請求時的路徑地址。對應(yīng)的 URI，http://www.baidu.com/ 就是要跳轉(zhuǎn)到的目標(biāo)地址。

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

同樣上面的功能也可以在 yml 文件中實現(xiàn)。配置文件如下，說白了就是對 Path 和 URI 參數(shù)的設(shè)置，實現(xiàn)的功能和上面代碼保持一致。

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

此時啟動 API 網(wǎng)關(guān)，假設(shè)網(wǎng)關(guān)的訪問地址是“l(fā)ocalhost:8080/baidu”，當(dāng)用戶請求這個地址的時候就會自動請求“www.baidu.com”這個網(wǎng)站。這個配置起來很簡單，有 Nginx 基礎(chǔ)的朋友應(yīng)該很快就能上手。

權(quán)重路由

這個使用場景相對于上面的簡單路由要多一些。由于每個微服務(wù)發(fā)布新版本的時候，通常會保持老版本與新版版同時存在。

然后通過網(wǎng)關(guān)將流量逐步從老版本的服務(wù)切換到新版本的服務(wù)。這個逐步切換的過程就是常說的灰度發(fā)布。

此時，API 網(wǎng)關(guān)就起到了流量分發(fā)的作用，通常來說最開始的老版本會承載多一些的流量，例如 90% 的請求會被路由到老版本的服務(wù)上，只有 10% 的請求會路由到新服務(wù)上去。

從而觀察新服務(wù)的穩(wěn)定性，或者得到用戶的反饋。當(dāng)新服務(wù)穩(wěn)定以后，再將剩下的流量一起導(dǎo)入過去。

圖 6：灰度發(fā)布，路由到新/老服務(wù)

如下代碼所示，假設(shè) API 網(wǎng)關(guān)還是采用 8080 端口，需要針對兩個不同的服務(wù)配置路由權(quán)重。因此在 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

在兩個配置中對應(yīng)的 URI 分別是新老兩個服務(wù)的訪問地址，通過“http://localhost:8888/v1”和“http://localhost:8888/v2”來區(qū)別。

在 Predicates(斷言)中定義了的 Path 是想通的都是“/gatewaytest”，也就是說對于客戶端來說訪問的路徑都是一樣的，從路徑上客戶不會感知他們訪問的是新服務(wù)或者是老服務(wù)。

主要參數(shù)是在 Weight，針對老/新服務(wù)分別配置的是 90 和 10。也就是有 90% 的流量會請求老服務(wù)，有 10% 的流量會請求新服務(wù)。

簡單點說，如果有 100 次請求，其中 90 次會請求 v1(老服務(wù))，另外的 10 次會請求 v2(新服務(wù))。

限流

當(dāng)服務(wù)在短時間內(nèi)迎來高并發(fā)，并發(fā)量超過服務(wù)承受的范圍就需要使用限流。例如：秒殺、搶購、下單服務(wù)。

通過請求限速或者對一個時間窗口內(nèi)的請求進(jìn)行限速來保護(hù)服務(wù)。當(dāng)達(dá)到限制速率則可以拒絕請求，返回錯誤代碼，或者定向到友好頁面。

一般的中間件都會有單機限流框架，支持兩種限流模式：

控制速率
控制并發(fā)

這里通過 Guava 中的 Bucket4j 來實現(xiàn)限流操作。按照慣例引入 Bucket4j 的依賴：

 
 
 
   
  
  
     
  
  
      com.github.vladimir-bukhtoyarov   
  
  
      bucket4j-core   
  
  
      4.0.0

由于需要對于用戶請求進(jìn)行監(jiān)控，因此通過實現(xiàn) GatewayFilter 的方式自定義 Filter，然后再通過 Gateway API Application 應(yīng)用這個自定義的 Filter。

這里我們使用的是令牌桶的方式進(jìn)行限流，因此需要設(shè)置桶的容量(capacity)，每次填充的令牌數(shù)量(refillTokens)以及填充令牌的間隔時間(refillDuration)。

初始化這三個參數(shù)以后，通過 createNewBucket 方法針對請求建立令牌桶(bucket)，在 Filter 方法中實現(xiàn)限流的主要邏輯。

通過 ServerWebExchange 獲取請求的上下文中的 IP 信息，針對 IP 建立對應(yīng)的令牌桶，這個 IP 與令牌桶的對應(yīng)關(guān)系放到了 LOCAL_CACHE 中。

每次請求經(jīng)過的時候通過 tryConsume(1) 方法消費一個令牌，直到?jīng)]有令牌的時候返回 HttpStatus.TOO_MANY_REQUESTS 的狀態(tài)碼(429)，此時網(wǎng)關(guān)直接返回請求次數(shù)太多，即便是再有請求進(jìn)來也不會路由到對應(yīng)的服務(wù)了。

只有等待下一個時間間隔，一定數(shù)量的令牌放到桶里的時候，請求拿到桶中的令牌才能再次請求服務(wù)。

 
 
 
   
  
  
  public class GatewayRateLimitFilterByIp implements GatewayFilter, Ordered {   
  
  
      private static final Map 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 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 生成令牌桶，并且定義了桶的大小、每次放入桶令牌的個數(shù)、放入令牌的間隔時間。

并且通過 Filter 方法重寫了過濾的邏輯，那么下面只需要將這個 Filter 應(yīng)用到 Spring Cloud Gateway 的規(guī)則上去就可以了。通過下面代碼定義網(wǎng)關(guān)的路由斷言和過濾器。

在 Filters 中新建一個上面代碼定義的過濾器，指定容量是 20，每兩秒放入令牌，每次放入一個令牌。

那么當(dāng)用戶訪問 rateLimit 路徑的時候就會根據(jù)客制化的 Filter 進(jìn)行限流。

 
 
 
   
  
  
  @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();   
  
  
  }

這里的限流只是給大家提供一種思路，通過實現(xiàn) GatewayFilter，重寫其中的 Filter 方法，加入對流量的控制代碼，然后在 Spring Cloud Gateway 中進(jìn)行應(yīng)用就可以了。

動態(tài)路由

由于 Spring Cloud Gateway 本身也是一個服務(wù)，一旦啟動以后路由配置就無法修改了。

無論是上面提到的編碼注入的方式還是配置的方式，如果需要修改都需要重新啟動服務(wù)。

如果回到 Spring Cloud Gateway 最初的定義，我們會發(fā)現(xiàn)每個用戶的請求都是通過 Route 訪問對應(yīng)的微服務(wù)，在 Route 中包括 Predicates 和 Filters 的定義。

只要實現(xiàn) Route 以及其包含的 Predicates 和 Filters 的定義，然后再提供一個 API 接口去更新這個定義就可以動態(tài)地修改路由信息了。

按照這個思路需要做以下幾步來實現(xiàn)：

①定義 Route、Predicates 和 Filters

其中 Predicates 和 Filters 包含在 Route 中。實際上就是 Route 實體的定義，針對 Route 進(jìn)行路由規(guī)則的配置。

 
 
 
   
  
  
  public class FilterDefinition {   
  
  
      //Filter Name   
  
  
      private String name;   
  
  
      //對應(yīng)的路由規(guī)則   
  
  
      private Map args = new LinkedHashMap<>();   
  
  
  }   
  
  
  public class PredicateDefinition {   
  
  
      //Predicate Name   
  
  
      private String name;   
  
  
      //對應(yīng)的斷言規(guī)則   
  
  
      private Map args = new LinkedHashMap<>();   
  
  
  }   
  
  
  public class RouteDefinition {   
  
  
      //斷言集合   
  
  
  private List predicates = new ArrayList<>();   
  
  
  //路由集合   
  
  
  private List< FilterDefinition > filters= new ArrayList<>();   
  
  
  //uri   
  
  
  private String uri;   
  
  
  //執(zhí)行次序   
  
  
  private int order = 0;   
  
  
  }

②實現(xiàn)路由規(guī)則的操作，包括添加，更新，刪除

有了路由的定義(Route，Predicates，F(xiàn)ilters)，然后再編寫針對路由定義的操作。

例如：添加路由，刪除路由，更新路由之類的。編寫 RouteServiceImpl 實現(xiàn) ApplicationEventPublisherAware。

主要需要 override 其中的 setApplicationEventPublisher 方法，這里會傳入 ApplicationEventPublisher 對象，通過這個對象發(fā)布路由定義的事件包括：add，update，delete。

貼出部分代碼如下：

 
 
 
   
  
  
  @Service   
  
  
  public class RouteServiceImpl implements ApplicationEventPublisherAware {   
  
  
      @Autowired   
  
  
      private RouteDefinitionWriter routeDefinitionWriter;   
  
  
      private ApplicationEventPublisher publisher;   
  
  
      //添加路由規(guī)則   
  
  
      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 接口能夠讓用戶或者程序動態(tài)修改路由規(guī)則

從代碼上來說就是一個 Controller。這個 Controller 中只需要調(diào)用 routeServiceImpl 就行了，主要也是用到客制化路由實現(xiàn)類中的 add，update，delete 方法。

說白了就是對其進(jìn)行了一次包裝，讓外部系統(tǒng)可以調(diào)用，并且修改路由的配置。

經(jīng)過簡化以后的代碼如下，這里只對 add 方法進(jìn)行了包裝，關(guān)于 update 和 delete 方法在這里不展開說明，調(diào)用方式類似 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";   
  
  
      }   
  
  
  }

④啟動程序進(jìn)行路由的添加和更新操作

假設(shè)更新 API 網(wǎng)關(guān)配置的服務(wù)在 8888 端口上。于是通過 http://localhost:8888/actuator/gateway/routes 訪問當(dāng)前的路由信息，由于現(xiàn)在沒有配置路由這個信息是空。

那么通過 http://localhost:8888/route/add 方式添加一條路由規(guī)則，這里選擇 Post 請求，輸入類型為 Json 如下：

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

Json 中配置的內(nèi)容和簡單路由配置的內(nèi)容非常相似。設(shè)置了 Route，當(dāng) Predicates 為 baidu 的時候，將請求引導(dǎo)到 www.baidu.com 的網(wǎng)站進(jìn)行響應(yīng)。

此時再通過訪問 http://localhost:8888/baidu 的路徑訪問的時候，就會被路由到 www.baidu.com 的網(wǎng)站。

此時如果需要修改路由配置，可以通過訪問 http://localhost:8888/route/update 的 API 接口，通過 Post 方式傳入 Json 結(jié)構(gòu)，例如：

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

在更新完成以后，再訪問 http://localhost:8888/CTO 的時候就會把引導(dǎo)到 www..com 的網(wǎng)站了。

通過上面四步操作，即使不重啟 Spring Cloud Gateway 服務(wù)也可以動態(tài)更改路由的配置信息。

總結(jié)

由于微服務(wù)的盛行，API 網(wǎng)關(guān)悄然興起。針對 API 網(wǎng)關(guān)本身講述了其存在的原因，它不僅提供了服務(wù)的門面，而且可以協(xié)調(diào)不同的系統(tǒng)之間的通訊以及服務(wù)不同的客戶端接口。

針對 API 網(wǎng)關(guān)的最佳時間 Spring Cloud Gateway 的定義和概念的解釋，其實現(xiàn)了路由、過濾器、斷言，針對不同的客戶端請求可以路由到不同的微服務(wù)，以及其中幾個組件是如何分工合作完成路由工作的。

在最佳實踐的介紹中分別從：基本路由、權(quán)重路由、限流和動態(tài)路由幾個方面進(jìn)行了闡述。

【原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為.com】

分享標(biāo)題：我去，你竟然還不會用API網(wǎng)關(guān)！
本文來源：http://fisionsoft.com.cn/article/cdcjeco.html

新聞中心

其他資訊