配置文件的复杂性

finyren · 2016-07-01T13:50:08+00:00

多谢院长指点。在 2016年7月1日星期五 UTC+8下午1:28:18，&...

配置文件的复杂性

finyren

hello!

我这边有两千多个域名，每个域名里面又根据uri的不同需要做不同的业务处理。当我在实际配置时，觉得配置文件会非常复杂。配置文件里面有的配置是用于真正处理业务的，而有的是用于我的功能实现的，交织在一起不仅不好看，而且太复杂了。比如：

server {
listen 80 default_server;

set $proxy_addrs '';
set $next_address '';
set $route_header '';

location ~* ^/ {
content_by_lua_block {
require "dynamic".dynamic_request()
}
}
location @proxy {
rewrite_by_lua_block {
require "dynamic".add_route_header()
}
proxy_pass http://$next_address;
error_page 504 500 502 503 = @next;
}
location @next {
rewrite_by_lua_block {
require "dynamic".next_proxy_addr()
}
}
location @source {
proxy_pass http://192.168.1.212;
}

}

向上面这种配置，那3个set的变量还有@proxy, @next, @source. 其实都是我用于内部实现用的。这个server块还有很多其他配置省略了。感觉这种将实际业务的配置和用于功能实现的配置交织在一起的方式很不利于维护，并且很复杂。

请问各位大神有没有遇到过类似问题，是怎么简化nginx的配置的？

agentzh

Hello!

2016-06-30 22:50 GMT-07:00 ch ren:
> 向上面这种配置，那3个set的变量还有@proxy, @next, @source.
> 其实都是我用于内部实现用的。这个server块还有很多其他配置省略了。感觉这种将实际业务的配置和用于功能实现的配置交织在一起的方式很不利于维护，并且很复杂。
>
> 请问各位大神有没有遇到过类似问题，是怎么简化nginx的配置的？
>

建议尽量把逻辑放在 Lua 代码中，使用 ngx_lua 提供的 Lua API 来和 nginx
交互，以实现高度的动态性和定制化。nginx.conf 应尽量保持简单。比如 CloudFlare 这样的 CDN
公司服务着百万级别的不同的客户站点，各个客户站点的配置和逻辑都千差万别，但 nginx.conf 还是比较简单的，几乎所有业务逻辑都是在
Lua 代码基中搞定的。如果把这些都写在 nginx.conf 里面，不容易实现动态更新不说，同时也极难维护和伸缩，性能也会很差。

Regards,
-agentzh

paulvon73

春哥，就着这个问题扩展问下，你们那边百万级别的客户，应该有百万级别的配置吧，这些配置你们是怎么高效存储，高效访问的呢？

我们现在是用json文件本地存储，每次nginx启动时加载至shared_dict中。现在我们的客户才1000多，json文件就2m多了，长远看这肯定

是个问题，不知道方不方便透露下你们那边是怎么处理的呢谢谢了

On Saturday, July 2, 2016 at 2:13:42 AM UTC+8, agentzh wrote:

Hello!

2016-06-30 22:50 GMT-07:00 ch ren:
> 向上面这种配置，那3个set的变量还有@proxy, @next, @source.
> 其实都是我用于内部实现用的。这个server块还有很多其他配置省略了。感觉这种将实际业务的配置和用于功能实现的配置交织在一起的方式很不利于维护，并且很复杂。
>
> 请问各位大神有没有遇到过类似问题，是怎么简化nginx的配置的？
>

建议尽量把逻辑放在 Lua 代码中，使用 ngx_lua 提供的 Lua API 来和 nginx
交互，以实现高度的动态性和定制化。nginx.conf 应尽量保持简单。比如 CloudFlare 这样的 CDN
公司服务着百万级别的不同的客户站点，各个客户站点的配置和逻辑都千差万别，但 nginx.conf 还是比较简单的，几乎所有业务逻辑都是在
Lua 代码基中搞定的。如果把这些都写在 nginx.conf 里面，不容易实现动态更新不说，同时也极难维护和伸缩，性能也会很差。

Regards,
-agentzh

agentzh

Hello!

2016-07-07 20:18 GMT-07:00 Paul Von:
> 春哥，就着这个问题扩展问下，你们那边百万级别的客户，应该有百万级别的配置吧，这些配置你们是怎么高效存储，高效访问的呢？
> 我们现在是用json文件本地存储，每次nginx启动时加载至shared_dict中。现在我们的客户才1000多，json文件就2m多了，长远看这肯定
> 是个问题，不知道方不方便透露下你们那边是怎么处理的呢  谢谢了
>

确实是百万级的。CloudFlare 使用 KyotoTycoon（KT）的 master-slave replication
来实现配置的全网分发。每个 edge 节点的 nginx 只通过 lua-resty-memcached 库来访问本地的 KT
服务，然后通过 lua_shared_dict 和 lua-resty-lrucache 实现 nginx 进程内的两级缓存。

Regards,
-agentzh

paulvon73

学习了，谢谢春哥

On Sunday, July 10, 2016 at 10:26:00 AM UTC+8, agentzh wrote:

Hello!

2016-07-07 20:18 GMT-07:00 Paul Von:
> 春哥，就着这个问题扩展问下，你们那边百万级别的客户，应该有百万级别的配置吧，这些配置你们是怎么高效存储，高效访问的呢？
> 我们现在是用json文件本地存储，每次nginx启动时加载至shared_dict中。现在我们的客户才1000多，json文件就2m多了，长远看这肯定
> 是个问题，不知道方不方便透露下你们那边是怎么处理的呢谢谢了
>

确实是百万级的。CloudFlare 使用 KyotoTycoon（KT）的 master-slave replication
来实现配置的全网分发。每个 edge 节点的 nginx 只通过 lua-resty-memcached 库来访问本地的 KT
服务，然后通过 lua_shared_dict 和 lua-resty-lrucache 实现 nginx 进程内的两级缓存。

Regards,
-agentzh