引言：

Spring Cloud Gateway是當(dāng)前使用非常廣泛的一種API網(wǎng)關(guān)。它本身能力并不能完全滿足企業(yè)對網(wǎng)關(guān)的期望，人們希望它可以提供更多的服務(wù)治理能力。但Spring Cloud Gateway并不提供數(shù)據(jù)的動態(tài)管理，甚至修改個路由都需要重啟。我們?nèi)绾谓鉀Q它這個短板，同時實現(xiàn)治理配置數(shù)據(jù)的高效動態(tài)管理呢?本文將帶來我們網(wǎng)關(guān)與Redis組合的實踐。

[[274496]]

目錄：

1.Spring Cloud Gateway 簡介

2.網(wǎng)關(guān)數(shù)據(jù)管理

3.實現(xiàn)細節(jié)

1.Spring Cloud Gateway 簡介

API 網(wǎng)關(guān)

API 網(wǎng)關(guān)出現(xiàn)的原因是微服務(wù)架構(gòu)的出現(xiàn)，不同的微服務(wù)一般會有不同的網(wǎng)絡(luò)地址，而外部客戶端可能需要調(diào)用多個服務(wù)的接口才能完成一個業(yè)務(wù)需求，如果讓客戶端直接與各個微服務(wù)通信，會有以下的問題：

• 客戶端會多次請求不同的微服務(wù)，增加了客戶端的復(fù)雜性。
• 存在跨域請求，在一定場景下處理相對復(fù)雜。
• 認證復(fù)雜，每個服務(wù)都需要獨立認證。
• 難以重構(gòu)，隨著項目的迭代，可能需要重新劃分微服務(wù)。例如，可能將多個服務(wù)合并成一個或者將一個服務(wù)拆分成多個。如果客戶端直接與微服務(wù)通信，那么重構(gòu)將會很難實施。
• 某些微服務(wù)可能使用了防火墻 / 瀏覽器不友好的協(xié)議，直接訪問會有一定的困難。

以上這些問題可以借助 API 網(wǎng)關(guān)解決。API 網(wǎng)關(guān)是介于客戶端和服務(wù)器端之間的中間層，所有的外部請求都會先經(jīng)過 API 網(wǎng)關(guān)這一層。也就是說，API 的實現(xiàn)方面更多的考慮。 

使用 API 網(wǎng)關(guān)后的優(yōu)點如下：

• 易于監(jiān)控。可以在網(wǎng)關(guān)收集監(jiān)控數(shù)據(jù)并將其推送到外部系統(tǒng)進行分析。
• 易于認證?？梢栽诰W(wǎng)關(guān)上進行認證，然后再將請求轉(zhuǎn)發(fā)到后端的微服務(wù)，而無須在每個微服務(wù)中進行認證。
• 減少了客戶端與各個微服務(wù)之間的交互次數(shù)。

Spring Cloud Gateway

Spring Cloud Gateway是Spring官方基于Spring 5.0，Spring Boot 2.0和Project Reactor等技術(shù)開發(fā)的網(wǎng)關(guān)，Spring Cloud Gateway旨在為微服務(wù)架構(gòu)提供一種簡單而有效的統(tǒng)一的API路由管理方式。

Spring Cloud Gateway作為Spring Cloud生態(tài)系中的網(wǎng)關(guān)，目標(biāo)是替代Netflix ZUUL，其不僅提供統(tǒng)一的路由方式，并且基于Filter鏈的方式提供了網(wǎng)關(guān)基本的功能，例如：安全，監(jiān)控/埋點，和限流等。 

如圖所示，SCG的架構(gòu)看起來很簡單。

首先，它內(nèi)部包含了一個高性能的Netty Server，用來接收各類網(wǎng)絡(luò)請求。請求進來之后，會根據(jù)配置的各個路由進行匹配并處理請求。每個路由都可以定義多個斷言(Predicate)，用于路由匹配。

SCG默認提供了10多個內(nèi)建的斷言，可以基于請求的各個方面(請求頭，路徑，路徑，時間，Cookie，http方法等)進行路由匹配。如果還不夠，用戶還可以自已擴展。

請求匹配到了合適的路由之后，就會按照路由中配置的各過濾器(filter)，按順序?qū)φ埱筮M行處理。Filter也基本上可以對請求的所有屬性做處理，修改，添加或者除請求頭，修改請求數(shù)據(jù)，修改返回的數(shù)據(jù)等，幾乎無所不能。當(dāng)然，修改請求也只是一方面的用途，認證，鑒權(quán)，記錄日志等也都可以在網(wǎng)關(guān)中統(tǒng)一來做。

所有filter形成處理鏈，直到所有的filter處理完，才會交給最后面的 Netty Client，由它將處理過的請求發(fā)送至對應(yīng)的微服務(wù)。

在請求發(fā)送至微服務(wù)之前，還可以定義它的負載均衡策略(LoadBalancerRule)，以決定請求至底發(fā)往微服務(wù)的哪個實例。

Filter 與 LoadBalancerRule 都支持自行擴展。

2.網(wǎng)關(guān)數(shù)據(jù)管理

實現(xiàn)一個適合自已的網(wǎng)關(guān)，對數(shù)據(jù)管理需要考慮哪些方面的東西呢?

（1）首先，我們要考慮一下，我們需要管理些什么數(shù)據(jù)。

SCG本身對數(shù)據(jù)管理的管理是很弱的。它沒有提供數(shù)據(jù)的持久化方案，它所有的數(shù)據(jù)都來自初始化，來自它的配置文件(application.yml)。它本身雖然也對外提供了一些管理接口(Actuator API)能力不夠，但能力不夠，且這些修改都是暫時的，網(wǎng)關(guān)一停，數(shù)據(jù)就消失了。這就要求我們要用一套更完善的方案，把網(wǎng)關(guān)的這些數(shù)據(jù)管理起來，不能讓它只能寫在配置文件中，而要支持持久化，支持動態(tài)變更。再有就是我們對各微服務(wù)的治理數(shù)據(jù)。網(wǎng)關(guān)只用來做路由轉(zhuǎn)發(fā)，那就太浪費了，統(tǒng)一認證，統(tǒng)一鑒權(quán)，訪問日志記錄，應(yīng)用訪問統(tǒng)計，黑白名單過濾，API訂閱管理，流量限制，甚至數(shù)據(jù)格式轉(zhuǎn)換，網(wǎng)絡(luò)協(xié)議轉(zhuǎn)換，都可以在網(wǎng)關(guān)中來做。而所有的這些能力，無不需要數(shù)據(jù)的支持。因此，這些服務(wù)的治理配置，也是網(wǎng)關(guān)需要管理的數(shù)據(jù)。

（2）數(shù)據(jù)有了，我們還得考慮怎么把它保存起來，不能網(wǎng)關(guān)一重啟，所有數(shù)據(jù)就沒了。

（3）還得再考慮一下數(shù)據(jù)的讀取。網(wǎng)關(guān)對性能的要求是很高的，每次對過關(guān)的數(shù)據(jù)進行治理，都需要去讀取這些配置信息。如果配置信息讀取太消耗資源，無疑對網(wǎng)關(guān)是不利的。所以，我們還得考慮數(shù)據(jù)如何緩存，以提高數(shù)據(jù)的讀取性能。

（4）單個網(wǎng)關(guān)，可以處理的請求量是有上限的。為了應(yīng)對大的流量，我們可能會需要對網(wǎng)關(guān)做水平擴容。當(dāng)多個網(wǎng)關(guān)實例共存時，如何保障對網(wǎng)關(guān)的修改，能快速同步到每個網(wǎng)關(guān)實例呢?數(shù)據(jù)變更通知也得考慮。

（5）最多，我們還得考慮一下方案的擴展，數(shù)據(jù)存儲能不能改個地方，通知能不能換種方式?

綜合考慮了這些方面之后，我們的網(wǎng)關(guān)的架構(gòu)如下： 

如圖，以上就是我們網(wǎng)關(guān)的整體設(shè)計。方案設(shè)計要點如下：

• 網(wǎng)關(guān)對外提供治理數(shù)據(jù)管理接口, 微服務(wù)治理平臺可通過這些接口, 將治理配置推送到網(wǎng)關(guān)
• 網(wǎng)關(guān)通過治理數(shù)據(jù)統(tǒng)一存儲接口, 將治理配置數(shù)據(jù)保持至治理數(shù)據(jù)持久存儲(這里我們默認為Redis)
• Redis通過發(fā)布訂閱能力, 將數(shù)據(jù)的變更通知到各網(wǎng)關(guān)實例
• 各網(wǎng)關(guān)實例收到通知后, 將數(shù)據(jù)從持久存儲同步至內(nèi)部高速緩存
• 內(nèi)部緩存在網(wǎng)關(guān)啟動時, 會自動從持久存儲加載對應(yīng)配置進入緩存. 同時它也支持清空, 以及按需加載
• 外部業(yè)務(wù)請求經(jīng)過網(wǎng)關(guān)時, 對數(shù)據(jù)執(zhí)行鑒權(quán),處理轉(zhuǎn)換, 以及灰度策略時,所需要治理配置,都從內(nèi)部緩存中獲取, 以提升性能
• 方案中, 外部持久存儲(默認用的Redis, 可以換成Mysql, 文件, Appolo等), 以及數(shù)據(jù)變更通知(默認使用的是Redis的發(fā)布訂閱, 可以換成Appolo通知, 消息隊列, 定時掃描等), 都是可以擴展的

3.實現(xiàn)細節(jié)

動態(tài)路由管理

Spring Cloud Gateway作為所有請求流量的入口，在實際生產(chǎn)環(huán)境中為了保證高可靠和高可用，盡量避免重啟, 需要實現(xiàn)Spring Cloud Gateway動態(tài)路由配置。實現(xiàn)動態(tài)路由其實很簡單, 重點在于 RouteDefinitionRepository 這個接口. 這個接口繼承自兩個接口, 其中 RouteDefinitionLocator 是用來加載路由的. 它有很多實現(xiàn)類，其中的 PropertiesRouteDefinitionLocator 就用來實現(xiàn)從yml中加載路由。另一個 RouteDefinitionWriter 用來實現(xiàn)路由的添加與刪除。通過查看spring cloud gateway的源碼可以發(fā)現(xiàn), 在 org.springframework.cloud.gateway.config.GatewayAutoConfiguration中這么一段： 

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

可以看出, 網(wǎng)關(guān)中如果沒有RouteDefinitionRepository的Bean, 就會采用InMemoryRouteDefinitionRepository做為實現(xiàn)。這個 InMemoryRouteDefinitionRepository有一個問題, 就是數(shù)據(jù)沒有持久化, 網(wǎng)關(guān)重啟之后,原來通過接口設(shè)置的路由就會丟失了。

這當(dāng)然是不可接受的, 所以我們需要實現(xiàn)自已的 RouteDefinitionRepository, 來提供路由配置信息。如使用redis做為存儲, 來實現(xiàn)路由的存儲。實現(xiàn)請參考文章：https://dwz.cn/tsHfKwMe

除此以外, 每當(dāng)路由更改之后, 還需要通知網(wǎng)關(guān)刷新路由。這需要發(fā)送 RefreshRoutesEvent 來通知網(wǎng)關(guān)。如下列示例： 

@Component 
public class RouteDynamicService implements ApplicationEventPublisherAware { 
    private ApplicationEventPublisher publisher; 
 
    @Override 
    public void setApplicationEventPublisher(ApplicationEventPublisher publisher) { 
      this.publisher = publisher; 
    } 
 
    /** 
    * 刷新路由表 
    */ 
    public void refreshRoutes() { 
      publisher.publishEvent(new RefreshRoutesEvent(this)); 
    } 
} 

刷新可以通過消息通知機制來觸發(fā), 當(dāng)然, 也可以對外接供rest接口, 手動觸發(fā)。

數(shù)據(jù)存儲 

如上述類圖所示, IGovernDataRepository為治理數(shù)據(jù)統(tǒng)一存儲接口。RedisGovernDataRepository為實現(xiàn)的它的抽像類, 它需要依賴兩個, 一個是StringRedisTemplate，用來實現(xiàn)redis數(shù)據(jù)的存儲。另一個為 RedisKeyGenerator, 用來為各治理對象生成對應(yīng)的key。RedisGovernDataRepository下面則為各個治理數(shù)據(jù)存儲的實現(xiàn)類。使用Redis做為持久存儲時, 需要注意以下幾點:

• 為對象生成key時, 建議為key添加一個命名空間(就是加一段有意義的前綴)
• 在redis中進行模糊搜索時, 提供給Redis的pattern, 不能是一個正則的通配, 它支持三種通配 *(多個), ?(單個)
• 如果數(shù)據(jù)量比較大, 不建議使用keys進行模糊查詢, 應(yīng)該使用scan方式

數(shù)據(jù)緩存

我們提供了內(nèi)部緩存，它處于使用者與持久存儲之間，緩存數(shù)據(jù)以提升性能。緩存的實現(xiàn)主要有如下幾點：

1. 實現(xiàn)了 InitializingBean 以實現(xiàn)在網(wǎng)關(guān)啟動時, 自動加載數(shù)據(jù)
2. 內(nèi)部使用了ConcurrentHashMap, 保證寫時的線程同步, 又保證了get時的高效(get整個過程不需要加鎖)
3. 從緩存中取數(shù)據(jù)時, 如果需要懶加載, 當(dāng)從持久存儲中加載不到數(shù)據(jù)時, 建議使用空數(shù)據(jù), 或空集合占位, 避免每次都去持久存儲中查詢

代碼示例如下： 

/** 
  * 根據(jù) appCode 獲取流量策略 
  *  
  * @param appCode 
  * @return 
  */ 
public Set<ApplicationTrafficPolicy> getAppTrafficPolicies(String appCode) { 
  // 從緩存加載 
  Map<String, ApplicationTrafficPolicy> map = policyMap.get(appCode); 
  // 緩存中沒有 
  if (map == null) { 
    // 嘗試從持久存儲中加載所有此網(wǎng)關(guān)的流量策略 
    Set<ApplicationTrafficPolicy> policies = trafficPolicyRepository.fuzzyQuery(); 
    // 持久存儲中沒有任何流量策略，占個位置，防止緩存重復(fù)去加載 
    if (policies == null || policies.size() == 0) { 
      map = new ConcurrentHashMap<>(); 
      policyMap.put(appCode, map); 
    } else { 
      // 持久存儲中有流量策略，放入緩存 
      for (ApplicationTrafficPolicy policy : policies) { 
        setTrafficPolicy(policy); 
      } 
      // 重新從緩存中加載一次 
      map = policyMap.get(appCode); 
      // 如果還是沒有，使用空 map 占位子 
      if (map == null) { 
        map = new ConcurrentHashMap<>(); 
        policyMap.put(appCode, map); 
      } 
    } 
  } 
  return map.values().stream().collect(Collectors.toSet()); 
} 

事件通知

事件通知，這里我們使用的是redis的發(fā)布與訂閱能力。Redis默認是不發(fā)送事件的，要讓它發(fā)布事件，需要先修改它的配置文件redis.conf，添加一個配置： 

notify-keyspace-events "K$g" 

上面的配置將使得Redis中發(fā)生數(shù)據(jù)的添加，修改或刪除時，發(fā)送set或del事件。

然后，我們需要配置一個RedisMessageListenerContainer，用來訂閱我們感興趣的事件。 

@Bean 
RedisMessageListenerContainer container(MessageListenerAdapter listenerAdapter) { 
  String gtwReidsPattern = "__keyspace@*__:" + GTW + keyGenerator.getGatewayCode() + "]*"; 
  String cofRedisPattern = "__keyspace@*__:" + COF + cacheKey.getKeyNameSpace() + USER_NAME + "*"; 
  log.info("Add gateway redis message listener, patternTopic is {}", gtwReidsPattern); 
  log.info("Add coframe redis message listener, patternTopic is {}", cofRedisPattern); 
  RedisMessageListenerContainer container = new RedisMessageListenerContainer(); 
  container.setConnectionFactory(redisTemplate.getConnectionFactory()); 
  // PatternTopic 參考：http://redisdoc.com/topic/notification.html 
  container.addMessageListener(listenerAdapter, Arrays.asList(new PatternTopic(PatternUtil.fmt(gtwReidsPattern)), new PatternTopic(PatternUtil.fmt(cofRedisPattern)))); 
  return container; 
} 
當(dāng)redis事件訂閱好了之后, 每次其中我們關(guān)心的數(shù)據(jù)有變更, 都會發(fā)送set或del事件. 
我們需要定義一個 MessageListener, 來接收事件: 
@Service(value = RedisMessageListener.REDIS_LISTENER_NAME) 
public class RedisMessageListener implements MessageListener { 
  @Override 
  public void onMessage(Message message, byte[] pattern) { 
    String ops = new String(message.getBody()); 
    String channel = new String(message.getChannel()); 
    String key = channel.split(":")[1]; 
 
    if ("set".equals(ops)) { 
      String value = redisTemplate.opsForValue().get(key); 
      handleSet(key, value); 
    } else if ("del".equals(ops)) { 
      handleDel(key); 
    } 
  } 
  ... 
} 

接收到事件后，會調(diào)用相應(yīng)的內(nèi)部緩存，更新內(nèi)部緩存中的數(shù)據(jù)，以實現(xiàn)治理數(shù)據(jù)變更的及時生效。

作者：

將曉漁，現(xiàn)任普元云計算架構(gòu)師。曾在PDM，云計算，數(shù)據(jù)備份，移動互聯(lián)相關(guān)領(lǐng)域公司工作，十年以上IT工作經(jīng)驗。曾為科企桌面虛擬化產(chǎn)品的核心工程師，愛數(shù)容災(zāi)備份云柜系統(tǒng)設(shè)計師，萬達信息的食安管理與追溯平臺開發(fā)經(jīng)理。國內(nèi)IAAS云計算的早期實踐者，容器技術(shù)專家。