随着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