“老谭，系统访问不上，访问经常被拒绝，已经持续两个小时了，赶紧排二线专家过来解决！”医保局领导语气强硬又略带一丝焦虑的打电话。这时候共保体的运维人员也在一个个的呼叫，让人感觉不妙，随即带着架构师赶赴现场。

原来笔者有幸参与了某地区医保局的惠民保平台的建设，这个平台从功能角度来说，并不复杂，但这个服务是针对该地区接近1000万人口做的惠民项目，而且联合共保体单位实行地毯式的推广，系统上线几天后，随着数据量的增加，参与该项目的用户也在这几天达到了顶峰，系统终于扛不住了。

问题分析

出现问题后，我们将各个链路进行了逐一分析，包括nginx、网关、服务、连接池、数据库。

1、nginx

nginx在系统故障时，频繁出现499 500错误，经分析发现服务器正常，出现问题的原因是后端服务超时导致。

2、 网关

spring cloud gateway负责转发nginx的请求，发生故障时，经过网关的请求有些直接返回，经分析，是由于服务发生熔断，提交给应用的请求直接返回失败。

3、服务

平台提供的接口是整个系统的压力点，发生故障时，系统并发数达到了1000+，经排查应用日志，发现几个问题点：

a 系统频繁打印job相关日志

b 某些请求响应时间较长

c 高峰时并无应用日志产生。

分析发现造成此现象的原因是：

a 惠民保和公服使用了一个任务调度实例，但是系统时间不一致，造成应用频繁请求数据库

b 系统高峰时，各个线程频繁占用连接池资源，造成系统拥堵，某些请求超时，从而触发熔断

c 发生熔断后，应用处于关闭状态，不接收任何请求，5s后处于半关闭状态，根据实际请求判断打开或关闭服务。

4 连接池

发生故障时，数据库连接池处于繁忙状态，偶尔会由于数据库的超时查询导致连接关闭，从而发生新建连接的行为，此时会出现创建连接失败的情况。经分析数据库的最大连接数较小，导致并发能力较弱。

5 数据库

高峰时，数据库的处理能力有所下降，经分析有慢查询存在，导致查询性能较低，同时Mysql数据库未经调优，高并发场景下会存在瓶颈。

尝试解决

1 修改连接池配置

连接池最大连接数改为200，防止高并发下请求过度等待造成熔断

2 优化数据库配置

对数据库参数进行简单调优，并进行监控，根据实际情况进行后续调整，同时增加索引，提高查询性能

3 停止job服务

系统中并未使用job服务，停止job服务可减轻服务器压力，同时防止由于校时问题导致的服务频繁刷库问题

4 同步时间服务器

将两个应用服务器的时间统一

性能优化

虽然把所有环节都进行了排查和优化，系统的故障排除，在未来的时间里虽然出现偶尔的超时拒绝服务，好在没有太大的问题。问题虽然解决，但留在心头的一块心病是并没有完全的定位真正导致问题的原因，最后从最终调用方的日志初步分析此次故障的最大原因是死锁导致服务超时，最终导致熔断，服务被拒绝。而死锁的原因来自于：

1、两台应用服务器时钟不一致，导致分布式调度系统的两台应用服务器频繁的更新数据库。

调整服务器时钟，并去掉了没有用到的分布式调度。

2、两个业务表迅速突破上百万的数据，程序人员一个业务逻辑join两个大表导致了慢查询。

优化了数据结构，增加了冗余信息和调整了SQL语句，减少没必要的join查询。

3、在医保系统和惠民保系统之间交互过程中，支付前、提交订单、同步订单等几个环节都有检查参保人资格的操作，看似安全保险，其实没啥必要。

后来和上海保交所开发的惠民保的人员沟通后，减少了参保人资格检查的环节，提升了系统交互的效率。

总结

1、我们团队过去开发的系统所处的应用场景，都没有高并发的场景，团队缺乏应对高并发的场景，经过这次考验，也让团队在高并发架构方面开始重视，并会加强学习。

2、事故发生后，一线人员没有及时的沟通，没有第一时间定位问题，优化系统，导致处理时间过长，引起客户的过度关注，研发和运维的配合也出现问题，这个需要建立故障处理的协同机制。

3、开发人员只会编写业务代码，对于数据库SQL编程比较轻视，SQL语句存在各种性能的问题，对于数据的调优、索引的建立经验不足，对于网络拓扑结构、请求链的环境不熟悉，很难定位问题。

高并发场景在互联网应用中可能普遍存在，但是对于很多TO B 场景的应用开发中可能比较少，这也导致我们做TO B场景软件产品的团队比较轻视，需要加强学习。另外高性能架构也不是一蹴而就的设计出来，高并发的场景下很多不为人知的问题，会随着系统的发展而不断的暴露出来，珍惜每一次出问题的机会，通过解决问题的方式学习优化，让高性能架构在事故之后浴火而生。

笔者这里有一套性能优化的技术图谱，对于你做性能优化会有很大的帮助，私信回复“性能优化”后获取。