Nginx的动态配置方案

背景

在Nginx的设计中,每一个upstream维护了一张静态路由表,存储了backend的ip、port以及其他的meta信息。每次请求到达后,会依据location检索路由表,然后依据具体的调度算法(如round robin )选择一个backend转发请求。

但这张路由表是静态的,如果变更后,则必须reload,经常reload的话这对SLA有较大影响。
为了达到减少reload的目的,大多通过动态更新维护路由表来解决这个问题。

通常路由表的维护有Push与Pull两种方式。

Push模式

通过Nginx API向Nginx发出请求。

Pull模式

路由表中所有的backend信息(含meta)存储到DB,所有的Nginx从DB拉取相关信息。
有变更则更新路由表,利用DB解决一致性问题。

Push与Pull方案对比

特性\方案 Push方案 Pull方案
优点 操作简单、便利 一致性问题好解决、稳定、可靠
缺点 多台Nginx时,不同Nginx路由表的一致性难于保证 相对复杂

Pull方案的具体实现

方案1

Upsync + Consul。

  • 路由表中所有的backend信息(含meta)存储到Consul,所有的Nginx从Consul拉取相关信息。有变更则更新路由表,利用Consul解决一致性问题
  • 同时利用Consul的wait机制解决实时性问题。
  • 利用Consul的index进行增量摘取,解决带宽占用问题。
  • Upsync模块使用了Push模式,通过拉取Consul的后端Server的列表,并动态更新Nginx的路由信息。

方案2

Upsync + Etcd

坚持原创技术分享,您的支持将鼓励我继续创作!