浅析PaaS 7层动态路由的几类实现

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

　　nginx在性能、稳定性、扩展性上都是不二之选。基于nginx来实现7层动态路由，大概又有两种实现思路。

　　第一种思路，基于nginx-lua实现。每次用户请求到达相应upstream时，通过nginx-lua从redis等数据存储中获得后端实例信息，从而实现请求的转发。nginx获取redis数据需要进行一次网络请求，同机房的时延一般是毫秒级，但在大访问量时可能存在一定问题，因此可以使用 lua-shared-dict作为系统缓存。

　　第二种思路，基于名字服务(或基于zookeeper/etcd等实现的服务注册和发现工具)，通过watch或定时调度，将注册的后端实例更新到 nginx配置文件的upstream中，从而实现后端的(准)实时变化。这方面也有如confd等的开源工具。confd基于golang的 template库，将nginx配置文件作为模板;支持consul/etcd/redis/zookeeper等诸多后端存储，通过watch或定时调度从这些后端获取实例信息，并更新到nginx配置文件模板，从而实现(准)实时的7层动态路由。这种实现逻辑简单，稳定性高，但在大规模应用时 nginx可能会较频繁的reload。

　　参考如下链接：

　　https://github.com/openresty/lua-nginx-module

　　http://segmentfault.com/a/1190000004128807?luicode=10000359&luicode=10000359

　　第二类，不依赖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中。

　　原文链接：http://mogu.io/151-151