深入微服務?API?網關之架構實踐篇
[導讀]-???前言???-?隨著這些年微服務的流行，API網關已經成為微服務架構中不可或缺的一環(huán)。一方面它承擔著服務對外的唯一門戶，一方面它提取了許多應用的共性功能。-???整體架構???-?我們的Api網關目前的架構如上所示，可以看到Api網關處于一個什么位置，往上承接所有的南北流量...
-? ? ?前言? ? ?-?
隨著這些年微服務的流行，API網關已經成為微服務架構中不可或缺的一環(huán)。一方面它承擔著服務對外的唯一門戶，一方面它提取了許多應用的共性功能。
-? ? ?整體架構? ? ?-?
我們的Api網關目前的架構如上所示，可以看到Api網關處于一個什么位置，往上承接所有的南北流量，往下會分發(fā)流量到微服務應用或者BFF聚合應用，在BFF規(guī)范化之前我們仍然將其視為一個普通微服務應用。目前Api網關實現(xiàn)的功能包括請求分發(fā)、條件路由、Api管理、限流隔離、熔斷降級、安全策略、監(jiān)控報警以及調用鏈追蹤等。
我們的Api網關基于RxNetty開發(fā)，整個流程是異步響應式的，可以達到較高的單機并發(fā)?；谏僭燧喿拥睦砟?，Api網關的大部分功能都是結合現(xiàn)有平臺實現(xiàn)。包括請求分發(fā)、條件路由基于微服務框架，限流隔離、熔斷降級基于穩(wěn)定性平臺，監(jiān)控報警基于監(jiān)控平臺等，安全策略基于大數(shù)據分析平臺等。注冊中心與配置中心則分別負責服務注冊核心信息與第三方配置信息的下發(fā)。-? ? ?請求分發(fā)??? ?-?
請求的分發(fā)路由應該是一個網關最基本的功能，在絕大多數(shù)基于nginx開發(fā)的網關上，這部分功能通?；趧討B(tài)更新代理的upstream。而在我們的實現(xiàn)中，認為網關是一個只訂閱不注冊的微服務而已，區(qū)別是微服務應用發(fā)起rpc調用指定了調用服務，而網關接收請求分發(fā)只有url信息。
這可以通過簡單的改造來復用已有微服務框架的服務發(fā)現(xiàn)功能。
經過一系列url規(guī)范化行動后，我們的url目前不同的應用都會采取不同的前綴，同時這個前綴信息會隨著應用注冊到注冊中心。
這樣網關進行服務發(fā)現(xiàn)時會給不同的url前綴以及微服務應用構建不同的namespace對象，在進行請求匹配時候只需根據url前綴選取到對應的namespace即可匹配到對應微服務應用，后續(xù)就是現(xiàn)有微服務框架sdk的功能：路由、負載均衡直至完成整個調用。
這里還涉及到另一個問題，網關選擇服務發(fā)現(xiàn)的應用是哪些？即我需要拉取哪些應用信息以構建namespace？
我們這里對服務發(fā)現(xiàn)對象進行了管理，用戶可在管控平臺上控制微服務應用在網關層的上下線，這會通過我們的配置中心推送到網關并進行一次熱更新，刷新內存緩存，這樣就做到了請求分發(fā)服務的動態(tài)增減。
-? ? ?條件路由
下載文檔
