測試開發：從0到1學習如何測試API網關

本文來自一名學員的分享nginx

平常工做中，不免會遇到臨危受命的狀況，雖然沒有這麼誇張，可是也可能會接到一個陌生的任務，也許只是對這個概念有所耳聞。也許這個時候會感到一絲的焦慮，生怕無法完成領導交給的測試任務。其實也沒有必要那麼緊張，面對一個陌生的被測對象，咱們只須要去了解清楚它的應用場景、內部原理、實現邏輯，結合開發的設計需求，同樣也能完成好測試任務，積累經驗。此次就分享一些從0到1學習如何測試API網關的經驗。web

1、什麼是API網關

簡述：

API網關出現的緣由是微服務架構的出現，不一樣的微服務通常會有不一樣的網絡地址，而外部的客戶端可能須要調用多個服務的接口才能完成一個業務需求，這個時候系統結構會顯得很是錯綜複雜，會出現許多問題：正則表達式

客戶端複雜性增長，如今通常同一套後端服務會支撐多個客戶端
存在跨域請求，在必定場景下處理相對複雜
認證複雜，每一個服務都須要單獨驗證
耦合度高，難以重構
某些微服務會存在防火牆等一些保護措施，沒法直接訪問

微服務網關是微服務架構中的一個關鍵角色，用來保護，加強和控制對於微服務的訪問，微服務網關是一個處於應用程序或服務以前的系統，用來管理受權，訪問控制和流量限制等，這樣微服務就會被微服務網關保護起來對全部的調用者透明。所以，隱藏在微服務網關後面的業務系統就能夠更加專一於業務自己。redis

組成：

路由轉發：接受外界請求，轉發到後端微服務
過濾器：完成一系列橫切功能，例如權限校驗，限流以及監控等

優勢：

安全性高，只有網關係統對外進行暴露，微服務能夠隱藏在內網，經過防火牆策略保護
易於監控，能夠在網關收集監控數據並將其推送到外部監控系統進行分析
易於認證，能夠在網關處統一進行認證，無需在後端微服務中進行認證
減小耦合，避免多個客戶端與後端微服務之間的交互次數
易於鑑權，在網關處統一鑑權

職能：

請求接入，做爲全部API接口服務請求的接入點
業務聚合，做爲全部後端業務服務的聚合點
中介策略，實現安全，驗證，路由，過濾，流控等策略
統一管理，對全部API服務和策略進行統一管理

2、微服務網關常見技術

nginx是一個高性能的HTTP和反向代理web服務器，同時也提供了IMAP/POP3/SMTP服務
zuul，Zuul是Netflix出品的一個基於JVM路由和服務端的負載均衡器
spring-cloud-gateway是spring出品的基於spring的網關項目，集成斷路器，路徑重寫等，性能比Zuul好

2.1 gateway是什麼

Spring Cloud Gateway旨在爲微服務架構提供一種簡單而有效的統一的API路由管理方式。Spring Cloud Gateway做爲Spring Cloud生態系中的網關，目標是替代Zuul，其不只提供統一的路由方式，而且基於Filter鏈的方式提供了網關基本的功能，例如：安全，監控/埋點，和限流等。spring

幾個概念

Route（路由）：這是網關的基本構建塊。它由一個ID，一個目標URI，一組斷言和過濾器定義。若是斷言爲真，則路由匹配成功。
Predicate（斷言）：輸入類型是一個ServerWebExchange。咱們可使用它來匹配來自HTTP請求的任何內容，例如headers或參數。
Filter（過濾器）：Gateway中的Filter分爲兩種類型的filter，分別是gateway filter和global filter，過濾器會對請求和響應做處理。

2.2 gateway怎麼用

說到底predicate就是爲了實現一組匹配規則，方便讓請求過來找到對應的Route進行處理，而spring cloud gateway內置了幾種predicate的使用。數據庫

一、經過時間匹配json

Predicate 支持設置一個時間，在請求進行轉發的時候，能夠經過判斷在這個時間以前或者以後進行轉發。好比咱們如今設置只有在 2018 年 1 月 20 日纔會轉發到個人網站，在這以前不進行轉發，我就能夠這樣配置：後端

spring:
  cloud:
    gateway:
      routes:
       - id: time_route
        uri: http://youknowit.com
        predicates:
         - After=2018-01-20T06:06:06+08:00[Asia/Shanghai]

二、經過cookie匹配跨域

Cookie Route Predicate 能夠接收兩個參數，一個是 Cookie name , 一個是正則表達式，路由規則會經過獲取對應的 Cookie name 值和正則表達式去匹配，若是匹配上就會執行路由，若是沒有匹配上則不執行。數組

spring:
  cloud:
    gateway:
      routes:
       - id: cookie_route
         uri: http://youknowit.com
         predicates:
         - Cookie=youknowit, value

三、經過請求路徑匹配

Path Route Predicate 接收一個匹配路徑的參數來判斷是否走路由。

spring:
  cloud:
    gateway:
      routes:
      - id: host_route
        uri: http://x.x.x.x:8022/
        predicates:
        - Path=/foo/{segment}

若是請求路徑符合要求，則此路由將匹配，例如：/foo/1或者/foo/bar。

固然內置的匹配規則還有不少，經過請求參數，請求方式，請求IP地址等去匹配，也能夠組合使用。

注意：

一個請求知足多個路由的謂詞條件時，請求只會被首個成功匹配的路由轉發

本次提測版本，開發使用spring-cloud-gateway來將平臺業務側引入網關，將網關做爲調用PaaS的惟一入口，便於維護，同時利用網關的能力實現限流，熔斷，鑑權，灰度驗證等功能。第一期只接入統一前裝，充分驗證後後續接入其餘應用。所以，本次測試的重點在路由轉發功能。

3、常見測試點

spring:
  cloud:
    gateway:
      httpclient:
        connect-timeout: 5000
        response-timeout: 5s
        ssl:
          close-notify-flush-timeout-millis: 3000
          close-notify-read-timeout-millis: 0
          handshake-timeout-millis: 10000
          useInsecureTrustManager: true
      routes:
        # gis
        - id: gis_route
          predicates:
            - Path=/gis/**
          uri: http://x.x.x.x:8022/

知道了網關的基礎知識和基本原理以後，對於咱們如何測試它，做爲一名測試人員心中已經有了大概的思路，接下來就是根據咱們實際的需求去列出測試點，並進一步轉換爲用例去執行。從上面開發給出的配置能知道，這次開發提測主要是實現了基於路徑匹配的路由轉發功能，其他功能暫未引入，這樣想來就簡單了許多。

3.1 功能測試

常見請求正常轉發

get請求正常轉發：帶參數與不帶參數
post請求正常轉發：數據格式校驗，例如json，form等
delete請求正常轉發：帶參數與路徑帶參
put請求正常轉發：數據格式校驗，例如json，form等
patch請求正常轉發：數據格式校驗，例如json，form等
接口超時測試：具體的邊界值測試需根據自身業務需求場景來設計case
文件上傳功能：大小限制，亂碼問題，格式問題
路由規則：根據項目需求的不一樣規則來制定，例如全量匹配，正則，前後順序等
負載策略：輪詢，權重等
超時設置

3.2 插件測試

API網關插件各個公司根據不一樣的需求有不一樣的插件，這次提測也沒有涉及，因此收集整理了一些常見的通用插件，例如降級，限流，熔斷，跨域，abtest插件等，提供一些測試思路。

限流

基本概念： 客戶端請求太多，超出了服務端的承受能力，致使服務端不可用或沒法響應，耗盡服務端資源甚至是服務崩潰。解決方案：服務端對客戶端進行限流，保護服務端資源。對各種請求設置最高的QPS閾值，當請求高於閾值時直接阻斷。

限流插件測試思路：能夠在API網關平臺爲對應測試接口配置限流策略。根據不一樣時間，使用壓測工具進行階段性的壓力測試，並統計阻斷接口數，具體的數值能夠根據自身業務場景進行測試。

降級

基本概念： 服務降級是指當服務器壓力劇增的狀況下，根據實際業務狀況，將一些不重要的接口換種簡單的方式處理，從而將服務器資源釋放給當前的核心業務使其能夠高效運做。

降級插件測試思路：降級策略主要看開發如何選擇，有的就是讓請求沒法訪問到後端服務，藉口暫停使用，當接口配置降級插件。插件開關打開，返回API網關所配置的響應信息狀態碼等，接口是沒法真正的請求到後端服務。

熔斷

基本概念： 微服務架構中，各個微服務之間相互依賴很是廣泛，所以在整個鏈路中，有一個環節出現問題，都會形成整個上下游服務調用出現問題，服務出現宕機。也就是說，熔斷就是調用方發起服務調用時，若是被調用方返回的錯誤率超過必定的閾值，那麼後續的請求不會真正發起請求，而是調用方直接返回錯誤。兩個關鍵點，判斷什麼時候熔斷和什麼時候從熔斷狀態恢復。

熔斷插件測試思路： 不一樣的網關有不一樣的熔斷策略，例如針對5xx的返回，根據不一樣的入參控制返回，可返回2xx，4xx，5xx，當規定的時間5xx數達到閾值，服務是否開啓熔斷。熔斷恢復測試也是同樣，好比10s，容許部分請求經過，你能夠繼續控制請求，若這部分請求都成功，恢復熔斷。具體的case設計仍是要根據自身業務爲準。

跨域

基本概念： 跨域是指，只要協議，域名，端口有任何一個不相同，都被看成是不一樣的域。所謂同源策略就是指，協議，域名和端口都要相同，其中有一個不一樣都會產生跨域。

跨域測試思路： CORS是一種基於HTTP頭的機制，該機制經過容許服務器標識除了本身之外的其餘origin，這樣瀏覽器能夠訪問加載這些資源。瀏覽器必須首先使用OPTIONS方法發起一個預檢請求，從而獲知服務端是否容許該垮源請求。服務器容許以後，才發起實際的HTTP請求。在預檢請求的返回中，服務端也能夠通知客戶端，是否須要攜帶身份憑證。測試時，咱們就能夠經過是否須要攜帶參數，身份憑證等；各類參數組合，不一樣請求等方面去設計case。

3.3 容錯測試

數據庫宕機或者重啓：新發布的路由或者插件設置等數據操做可能失敗，可是不影響已生效的路由和插件
後端服務其中一臺或多臺宕機，重啓，添加新節點等：負載策略可以自動提出不可用的服務節點和自動增長新的服務節點
redis服務宕機一臺或多臺：不影響已生效路由和插件
eureka掛一臺或多臺：不影響已生效負載策略

注意： 數據庫down,由於有本地緩存，驗證本地緩存是否生效，因此數據庫重啓或者down掉，不能影響已經生效的路由和插件；後端服務down掉一臺，驗證eureka是否有將死掉的節點刪除，若eureka並無將死掉的節點刪除，則會報錯。添加新的節點，須要看請求是否有輪詢；redis主要用於限流，在redis down掉限流策略失效，可是其餘插件功能及路由應該不受影響；eureka是註冊中心，註冊中心在啓動的時候會將全部資源加載本地，因此eureka掛一臺或者多臺，不影響已經加載到本地的。 總上所述，總結來講就是API網關的全部依賴均可以down，可是gateway不能夠不用。

3.4 壓力測試

正常壓測：壓API網關的API便可
負載測試：壓測時，增長和減小後端服務節點；某個服務資源打滿或者超時嚴重，不影響其餘項目正常訪問
切換路由配置
項目資源測試：超過配置資源返回錯誤
...

注意： 項目資源的做用是進行線程隔離，每一個項目資源分配應該是固定的，不能搶佔其餘項目資源而致使其餘服務不可用，進行負載測試時，增長壓力，增長和減小後端服務節點，請求應該不報錯。

4、總結

上述內容，是對一些網關通用功能的測試思路總結。因爲本次開發提測網關版本並無涉及過多的功能，例如還有集羣的熱加載，插件在集羣項目與API間的運用，API的發佈，下線，插件的隨時切換，監控等需求，親身實踐還不夠，只能提供一些思路，還須要具體結合項目的業務進行更爲準確的case設計。