隨著Docker的出現，PaaS、CaaS(Container As A Service)、甚至DCOS(DataCenter OS)呈現了爆發式的發展。而在PaaS中，因為實例一般默認為動態IP，對于7層調用(比如http請求)，需要7層動態路由獲取應用域名(或虛IP)和后端實例的映射關系，以提供7層服務;而對于4層調用(比如rpc調用)，可以通過動態LVS或名字服務(或基于zookeeper/etcd等實現的服務注冊和發現工具)進行調用。
簡單舉例，開發者在PaaS里創建了一個APP，包含若干個實例，然后為APP綁定某個域名。用戶對APP發出請求，需要經過后端實例的處理才能正確的返回。那么作為7層動態路由，核心就是獲取域名(或虛IP)與后端實例的對應關系并作為反向代理完成請求轉發。
這里簡單討論下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作為系統緩存。
參考：
https://github.com/openresty/lua-nginx-module
http://segmentfault.com/a/1190000004128807?luicode=10000359&luicode=10000359
京公網安備 11010502049343號