[toc]
## 问题:

自7/4 以来, 所有设备同时出现 Network Error, 导致业务无法正常进行, 频率 3次/每分钟;

## 现场情况及原因分析:
3楼: 8条产线
4楼: 20条产线
5楼: 5条产线
点数: 33条线 * 平均 (5台工位 + 1台电视看板 + 3台测试仪 + ) ≈ 300

- Nginx 日志占用: access 日志 100G 单个文件, error 日志 单个文件 76MB

- 设备资源占用正常

### 问题原因
通过查看Nginx 错误日志, 发现大量报错 no live upstreams while connecting to upstream

2023/07/06 11:28:43 [error] 42652#57660: *4922556 no live upstreams while connecting to upstream, client: xx, server: localhost, request: "OPTIONS /api/Axx HTTP/1.1", upstream: "http://myapp/api/xx", host: "xx", referrer: "xx"

upstream中没有可以提供服务的server ，即nginx已经发现不了存活的后端了,但是,我直接访问后端的server确是可以使用的,证明server端可用.
最后查找文档,发现问题出现在业务上要求保持会话,但是nginx到后端并没有保持会话,那么,nginx找不到后端可用服务,就会报no live upstream
参考文档:
https://nginx.org/en/docs/http/ngx_http_upstream_module.html

## 临时方法及验证

12:20 修改 max_fails=3 fail_timeout=60s
13:30 卡顿持续(每分钟3次左右, 报错网络错误)
14:13 修改  keepalive 配置
14:42  卡顿一次 (表现不同, 等待响应)
15:09  卡顿一次 (表现不同, 等待响应)
16:00  卡顿一次 (表现不同, 等待响应 )

## 根本原因分析

后端服务响应时间过长导致Nginx 自动剔除节点, 最终所有节点不可用直接拒绝连接;

## 改善建议
1. 修改Nginx 配置:
1.1 增加   keepalive 配置, 这个值并没有一个固定的值, 需要综合结合资源、服务使用情况来具体配置, 一般为节点数的2倍;
1.2 调整 access 日志级别;
1.3 日志增加归档功能;
2. 优化报工相关接口;
3. 看板服务分离;
4. 数据库数据归档;

## 扩展内容

upstream 参数

| #  | 参数名  |     作用                          |
| -- | -- | ------------ |
| 1  | server  | 配置 server 节点下的 location 节点中的 proxy_pass 反向代理  |
| 2 |  weight | 指定轮询几率(weight)，weight 和访问比率成正比，用于后端服务器性能不均的情况  |
| 3  | ip_hash  | 每一个请求按訪问ip的hash结果分配(ip_hash)。这样每一个訪客固定訪问一个后端服务器，能够解决 session 的问题  |
| 4  | fair  |  按后端服务器的响应时间来分配请求(fair)。响应时间短的优先分配。与weight分配策略相似。 |
| 5  |   keepalive      |    长连接缓存池大小为32 |
| 6  |   keepalive_requests 2000 | 每条长连接最大复用请求数为2000  |
| 7 |  keepalive_time  |   |
| 8 |  keepalive_timeout  |   |