EOS8 網關部署拓撲架構

EOS 8 API Gateway 有兩種部署模式。

1. EOS 8 API Gateway可以不依賴微服務架構中的注冊中心、配置中心進行單獨部署。整個生命周期中API鑒權、ip認證、流控、配置管理，協議數據轉換和調用日志監控等功能依然具備。但是依賴注冊中心的服務路由、配置中心的統一配置API、監控/日志中心的后端服務監控等功能會缺失。

2. EOS 8 API Gateway 作為微服務治理的重要成員，可依賴注冊中心、配置中心和監控/日志中心做微服務治理。

   a、將API Gateway、后端應用注冊到注冊中心。當配置需要管理的API時，可選擇注冊中心的應用，亦可手動輸入后端服務地址。

   b、在配置中心可以對網關API進行統一配置，譬如：統一配置請求頭響應頭、統一請求參數響應參數等。

   c、監控/日志中心可以監控注冊到注冊中心的后端服務調用和資源使用情況。

管理門戶（Governor）是EOS 8微服務架構中服務治理和資產管理的門戶，由管理員頁面操作，進行API配置發布、API分組管理、黑白名單配置、流控配置、系統/應用注冊、統一配置等操作，不過上述的功能的接口都有詳細的swagger文檔，可以根據需求自行擴展。

API_Gateway_Monitor是網關自帶的日志解析組件。網關現支持Mysql、Oracle、PG數據庫，Redis存放流控數據。

EOS8 網關部署拓撲架構主要技術

注冊中心使用Spring Cloud Eureka，配置中心使用Ctrip Apollo。

網關主要的技術框架：

1. 網關使用了Oauth3鑒權技術（后續配合IAM做權限校驗）。

2. 在java8、Spring4的大環境下，Spring Boot加大了開發效率。

3. 嵌入了Jetty容器讓網關更輕，讓系統性能維持在一個可接受狀態。

4. 使用了基于傳輸層的Netty框架，提供異步的、事件驅動的網絡應用程序框架，為我們核心框架分階段消息異步處理架構奠定基礎。

分階段消息異步處理

可以將一次請求Api Gateway，并從API Gateway獲得響應視為整個流程。

1. 邏輯分段。將整個流程劃分成：請求接入/響應接出、代理服務處理、業務服務處理、請求接出/響應接入四個業務Stage。

2. 段之間基于隊列/消息通信。每個業務Stage都有自己獨立的業務處理Event Handler、Event Queue和線程池，每個階段之間沒有任何依賴，當前的Stage事件處理完成，封裝到Message中，然后派發到其他Stage的Event Queue，直到整個Stage處理完成有Nio Client或者Ribbon Client接出。當Event queue吸納過量的負載，有限的線程池維持并發。

3. Stage控制器負責資源的分配和調度，控制派發給Event Handler的事件的數量和順序，Event Handler可能在內部丟棄、過濾、重排序事件。

分階段消息異步處理架構實現了EOS 8網關高并發請求全周期異步化。

API Gateway 提供了統一的API管理

EOS 8 API Gateway從功能層面提供了統一的API管理。

首先，具有多協議接入和接出，例如HTTP協議、REST協議、WS協議等，發布出來的API可供企業內部系統、第三方應用系統和前端研發人員調用。

其次，在服務接入層，實現了權限認證、IP認證和用戶名密碼認證，再加上可靠的流控機制保障了通過網關的傳輸安全。

最后，Api Gateway Server服務引擎有以下幾個內容：

1. Api Gateway Server內部實現了協議擴展和消息轉換，根據需求在Governor管理頁面進行配置。

2. Server端的接出由Ribbon Client實現，可根據Eureka注冊的應用進行路由。

3. 流控數據皆保存在Redis中，在有限的JVM資源下優先保障傳輸效率。

4. server附帶的普元自主研發的API Gateway Monitor，可以輕松解析千萬級并發調用的日志文件，為governor呈現有效的API的調用詳情和調用趨勢。

5. API Gateway可使用F5或者Nginx進行橫向擴展，應對更大調用需求。

6. 斷路器機制可以有效的保護JVM主線程，為傳輸安全提供保障。

豐富的服務引擎使API管理更加完善。

如何使用EOS 8網關？用EOS 8網關如何注冊和發布一個API？服務消費者系統又如何根據token調用已發布的網關？

API注冊

創建后端應用

如果需要API Gateway動態路由到后端應用，需要將該應用服務注冊到Eureka，然后在Governor注冊。為API注冊選擇后端服務時做好準備。

創建API第一步（配置基本信息）

創建API第一步配置基本信息，對需要注冊的API進行定義分組、協議、名稱的配置。

創建API第二步（配置API接入【協議/數據轉換】）

創建API第二步，配置API接入，當外部系統調用網關發布的API時涉及到的配置。

一共有四個基本配置：

1. “請求Path”是API的URI。

2. “HTTP Method”是http請求的方法。

3. “入參模式”分兩種：穿透和轉換，穿透與轉換的區別是前者網關在服務調用生命周期只做代理轉發，后者可以對請求報文進行適配和轉換。

4. “報文類型”請求報文的數據類型，默認有：JSON、XML、FORM表單，如有其他需求，可在數據字典擴展。

本次示例是http穿透，路徑參數 ”num1“加入了參數列表，參數列表中定義過的參數皆可在后端服務的Path、Header、Body中使用。

在系統對接過程，常見的API適配有json轉json、xml轉json、json轉xml。

在EOS8 API Gateway中，無論請求方的報文是什么格式的，只要能在請求的Path、Header或者Body中提取出后端服務請求所需的報文數據，便可重構后端服務請求報文。

如圖所示，在入參定義中，當提取HTTP報文體，”參數路徑“是根據報文類型而選擇，當請求報文是JSON格式，用“$.*”JSONPath提取參數，當報文是XML格式，就用“/*/*”XPath提取參數。

將請求報文的關鍵數據都提取出來保存到參數列表中，待后端服務配置使用。

創建API第三步（配置API后端服務）

創建API第三步，配置API后端服務。

一共有6個基本配置：

1. “后端協議”是請求后端服務的網絡協議（HTTPS協議將在下個版本加入）。

2. “服務地址”是后端服務的地址，如果部署架構中將網關獨立部署，這里可以選擇“手動輸入”配置后端服務，如果部署EOS8微服務架構，可選擇“應用”進行動態路由。

3. “HTTP Method”是請求后端服務的方法。

4. “超時時間”是后端服務響應的熔斷時間。

5. “后端請求Path”是后端服務請求的URI。

6. “報文類型”是請求后端服務的請求報文類型。

后端服務參數中，可根據參數位置配置參數路徑，如：在“后端請求Path””/json/library/book/{library}”路徑中，library可作為參數路徑變量，在參數列表中找到對應的參數進行賦值。

對于后端服務報文的重構，根據已知的后端服務請求報文格式，使用了VTL語言重構，使用參數列表中的參數對重構報文的value進行賦值。VTL重構的報文示例：

{
"id":"$ReqBody_Did.asText()",
"name":"$ReqBody_Dname.asText()",
"isbn":"$ReqBody_Disbn.asText()",
"author":"$ReqBody_Dauthor.asText()",
"price":$ReqBody_Dprice.asText()
}

關于VTL腳本語言更多介紹請參考(http://t.cn/EGsgPrP)

創建API第四步（響應結果配置）

創建API第四步，響應結果配置。

• “返回ContentType”配置后端服務響應的報文類型。

• “錯誤碼定義”可以自定義后端服務非正常響應。

到這里，一個完整的實現了報文轉換的API注冊成功，接下來介紹剛注冊好的API如何添加策略配置。

API策略配置

ip配置

首先創建黑白名單策略，“控制類型”可選擇黑名單或者白名單，“IP列表”可用正則表達式定義，然后在剛剛創建好的白名單策略上綁定API，綁定成功則白名單策略生效。

調用數配置

首先創建調用數控制策略，配置單位時間內的API被調用次數和單位時間內調用方的調用次數，然后在剛剛創建好的調用數策略上綁定API，綁定成功則調用數策略生效。

接下來開始介紹如何調用API。

調用API

API發布

API處于“已發布”狀態才能被調用。

創建調用方系統

首先創建調用方系統。

調用方系統訂閱API

然后調用方系統訂閱API。

獲取網關頒發給調用方系統的憑證token

訂閱完成后，網關會頒發一個令牌，調用系統想要調用剛才訂閱的API需要傳這個令牌做認證。

調用系統調用訂閱后的API

請求已發布的API，將剛剛獲取的令牌放入“access_token”請求頭中，在IP策略和調用數策略允許范圍內，調用成功。

多調用幾次后，監控調用詳情。

API調用監控

剛才調用后，API Gateway Server會產生日志文件，API_Gateway_Monitor自動解析完日志后會產生監控數據，如上圖展示。