Upsync是新浪微博开源的基于Nginx实现动态配置的三方模块。 Upsync模块工作原理在Nginx的设计中，每一个upstream维护了一张静态路由表，存储了backend的ip、port以及其他的meta信息。每次请求到达后，会依据location检索路由表，然后依据具体的调度算法(如round robin )选择一个backend转发请求。但这张路由表是静态的，如果变更后，则必须reload，经常reload的话这对SLA有较大影响。 为了达到减少reload的目的，大多通过动态更新维护路由表来解决这个问题。通常路由表的维护有Push与Pull两种方式。
通过Nginx API向Nginx发出请求,操作简单、便利。 架构图如下： http api除了操作简单、方便，而且实时性好；缺点是有多台Nginx时，不同Nginx路由表的一致性难于保证，如果某一条注册失败，便会造成服务配置的不一致，容错复杂。另外扩容Nginx服务器，需要从其他的Nginx中同步路由表。
路由表中所有的backend信息(含meta)存储到Consul，所有的Nginx从Consul拉取相关信息。有变更则更新路由表，利用Consul解决一致性问题，同时利用Consul的wait机制解决实时性问题。利用Consul的index进行增量摘取，解决带宽占用问题。 在Consul中，一个K/V对代表一个backend信息，增加一个即视作扩容，减少一个即为缩容。调整meta信息，如权重，也可以达到动态流量调整的目的。 架构图如下：
Upsync模块使用了第二种模式，通过拉取Consul的后端Server的列表，并动态更新Nginx的路由信息。Upsync模块工作流程图如下： 每个Work进程定时的去Consul拉取相应upstream的配置，若Consul发现对应upstream的值没有变化，便会hang住这个请求五分钟(默认值)。在这五分钟内对此upstream的任何操作，都会立刻返回给Nginx对相应路由进行更新。 upstream变更后，除了更新Nginx的缓存路由信息，还会把本upstream的后端server列表dump到本地，保持本地server信息与consul的一致性。 除了注册／注销后端的server到consul，会更新到Nginx的upstream路由信息外，对后端server属性的修改也会同步到nginx的upstream路由。 Upsync模块支持修改的属性有：weight、max_fails、fail_timeout、down。
每个work进程各自拉取、更新各自的路由表，采用这种方式的原因：
Upsync模块高可用性 Nginx的后端列表更新依赖于Consul，但是不强依赖于它，具体表现为：
Nginx启动流程图如下： Nginx启动时，master进程首先会解析本地的配置文件，解析完成功，接着进行一系列的初始化，之后便会开始work进程的初始化。work初始化时会去Consul拉取配置，进行work进程upstream路由信息的更新，若拉取成功，便直接更新，若拉取失败，便会打开配置的dump后端列表的文件，提取之前dump下来的server信息，进行upstream路由的更新，之后便开始正常的提供服务。 每次去拉取Consul都会设置连接超时，由于Consul在无更新的情况下默认会hang五分钟，所以响应超时配置时间应大于五分钟。大于五分钟之后，Consul依旧没有返回，便直接做超时处理。 Upsync模块安装安装Consul
Upsync最新版本是支持ectd，这里用ectd做为后端存储。有关consule的讲解后面单独来讲。如果你还没有etcd环境，可参考「 声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系 [邮箱地址] 删除 |
注册
登录
