nginx动态配置及服务发现那些事

标题, 《闲聊nginx动态配置及服务发现的那些事》 …

这次的准备闲聊关于nginx服务发现的话题, 按照我以往写文章的性子，估计会迁移一些主题. 毕竟单纯聊nginx和动态服务发现没啥意思，因我以前的文章有大量的涉及到。

该文章写的有些乱，欢迎来喷 ! 另外文章后续不断更新中，请到原文地址查看更新. http://xiaorui.cc/?p=3855

nginx upstream相关

我这里就不再精细的讲述nginx的源码, 毕竟我自己也只是粗略看了点nginx的底层代码. nginx的动态配置肯定是绕不过upstream模块的运作了，他主要的驱动是xxx_pass，比如最常用的proxy_pass, uwsgi_pass。upstream相关配置结构的建立，并不一定是非要配置upstream这个指令才会去做，有时proxy_pass直接就是跟一个ip地址或域名, 他其实隐式的调用upstream 。

那么一个具体的request过程如何跟upstream配置怎么关联起来的?

首先是通过peer.init函数指针初始化，然后根据round robbin算法选择ngx_http_upstream_init_round_robin_peer，每种算法锁出发的函数不一样，这是废话。从配置上看，凡是请求到location /xxx的request请求，他们都关联到同一个upstream配置，但是既然大家公用一个结构，那么需不需要互斥呢？如果大家都要修改其中的某个成员…

实际上，nginx中一个请求不会中多个进程中同时处理，一个request生老病死都在一个worker内。每个nginx worker都会监听自己相关的epoll fd事件。当一个worker争取到了nginx listen fd accept的锁，那么他就可以接收新的request请求，这个请求的创建出的fd会压到他本进程的事件里。我想说的是，他不会逃到worker里，因为也没这个必要这么实现，跨多进程传递socket本身是个很蛋疼的实现.

nginx relaod相关

那么nginx upstrem阐述完了，我们再聊聊nginx -s reload.

当你增删改upstream配置的时候，如何让nginx不停服务的重载配置？ nginx -s reload. reload的实现相对好理解，-s的作用是向master进程发送信号。其实是SIGHUP信号的封装，也就是说我们可以直接通过kill向nginx的pid发送SIGHUP信号来完成reload操作。
master通过ngx_signal_handler处理信号，见到reload就重置ngx_reconfigure = 1.

casengx_signal_value(NGX_RECONFIGURE_SIGNAL):

ngx_reconfigure = 1;

action = ", reconfiguring";

break;

这样当ngx_master_process_cycle的for循环中检测到ngx_reconfigure ==1，就开始做重加载配置的操作，通过ngx_start_worker_processes开启新进程，而之前的进程则通过ngx_signal_worker_processes来发送信号进行“优雅”的关闭. 所谓优雅的关闭, 就是让当前真正处理请求的进程等到处理完之后再退出，当然进程不能再次参与accept锁的争夺了. 这样新的请求会拿到listen accept锁，可建立reqeust连接.

如何保证已经建连的连接 ?

如果是短连接，那么在请求完之后，worker会主动发送close()，后面就把fd事件给踢掉。

那么长连接会怎么办？这个时候长连接是有两种的, 前者是是client 跟 nginx proxy的连接，后者是proxy跟后端服务的连接，比如nginx –> tornado 就属于后者.

nginx proxy主要就是给client提供服务，在对外请求完毕的情况下，右面的连接可有可无了, 当然我们还是操作proxy给后端服务发送close()关闭连接。如果发生异常进程退出，后端经过keepalive timeout后进行回收资源.

前者的连接就有点意思了, 当你的请求是http1.1长连接时候，不管是单次请求或者是stream这种流式请求，都会在请求完之后退出。那么对于客户端有什么影响? 客户端会收到fin的tcp关闭请求，配合nginx关闭连接之后. 当你再次访问nginx的时候，才会重建一个连接…

什么是nginx的动态配置?

到此为止, nginx reload 和 upstream 都过了一遍. 那么动态配置又是什么？我们什么时候需要动态配置?

我认为nginx的动态配置可以有这么几种方法.

一种是dns动态解析，一种是模板渲染，一种服务发现动态配置重载.

碰巧，这几种配置我都有在线上用过，我不会单纯的说谁更好，谁更差，因为每个动态配置方法都有他的应用场景. 比如dns动态解析非常适合依赖域名来辨识主机的集群服务，多用在类aws、阿里云这样的云服务. 模板动态配置方法更适合那种大型的运维平台管理体系. 服务发现配置适合那种docker化的服务, 或者类似的微服务框架体系.

第一种， dns动态解析

我们通常在配置nginx upstream的时候都会使用ip地址. 对于那种依赖域名的集群服务，非常适合这样的配置. 因为你修改了一组域名的配置，你如果nginx域名来解析, 就不再重新配置了。这个dns服务器肯定不能是公网. 内网必须配置一个高性能的dns服务，比如dnsmasq, bind. 另外我们需要注意dns缓存的问题, nginx默认会根据dns server返回的ttl来设置记录的失效时间, 推荐配置成5s . 如果ttl太小，dns也会成为一个瓶颈点.

dns的缺点也明显，那就是ip级别，很多时候一台服务器我们会开N个port, 动态的域名只能跟踪ip的级别, 这样显得很不灵活。由于nginx dns动态解析多适用于云主机环境，云主机一般是一两个核，所以这是可以接受的.

如果你使用skydns的化，也可以实现我们后面讲述的动态服务发现.

我们可以简单的配置dns模式.:

resolver 10.0.0.1;

set $blog http://service-123.xiaorui.cc;

location / {

proxy_pass $blog;

}

也可以配置更加的丰富. 我这边用的是tengine。

upstream backend {

dynamic_resolve fallback=stale fail_timeout=30s;

server a.com;

server b.com;

}

server {

proxy_pass http://backend;

}

nginx plus版的配置. 相对来说，nginx plus的功能更加丰富点，但是需要收费，我在free期间测试过该功能，通过.

#xiaorui.cc

resolver 10.0.0.1;

upstream xiaorui.cc {

zone upstream_dynamic 64k;

server backend2.example.com:8080 fail_timeout=5s slow_start=30s;

server backend3.example.com resolve;

server backend4.example.com service=http resolve;

}

server {

location / {

proxy_pass http://xiaorui.cc;

health_check;

}

另外可以使用nginx的dns加强版插件. https://github.com/GUI/nginx-upstream-dynamic-servers

第二种，动态模板解析

我在上面有说过动态模板解析的场景一般是那种运维平台系统，我曾经在全网集群调度平台，智能dns管理系统中使用过这种方法，他的优点在于系统的集中式管理，本身来说这种管理方式只是把手动的操作变成自动化而已，但这种配置方式相当的稳定，只是每次渲染模板后都需要nginx -s reload.

另外他的开发成本还是不低的，小公司hold不住的，一般各大公司的运维平台多使用这种方式.

简单说下他的实现，比如python语言，我们可以使用jinja2、mako的模板引擎，动态的根据你提供变量渲染配置.

第三种，服务发现模式.

服务发现是这次的重点，博客里有聊过etcd、zookeeper、consul 这三种服务发现的使用及坑. 那么跟nginx是怎么实现的动态加载配置？他跟nginx -s reload不一样， reload会重新开一组进程来接收请求，让老进程完事后再退出. 切记，如果你线上流量较大，不要频繁的reload, 因为nginx新老配置交替的时候会掉15%左右的qps .

其实并不一定要按照reload的路子走，我们可以针对nginx进行改造。让他可以主动去拉取最新的服务发现里的主机. 在github中的不少nginx服务发现的实现，他们不会新开进程，而是在在master进程中注册一个定时器，该事件会触发watch，当发现version的版本号发生变更时，就知道主机列表发生了变化，进而重载配置. 那么如何让worker进程也使用新的配置？这时候可能不会使用共享变量，因为读写都要加锁，及其影响速度. 所以每个worker都会缓存一份location upstream的配置，每个worker也会有个定时器，他的事件共享内存的upstream有无变化…

优点是什么？服务发现模式特别适合微服务，更片面的说 docker服务化. 因为docker可以更加弹性的扩展缩减集群的计算架构. 当docker容器起来后，直接给consul注册一个槽位，间隔性的发送健康心跳. 我们不需要管nginx的配置，nginx会自己动态的重载最新的配置. 当我们把docker容器干掉了，由于consul有配置过期自动清理记录，很大程度保证consul服务发现列表的 “纯洁性” .

一个nginx consul的场景图:

下图是etcd的服务发现流程. 服务的提供者会注册到服务注册中心上，请求者在请求之前会访问一次注册中心，从里面取出主机记录才会进一步访问.

nginx服务发现的模块， https://github.com/weibocom/nginx-upsync-module

转自：

http://xiaorui.cc/?p=3855

nginx动态配置及服务发现那些事相关推荐

java服务负载均衡_适用于Java开发人员的微服务：配置，服务发现和负载平衡
java服务负载均衡 1.配置,服务发现和负载平衡–简介我们正在缓慢但稳定地朝着准备好将微服务部署到生产中的方向发展. 在本教程的这一部分中,我们将讨论三个主要主题:配置,服务发现和负载平衡. 我们 ...
Ambassador系列-03-服务配置和服务发现
Ambassador 服务配置 Ambassador提供了三种服务配置方法. CRDs方式:Customer Resource Definitions 注解方式:Kubernetes Service ...
Nacos教程_3 整合SpringCloud(配置中心+服务发现)
教程原稿 https://gitee.com/fakerlove/joker-nacos 文章目录 3. 整合SpringCloud(配置中心+服务发现) 3.1 写配置 3.2 创建父工程demo ...
nginx简单配置php服务（多个）
nginx简单配置php服务(多个) 摘要:大部分网站开发语言都要运行在服务器,比如主流的nginx.apache等等,部署服务器环境对于大部分人来说是比较陌生和复杂的,其实搞懂了之后是很简单易用的. ...
openresty＋consul动态配置更新(服务变更发现)
最近在做数据收集平台,用openresty往kafka里push数据,不管是kafka broker也好,还是一个配置也好,希望做到动态更新,不需要reload openresty.尤其是针对接口调用 ...
这就是你日日夜夜想要的docker！！！---------docker+consul+ nginx集成分布式的服务发现与注册架构
文章目录一.Docker consul容器服务更新与发现理论 1.基本架构 2.基于nginx和consul构建高可用及自动发现的Docker服务架构 3.Docker consul自动发现服务架构 ...
Nginx安装配置与服务搭建
Nginx概述 Nginx(发音同engine x)是一款由俄罗斯程序员Igor Sysoev所开发轻量级的网页服务器.反向代理服务器以及电子邮件(IMAP/POP3)代理服务器.起初是供俄国大型的门 ...
spring cloud 服务发现时效配置（服务发现慢优化）
相信很多人都会感觉到,springcloud服务发现很慢,特别是使用feign client作为通讯工具的时候,明明服务已经启动了,还要等30-90s左右才能被正常调用到.这个等待有点长! 这件事情也 ...
Nginx 使用 NACOS 实现服务发现和反向代理。不用reload
现状我们想把自己的 http 服务注册 nacos,然后使用nginx 来实现反向代理.官方提供了一个方案是通过 java 来订阅nacos .当服务 ip 出现变化的时候.重新生成一份 ngin ...

nginx动态配置及服务发现那些事

nginx动态配置及服务发现那些事相关推荐

最新文章

热门文章