Writing a module-syncing upstreams from conf-servers

Xiaokai Wang xiaokai.wang at live.com
Wed Jan 13 06:57:44 UTC 2016

Hi Nginxers,I'm writing a new module that syncs upstreams from conf-servers(consul, etcd...). During the nginx offering service, the module makes requests to the conf-server(consul, etcd...) to pull upstreams backend list if upstreams value has changed and update upstreams peers to make new backend servers working.
The reason I write the module is that:       Last the Spring Festival, the company need extend the backend resources for the festival, need reload the new configuration of nginx, and find that partly requests cost much more time during the reloading, suspect it's caused by reloading.       The last, I think the fact prove it's true. The contrast between reloading and using module.      Other refer: https://www.nginx.com/blog/dynamic-reconfiguration-with-nginx-plus/ .On the other hand, the module I am writing is mostly different than other modules I could learn from, and all my knowledge about nginx is from looking at how other modules is written, I'm wondering and hoping if anyone could comment on how I designed the module and raise any issues if I did anything problematic, wrong,  weird or even stupid.
Any convenience, the module is here: https://github.com/weibocom/nginx-upsync-module

As everyone knows every work process has it's conf, so the module realizes that every work-process pulls upstreams independently and updates its own peers. I think that's easy and more reliable. Every peers is a array, so every updating need a new array and delete old peers, but, when delete old peers needing judge if having old requests use that. It's a little complicated.What do you think?
work-process flow: startup->pull from conf-servers->pull success->try to update->work;                                startup->pull from conf-servers->failed, parse dump file->try to update->work;I am not sure I make that clear, but I really want to get you advise. Any comments, suggestions, warnings are welcome.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160113/43818ea7/attachment.html>

More information about the nginx mailing list