普元EOS 8閘道器設計及應用

EAWorld發表於2019-01-15

普元EOS 8閘道器設計及應用

轉載本文需註明出處:微信公眾號EAWorld,違者必究。


引言:

普元EOS 8 API Gateway作為一個獨立模組,可以對API進行建立、釋出、維護、監控等全生命週期管理。

目錄:

一、為什麼引入EOS8閘道器

二、EOS 8閘道器的技術框架

三、API接入和監控示例

一、為什麼引入EOS8閘道器

普元EOS 8閘道器設計及應用

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

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

API Gateway 在各個模組間如何運作?


普元EOS 8閘道器設計及應用

上圖展示了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接出)。


二、EOS 8閘道器的技術框架

EOS8 閘道器部署拓撲架構

普元EOS 8閘道器設計及應用

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 閘道器部署拓撲架構主要技術

普元EOS 8閘道器設計及應用

註冊中心使用Spring Cloud Eureka,配置中心使用Ctrip Apollo。

閘道器主要的技術框架:

  1. 閘道器使用了Oauth2鑑權技術(後續配合IAM做許可權校驗)。

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

  3. 嵌入了Jetty容器讓閘道器更輕,讓系統效能維持在一個可接受狀態。

  4. 使用了基於傳輸層的Netty框架,提供非同步的、事件驅動的網路應用程式框架,為我們核心框架分階段訊息非同步處理架構奠定基礎。

分階段訊息非同步處理

普元EOS 8閘道器設計及應用

可以將一次請求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閘道器設計及應用

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管理更加完善。

三、API接入和監控示例

如何使用EOS 8閘道器?用EOS 8閘道器如何註冊和釋出一個API?服務消費者系統又如何根據token呼叫已釋出的閘道器?

API註冊

建立後端應用

普元EOS 8閘道器設計及應用

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

建立API第一步(配置基本資訊)

普元EOS 8閘道器設計及應用

建立API第一步配置基本資訊,對需要註冊的API進行定義分組、協議、名稱的配置。

建立API第二步(配置API接入【協議/資料轉換】)

普元EOS 8閘道器設計及應用

建立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後端服務)

普元EOS 8閘道器設計及應用

建立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第四步(響應結果配置)


普元EOS 8閘道器設計及應用

建立API第四步,響應結果配置。

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

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

到這裡,一個完整的實現了報文轉換的API註冊成功,接下來介紹剛註冊好的API如何新增策略配置。

API策略配置

ip配置

普元EOS 8閘道器設計及應用

首先建立黑白名單策略,“控制型別”可選擇黑名單或者白名單,“IP列表”可用正規表示式定義,然後在剛剛建立好的白名單策略上繫結API,繫結成功則白名單策略生效。

呼叫數配置

普元EOS 8閘道器設計及應用

首先建立呼叫數控制策略,配置單位時間內的API被呼叫次數和單位時間內呼叫方的呼叫次數,然後在剛剛建立好的呼叫數策略上繫結API,繫結成功則呼叫數策略生效。

接下來開始介紹如何呼叫API。

呼叫API

API釋出

普元EOS 8閘道器設計及應用

API處於“已釋出”狀態才能被呼叫。

建立呼叫方系統

普元EOS 8閘道器設計及應用

首先建立呼叫方系統。

呼叫方系統訂閱API

普元EOS 8閘道器設計及應用

然後呼叫方系統訂閱API。

獲取閘道器頒發給呼叫方系統的憑證token

普元EOS 8閘道器設計及應用

訂閱完成後,閘道器會頒發一個令牌,呼叫系統想要呼叫剛才訂閱的API需要傳這個令牌做認證。

呼叫系統呼叫訂閱後的API

普元EOS 8閘道器設計及應用

請求已釋出的API,將剛剛獲取的令牌放入“access_token”請求頭中,在IP策略和呼叫數策略允許範圍內,呼叫成功。

多呼叫幾次後,監控呼叫詳情。

API呼叫監控

普元EOS 8閘道器設計及應用

剛才呼叫後,API Gateway Server會產生日誌檔案,API_Gateway_Monitor自動解析完日誌後會產生監控資料,如上圖展示。

總結:


EOS 8 API Gateway有以上諸多優點,更為關鍵的是,兩種部署模式能夠滿足廣大使用者的不同需求。其訊息非同步處理機制和統一API管理等功能,必將吸引廣泛的使用者體驗並得到他們的青睞。而豐富的服務引擎也將會使API管理更加完善,給使用者以最優的開發體驗。

精選提問:

問1:請問閘道器本身的高可用和擴充套件性怎麼保證?

答:當高併發呼叫時,EOS8閘道器可部署在容器雲,通過F5或Nginx等工具做橫向擴充套件。流控機制可對API、呼叫方進行限流,減少併發問題的發生。業務服務端有熔斷機制保障執行緒高可用,接出時可配置後端服務超時的重連次數,當呼叫異常發生做相應的處理。

問2:api授權是採取什麼模式?

答:授權採取API釋出訂閱模式。當API處於“已釋出”狀態,消費者系統可訂閱API獲取閘道器頒發的令牌,當呼叫閘道器的目標API,閘道器會根據令牌校驗呼叫是否合法。

問3:單節點部署支援訪問多少併發?

答:1K報文在1000併發下,閘道器的TPS有2362,隨著報文增加,TPS會隨之有所下降。

普元EOS 8閘道器設計及應用

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

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31562043/viewspace-2558420/,如需轉載,請註明出處,否則將追究法律責任。

相關文章