PaaS 7層動態路由的若干實現

2021-08-19 12:10:30 字數 1522 閱讀 5692

隨著docker的出現,paas、caas(container as a service)、甚至dcos(datacenter os)呈現了爆發式的發展。而在paas中,因為例項一般預設為動態ip,對於7層呼叫(比如http請求),需要7層動態路由獲取應用網域名稱(或虛ip)和後端例項的對映關係,以提供7層服務;而對於4層呼叫(比如rpc呼叫),可以通過動態lvs或名字服務(或基於zookeeper/etcd等實現的服務註冊和發現工具)進行呼叫。

這裡簡單討論下7層動態路由的若干實現。因為nginx是乙個高效能的反向**伺服器,以是否基於nginx實現7層動態路由,可以將這些實現大概分為兩大類。

第一類,不依賴nginx,專案自身實現了反向**的功能。cloudfoundry可以說是第一代的開源paas專案,其模組gorouter即為乙個動態路由實現(同時支援4層和7層)。以cloudfoundry (release v164)為例,使用nats作為訊息匯流排,對各模組呼叫和訊息傳遞進行解耦。可以看下gorouter (tag 45ca951297)的**,registry/registry.go裡實現了相應邏輯**,以獲取網域名稱和後端例項的對應關係。其大概流程為:

例項啟動後向nats發布訊息,gorouter則會訂閱這些訊息,從而獲取應用網域名稱和後端例項的對應關係;同時gorouter使用goroutine實現了高效能的請求處理和**,支援4層和7層呼叫。

docker出現後,基於docker的輕量級paas紛紛湧現,大家可能會把例項資訊(如ip資訊等)儲存在redis(或其它資料儲存)。開源專案dinp基本就是這樣的實現,dinp-router fork自cloudfoundry的gorouter (tag 45ca951297),更改了部分**,以獲取應用網域名稱和redis中儲存的後端例項的對應關係,從而實現了7層動態路由的功能。

類似的,dotcloud的hipache則是利用nodejs的http庫實現了請求**,後端例項資訊則可以儲存在redis中。

當然,很多任務程師在7層的選型上還是更信賴nginx,畢竟nginx在效能、穩定性、擴充套件性上都是不二之選。基於nginx來實現7層動態路由,大概又有兩種實現思路。

其一,基於名字服務(或基於zookeeper/etcd等實現的服務註冊和發現工具),通過watch或定時排程,將註冊的後端例項更新到nginx配置檔案的upstream中,從而實現後端的(準)實時變化。這方面也有如confd等的開源工具。confd基於golang的template庫,將nginx配置檔案作為模板;支援consul/etcd/redis/zookeeper等諸多後端儲存,通過watch或定時排程從這些後端獲取例項資訊,並更新到nginx配置檔案模板,從而實現(準)實時的7層動態路由。這種實現邏輯簡單,穩定性高,但在大規模應用時nginx可能會較頻繁的reload。

其二,基於nginx-lua實現。每次使用者請求到達相應upstream時,通過nginx-lua從redis等資料儲存中獲得後端例項資訊,從而實現請求的**。nginx獲取redis資料需要進行一次網路請求,同機房的時延一般是毫秒級,但在大訪問量時可能存在一定問題,因此可以使用lua-shared-dict作為系統快取。

參考:

本文**蘑菇街技術部落格

PaaS 7層動態路由的若干實現

隨著docker的出現,paas caas container as a service 甚至dcos datacenter os 呈現了爆發式的發展。而在paas中,因為例項一般預設為動態ip,對於7層呼叫 比如http請求 需要7層動態路由獲取應用網域名稱 或虛ip 和後端例項的對映關係,以提供...

vue動態路由的實現

路由動態渲染,即路由是變動的,由後端返回,故資料不是唯一不變的 實現方法 route.index.js 需要許可權的頁面應該放在非同步路由裡面,登入頁 404頁等放在同步路由裡面,再拼接 實現過程 不需要許可權的頁面 export const asyncroutes redirect account...

網路層IP路由的負載均衡實現思路

equalize補丁可以解決路由的負載均衡問題,然而其實現的代價卻是禁用了均衡路由的快取,每次都要查詢路由表,查詢路由表的開銷抵消了一部分負載均衡帶來的效能提公升。因此最好的方法就是既實現了路由的負載均衡,又實現了路由快取,實現思路如下 為每一系列需要在其間做負載均衡的路由準備乙個均衡鍊錶t,新增路...