Azure App Service微服务架构性能排查：API与数据库瓶颈定位方法

1. 利用现有Application Insight定位异常请求 #

• 筛选生产时段慢请求：在AI的性能面板锁定用户反馈卡顿的时段，聚焦响应时间超阈值的请求，查看对应API实例、操作名称。
• 追踪请求依赖链：打开慢请求的端到端事务详情，查看每个请求调用的下游依赖（数据库、其他微服务）的耗时占比，若某依赖耗时远超预期，直接锁定可疑点。
• 排查隐藏异常：在失败和日志面板，检查卡顿时段是否有数据库连接超时、锁等待、未捕获内部错误等隐藏异常——这类问题常导致请求阻塞但不占用高CPU内存。
• 对比业务指标：若API上报了自定义业务指标（如订单处理量、队列长度），对比卡顿时段的指标波动，确认是否因业务突增引发资源争用。

2. API层面深入排查（排除数据库因素） #

• 启用实时诊断日志：打开App Service的日志流，实时查看卡顿时段的应用日志，重点排查线程阻塞、死锁、第三方服务调用延迟等信息。
• 采集运行时快照：在AI的性能面板对慢请求触发快照调试，获取请求执行时的线程堆栈，查看是否有线程卡在IO操作、同步锁等待或第三方SDK调用上。
• 检查隐藏资源瓶颈：查看App Service计划的文件IO使用率、网络带宽、连接数指标（PV3有连接数上限），高IO或带宽饱和也会导致卡顿，即使CPU内存正常。
• 验证实例伸缩：查看App Service的实例计数指标，确认卡顿时段自动伸缩是否正常，有无实例启动失败或未及时扩容的情况。

3. 数据库层面瓶颈排查 #

• 监控数据库核心指标：针对每个API的独立数据库，查看CPU使用率、内存、磁盘IO、连接数，重点关注查询等待时间（如SQL Server的等待统计），高等待时间意味着查询阻塞或资源争用。
• 捕获并分析慢查询：启用数据库的查询存储（如Azure SQL Query Store），筛选卡顿时段的慢查询，查看执行计划，检查是否存在缺失索引、全表扫描、锁等待问题。
• 验证连接池配置：检查API的数据库连接池参数（最大连接数、超时时间），结合数据库连接数指标，确认是否因连接池耗尽导致请求排队。
• 排查锁与阻塞：对于SQL类数据库，执行sp_who2或查询sys.dm_tran_locks视图，查看卡顿时段是否有长事务占据锁资源，导致其他请求阻塞。

4. 综合验证与根因确认 #

• 模拟压测复现：在非生产环境模拟相同业务量，触发卡顿场景，同时监控API和数据库的全量指标，定位瓶颈。
• 时段指标对比：将卡顿时段的AI请求耗时、数据库指标、App Service资源数据与正常时段对比，找出差异点（如某类请求占比突增、某查询执行时间翻倍）。
• 排查跨服务调用：若微服务间存在相互调用，查看调用链中的延迟数据，确认是否因下游API响应缓慢导致上游请求阻塞。

内容的提问来源于stack exchange，提问作者Saad Awan