普元EOS 8網關設計及應用

轉載本文需註明出處：EAWorld，違者必究。

引言：

普元EOS 8 API Gateway做爲一個獨立模塊，能夠對API進行建立、發佈、維護、監控等全生命週期管理。

目錄：

1、爲何引入EOS8網關
2、EOS 8網關的技術框架
3、API接入和監控示例

1、爲何引入EOS8網關



隨着微服務的熱度不斷上升，線上商業的發展和人們需求的擴增，企業中業務服務種類衆多，數量巨大，對如此規模的服務作升級、管理和維護，時間和資源成本的開銷不言而喻。API Gateway的價值隨之彰顯出來。與此同時對API Gateway的選擇也尤其重要。

統一的API管理、高併發請求全週期異步化、靈活的API適配是EOS 8 API Gateway的優點。

API Gateway 在各個模塊間如何運做？



上圖展現了EOS 8 API Gateway模塊間的進程視圖，方便咱們理解整個業務執行過程。

首先，須要將網關和後端應用註冊到Eureka（若是後端服務不是微服務，能夠忽略這一步）。

而後，在governor界面建立須要發佈的API，並配置相應的ip認證和流控配置，這些操做都會同步到Gateway Server的緩存。

最後，服務消費者系統須要在Governor訂閱API，得到網關頒發給調用方的token憑證（後面的版本會加入IAM受權），消費方系統拿到token憑證訪問已發佈的API，Gateway Server從Redis讀取緩存進行ip和流控校驗，從自身緩存中讀取token信息（後面版本鑑權由IAM完成）、API配置進行請求和API適配，各個EventHeadler都完成後，由Ribbon路由到Eureka註冊的應用（若是後端服務沒有註冊到Eureka，由異步的NioClient接出）。

2、EOS 8網關的技術框架

EOS8 網關部署拓撲架構



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

一、EOS 8 API Gateway能夠不依賴微服務架構中的註冊中心、配置中心進行單獨部署。整個生命週期中API鑑權、ip認證、流控、配置管理，協議數據轉換和調用日誌監控等功能依然具有。可是依賴註冊中心的服務路由、配置中心的統一配置API、監控/日誌中心的後端服務監控等功能會缺失。

二、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。

網關主要的技術框架：

網關使用了Oauth2鑑權技術（後續配合IAM作權限校驗）。
在java八、Spring4的大環境下，Spring Boot加大了開發效率。
嵌入了Jetty容器讓網關更輕，讓系統性能維持在一個可接受狀態。
使用了基於傳輸層的Netty框架，提供異步的、事件驅動的網絡應用程序框架，爲咱們核心框架分階段消息異步處理架構奠基基礎。

分階段消息異步處理



能夠將一次請求Api Gateway，並從API Gateway得到響應視爲整個流程。

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

段之間基於隊列/消息通訊。每一個業務Stage都有本身獨立的業務處理Event Handler、Event Queue和線程池，每一個階段之間沒有任何依賴，當前的Stage事件處理完成，封裝到Message中，而後派發到其餘Stage的Event Queue，直到整個Stage處理完成有Nio Client或者Ribbon Client接出。當Event queue吸納過量的負載，有限的線程池維持併發。

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

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

API Gateway 提供了統一的API管理



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

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

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

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

a、Api Gateway Server內部實現了協議擴展和消息轉換，根據需求在Governor管理頁面進行配置。
b、Server端的接出由Ribbon Client實現，可根據Eureka註冊的應用進行路由。
c、流控數據皆保存在Redis中，在有限的JVM資源下優先保障傳輸效率。
d、server附帶的普元自主研發的API Gateway Monitor，能夠輕鬆解析千萬級併發調用的日誌文件，爲governor呈現有效的API的調用詳情和調用趨勢。
e、API Gateway可以使用F5或者Nginx進行橫向擴展，應對更大調用需求。
f、斷路器機制能夠有效的保護JVM主線程，爲傳輸安全提供保障。

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

3、API接入和監控示例

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

API註冊

建立後端應用



若是須要API Gateway動態路由到後端應用，須要將該應用服務註冊到Eureka，而後在Governor註冊。爲API註冊選擇後端服務時作好準備。

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



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

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



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

一共有四個基本配置：

一、「請求Path」是API的URI。
二、「HTTP Method」是http請求的方法。
三、「入參模式」分兩種：穿透和轉換，穿透與轉換的區別是前者網關在服務調用生命週期只作代理轉發，後者能夠對請求報文進行適配和轉換。
四、「報文類型」請求報文的數據類型，默認有：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個基本配置：

一、「後端協議」是請求後端服務的網絡協議（HTTPS協議將在下個版本加入）。
二、「服務地址」是後端服務的地址，若是部署架構中將網關獨立部署，這裏能夠選擇「手動輸入」配置後端服務，若是部署EOS8微服務架構，可選擇「應用」進行動態路由。
三、「HTTP Method」是請求後端服務的方法。
四、「超時時間」是後端服務響應的熔斷時間。
五、「後端請求Path」是後端服務請求的URI。
六、「報文類型」是請求後端服務的請求報文類型。

後端服務參數中，可根據參數位置配置參數路徑，如：在「後端請求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/EqEd8P8)

建立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自動解析完日誌後會產生監控數據，如上圖展現。

總結：

EOS 8 API Gateway有以上諸多優勢，更爲關鍵的是，兩種部署模式可以知足廣大用戶的不一樣需求。其消息異步處理機制和統一API管理等功能，必將吸引普遍的用戶體驗並獲得他們的青睞。而豐富的服務引擎也將會使API管理更加完善，給用戶以最優的開發體驗。

關於做者：李鋮，普元java開發工程師，負責ESB/BIIP/DSB的維護，參與普元EOS 8網關的開發，現階段進行ESB 6.7升級的研發工做。 

 

關於EAWorld：微服務，DevOps，數據治理，移動架構原創技術分享。長按二維碼關注！