nginx海量业务运营总结

背景

标题党了，现在不写个海量、高并发、大数据都不好意思发出来。
前面发了一个nginx的tips文章，一些基本的用法。这里主要说下nginx在多业务、大规模场景下的一些实践与问题。

nginx线上运营的问题

upstream配置更新

首先，配置修改问题。1-2个业务，20台以下的nginx机器，人肉修改nginx配置没问题。但业务线拉长，业务需求多，需要一个配置管理系统统一按版本、下方配置。方便统一管理与记录。

然后，upstream后端机器扩缩容带来的变更。如果每次都需要人工修改配置下发，肯定会废掉。最好是有一个接口来做这个事情，貌似阿里的tengine已经实现了。
我这里是利用我厂内部的一个类dns的名字服务，自己写脚本实现的。大概步骤是：

nginx.tplt(nginx配置模版,upstream里配置名字服务的id) --->脚本处理翻译--> nginx标准配置文件 

名字服务和内部云系统完全打通，upstream后端机器的变更可以实时的通过名字服务查询到。脚本每隔2分钟执行一次，nginx检查配置，reload生效。实现了后端自动扩缩容，nginx接入自动生效。

nginx监控缺失

nginx自带的stats模块只能看全局的连接数，线上业务动辄上万QPS，开日志会浪费机器io，而且又带来一个新的问题： 日志管理。所以我线上默认全部关闭日志。那怎么监控nginx这一环呢？

自己弄了个nginx模块，抽取nginx内置的变量: upstream_addr, upstream_status, upstream_response_time, response_time, status,body_bytes_sent等等.通过udp抽样上报给storm集群，利用storm根据业务id，域名，api路径等分类实时分组计算，按5分钟纬度统计汇总。原始日志落地至hdfs，供故障定位时查看。

这样，每个业务的http状态码占比，upstream后端健康度都可以监控起来，并设置指标告警。

未完待续.....