记一次 ASP.NET Core Web API 启动崩溃分析（上）

Answer 1

某个周日的中午，突然接到领导电话："线上服务崩了，怎么回事！？"，让人血压瞬间上升，尽管机器配置豪华且部署简单，问题依然悄然浮现。项目采用的是微信小程序后端Web API，基于 ASP.NET Core 7.0，部署在IIS 10.0中。启动假死的问题，让服务在某段时间偶尔出现应用假死的情况，而这种现象伴随着系统日志的异常和服务器性能指标的波动。

通过对IIS请求日志的分析，发现回收前请求正常，回收时日志中断。服务重启期间大量请求时长超过1000ms，而启动失败则会导致长时间的日志中断，并且出现大量的503响应。而服务仅在读取配置文件时进行少量本地文件操作，但问题的根源仍未解决。

问题背后，我们意识到忽略了小问题的严重性。随着用户量的增长，上线后的问题逐渐凸显，多次尝试在业务需求间寻找平衡，如提前发布维护公告、选择低用户量的时间进行部署，虽然在一定程度上缓解了问题，但问题并未得到根本解决。最终，那个周日的崩溃促使我们重新审视和定位问题的原因。

我们需要理解，崩溃的直接原因是IIS的回收机制，它可能导致在特定的时间点发生崩溃。进一步地，通过查看事件查看器，发现是IIS在回收进程时引发了问题，这是因为进程回收可能在用户流量较大的时间段进行，导致服务在启动时遇到并发请求的瓶颈。通过在特定时间点调整IIS的回收配置，我们发现可能的原因是启动阶段存在的问题与请求负载正相关。

在优化IIS回收配置后，服务在特定时间点的崩溃得到了缓解，但我们继续探索，发现负载均衡定期的健康检查也成为了问题的新来源。通过调整负载均衡的健康检查频率，我们不仅确保了服务的正常运行，还为后续调查深层原因铺平了道路。在不断尝试与优化后，最终找到了问题的根源，并采取了有效的应对措施。