隨著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，新增路...