一、什么是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ù)需求，這個時候系統(tǒng)結(jié)構(gòu)會顯得非常錯綜復雜，會出現(xiàn)許多問題：

• 客戶端復雜性增加，現(xiàn)在一般同一套后端服務(wù)會支撐多個客戶端
• 存在跨域請求，在一定場景下處理相對復雜
• 認證復雜，每個服務(wù)都需要單獨驗證
• 耦合度高，難以重構(gòu)
• 某些微服務(wù)會存在防火墻等一些保護措施，無法直接訪問

微服務(wù)網(wǎng)關(guān)是微服務(wù)架構(gòu)中的一個關(guān)鍵角色，用來保護，增強和控制對于微服務(wù)的訪問，微服務(wù)網(wǎng)關(guān)是一個處于應用程序或服務(wù)之前的系統(tǒng)，用來管理授權(quán)，訪問控制和流量限制等，這樣微服務(wù)就會被微服務(wù)網(wǎng)關(guān)保護起來對所有的調(diào)用者透明。因此，隱藏在微服務(wù)網(wǎng)關(guān)后面的業(yè)務(wù)系統(tǒng)就可以更加專注于業(yè)務(wù)本身。

組成：

• 路由轉(zhuǎn)發(fā)：接受外界請求，轉(zhuǎn)發(fā)到后端微服務(wù)
• 過濾器：完成一系列橫切功能，例如權(quán)限校驗，限流以及監(jiān)控等

優(yōu)點：

• 安全性高，只有網(wǎng)關(guān)系統(tǒng)對外進行暴露，微服務(wù)可以隱藏在內(nèi)網(wǎng)，通過防火墻策略保護
• 易于監(jiān)控，可以在網(wǎng)關(guān)收集監(jiān)控數(shù)據(jù)并將其推送到外部監(jiān)控系統(tǒng)進行分析
• 易于認證，可以在網(wǎng)關(guān)處統(tǒng)一進行認證，無需在后端微服務(wù)中進行認證
• 減少耦合，避免多個客戶端與后端微服務(wù)之間的交互次數(shù)
• 易于鑒權(quán)，在網(wǎng)關(guān)處統(tǒng)一鑒權(quán)

職能：

• 請求接入，作為所有API接口服務(wù)請求的接入點
• 業(yè)務(wù)聚合，作為所有后端業(yè)務(wù)服務(wù)的聚合點
• 中介策略，實現(xiàn)安全，驗證，路由，過濾，流控等策略
• 統(tǒng)一管理，對所有API服務(wù)和策略進行統(tǒng)一管理

二、微服務(wù)網(wǎng)關(guān)常見技術(shù)

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

2.1    gateway是什么

Spring Cloud Gateway旨在為微服務(wù)架構(gòu)提供一種簡單而有效的統(tǒng)一的API路由管理方式。Spring Cloud Gateway作為Spring Cloud生態(tài)系中的網(wǎng)關(guān)，目標是替代Zuul，其不僅提供統(tǒng)一的路由方式，并且基于Filter鏈的方式提供了網(wǎng)關(guān)基本的功能，例如：安全，監(jiān)控/埋點，和限流等。

幾個概念

• Route（路由）：這是網(wǎng)關(guān)的基本構(gòu)建塊。它由一個ID，一個目標URI，一組斷言和過濾器定義。如果斷言為真，則路由匹配成功。
• Predicate（斷言）：輸入類型是一個ServerWebExchange。我們可以使用它來匹配來自HTTP請求的任何內(nèi)容，例如headers或參數(shù)。
• Filter（過濾器）：Gateway中的Filter分為兩種類型的filter，分別是gateway filter和global filter，過濾器會對請求和響應作處理。

2.2gateway怎么用

說到底predicate就是為了實現(xiàn)一組匹配規(guī)則，方便讓請求過來找到對應的Route進行處理，而spring cloud gateway內(nèi)置了幾種predicate的使用。

1、通過時間匹配

Predicate 支持設(shè)置一個時間，在請求進行轉(zhuǎn)發(fā)的時候，可以通過判斷在這個時間之前或者之后進行轉(zhuǎn)發(fā)。比如我們現(xiàn)在設(shè)置只有在 2018 年 1 月 20 日才會轉(zhuǎn)發(fā)到我的網(wǎng)站，在這之前不進行轉(zhuǎn)發(fā)，我就可以這樣配置：

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

2、通過cookie匹配

Cookie Route Predicate 可以接收兩個參數(shù)，一個是 Cookie name , 一個是正則表達式，路由規(guī)則會通過獲取對應的 Cookie name 值和正則表達式去匹配，如果匹配上就會執(zhí)行路由，如果沒有匹配上則不執(zhí)行。

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

3、通過請求路徑匹配

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

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

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

當然內(nèi)置的匹配規(guī)則還有很多，通過請求參數(shù)，請求方式，請求IP地址等去匹配，也可以組合使用。

注意：

一個請求滿足多個路由的謂詞條件時，請求只會被首個成功匹配的路由轉(zhuǎn)發(fā)

本次提測版本，開發(fā)使用spring-cloud-gateway來將平臺業(yè)務(wù)側(cè)引入網(wǎng)關(guān)， 將網(wǎng)關(guān)作為調(diào)用PaaS的唯一入口，便于維護，同時利用網(wǎng)關(guān)的能力實現(xiàn)限流，熔斷，鑒權(quán)，灰度驗證等功能。第一期只接入統(tǒng)一前裝，充分驗證后后續(xù)接入其他應用。因此，本次測試的重點在路由轉(zhuǎn)發(fā)功能。

三、常見測試點

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/

知道了網(wǎng)關(guān)的基礎(chǔ)知識和基本原理之后，對于我們?nèi)绾螠y試它，作為一名測試人員心中已經(jīng)有了大概的思路，接下來就是根據(jù)我們實際的需求去列出測試點，并進一步轉(zhuǎn)換為用例去執(zhí)行。從上面開發(fā)給出的配置能知道，此次開發(fā)提測主要是實現(xiàn)了基于路徑匹配的路由轉(zhuǎn)發(fā)功能，其余功能暫未引入，這樣想來就簡單了許多。

3.1功能測試

常見請求正常轉(zhuǎn)發(fā)

• get請求正常轉(zhuǎn)發(fā)：帶參數(shù)與不帶參數(shù)
• post請求正常轉(zhuǎn)發(fā)：數(shù)據(jù)格式校驗，例如json，form等
• delete請求正常轉(zhuǎn)發(fā)：帶參數(shù)與路徑帶參
• put請求正常轉(zhuǎn)發(fā)：數(shù)據(jù)格式校驗，例如json，form等
• patch請求正常轉(zhuǎn)發(fā)：數(shù)據(jù)格式校驗，例如json，form等
• 接口超時測試：具體的邊界值測試需根據(jù)自身業(yè)務(wù)需求場景來設(shè)計case
• 文件上傳功能：大小限制，亂碼問題，格式問題
• 路由規(guī)則：根據(jù)項目需求的不同規(guī)則來制定，例如全量匹配，正則，先后順序等
• 負載策略：輪詢，權(quán)重等
• 超時設(shè)置

3.2插件測試

API網(wǎng)關(guān)插件各個公司根據(jù)不同的需求有不同的插件，此次提測也沒有涉及，所以收集整理了一些常見的通用插件，例如降級，限流，熔斷，跨域，abtest插件等，提供一些測試思路。

限流

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

限流插件測試思路：可以在API網(wǎng)關(guān)平臺為對應測試接口配置限流策略。根據(jù)不同時間，使用壓測工具進行階段性的壓力測試，并統(tǒng)計阻斷接口數(shù)，具體的數(shù)值可以根據(jù)自身業(yè)務(wù)場景進行測試。

降級

基本概念：服務(wù)降級是指當服務(wù)器壓力劇增的情況下，根據(jù)實際業(yè)務(wù)情況，將一些不重要的接口換種簡單的方式處理，從而將服務(wù)器資源釋放給當前的核心業(yè)務(wù)使其可以高效運作。

降級插件測試思路：降級策略主要看開發(fā)如何選擇，有的就是讓請求無法訪問到后端服務(wù)，借口暫停使用，當接口配置降級插件。插件開關(guān)打開，返回API網(wǎng)關(guān)所配置的響應信息狀態(tài)碼等，接口是無法真正的請求到后端服務(wù)。

熔斷

基本概念： 微服務(wù)架構(gòu)中，各個微服務(wù)之間相互依賴非常普遍，因此在整個鏈路中 ，有一個環(huán)節(jié)出現(xiàn)問題，都會造成整個上下游服務(wù)調(diào)用出現(xiàn)問題，服務(wù)出現(xiàn)宕機。也就是說，熔斷就是調(diào)用方發(fā)起服務(wù)調(diào)用時，如果被調(diào)用方返回的錯誤率超過一定的閾值，那么后續(xù)的請求不會真正發(fā)起請求，而是調(diào)用方直接返回錯誤。兩個關(guān)鍵點，判斷何時熔斷和何時從熔斷狀態(tài)恢復。

熔斷插件測試思路： 不同的網(wǎng)關(guān)有不同的熔斷策略，例如針對5xx的返回，根據(jù)不同的入?yún)⒖刂品祷?，可返?xx，4xx，5xx，當規(guī)定的時間5xx數(shù)達到閾值，服務(wù)是否開啟熔斷。熔斷恢復測試也是一樣，比如10s，允許部分請求通過，你可以繼續(xù)控制請求，若這部分請求都成功，恢復熔斷。具體的case設(shè)計還是要根據(jù)自身業(yè)務(wù)為準。

跨域

基本概念： 跨域是指，只要協(xié)議，域名，端口有任何一個不相同，都被當作是不同的域。所謂同源策略就是指，協(xié)議，域名和端口都要相同，其中有一個不同都會產(chǎn)生跨域。

跨域測試思路： CORS是一種基于HTTP頭的機制，該機制通過允許服務(wù)器標識除了自己以外的其他origin，這樣瀏覽器可以訪問加載這些資源。瀏覽器必須首先使用OPTIONS方法發(fā)起一個預檢請求，從而獲知服務(wù)端是否允許該垮源請求。服務(wù)器允許之后，才發(fā)起實際的HTTP請求。在預檢請求的返回中，服務(wù)端也可以通知客戶端，是否需要攜帶身份憑證。測試時，我們就可以通過是否需要攜帶參數(shù)，身份憑證等；各種參數(shù)組合，不同請求等方面去設(shè)計case。

3.3容錯測試

• 數(shù)據(jù)庫宕機或者重啟：新發(fā)布的路由或者插件設(shè)置等數(shù)據(jù)操作可能失敗，但是不影響已生效的路由和插件
• 后端服務(wù)其中一臺或多臺宕機，重啟，添加新節(jié)點等：負載策略能夠自動提出不可用的服務(wù)節(jié)點和自動增加新的服務(wù)節(jié)點
• redis服務(wù)宕機一臺或多臺：不影響已生效路由和插件
• eureka掛一臺或多臺：不影響已生效負載策略

注意： 數(shù)據(jù)庫down,因為有本地緩存，驗證本地緩存是否生效，所以數(shù)據(jù)庫重啟或者down掉，不能影響已經(jīng)生效的路由和插件；后端服務(wù)down掉一臺，驗證eureka是否有將死掉的節(jié)點刪除，若eureka并沒有將死掉的節(jié)點刪除，則會報錯。添加新的節(jié)點，需要看請求是否有輪詢；redis主要用于限流，在redis down掉限流策略失效，但是其他插件功能及路由應該不受影響；eureka是注冊中心，注冊中心在啟動的時候會將所有資源加載本地，所以eureka掛一臺或者多臺，不影響已經(jīng)加載到本地的。總上所述，總結(jié)來說就是API網(wǎng)關(guān)的所有依賴都可以down，但是gateway不可以不用。

3.4壓力測試

• 正常壓測：壓API網(wǎng)關(guān)的API即可
• 負載測試：壓測時，增加和減少后端服務(wù)節(jié)點；某個服務(wù)資源打滿或者超時嚴重，不影響其他項目正常訪問
• 切換路由配置
• 項目資源測試：超過配置資源返回錯誤
• ...

注意： 項目資源的作用是進行線程隔離，每個項目資源分配應該是固定的，不能搶占其他項目資源而導致其他服務(wù)不可用，進行負載測試時，增加壓力，增加和減少后端服務(wù)節(jié)點，請求應該不報錯。

四、總結(jié)

上述內(nèi)容，是對一些網(wǎng)關(guān)通用功能的測試思路總結(jié)。由于本次開發(fā)提測網(wǎng)關(guān)版本并沒有涉及過多的功能，例如還有集群的熱加載，插件在集群項目與API間的運用，API的發(fā)布，下線，插件的隨時切換，監(jiān)控等需求，親身實踐還不夠，只能提供一些思路，還需要具體結(jié)合項目的業(yè)務(wù)進行更為準確的case設(shè)計。