一、背景
在生产环境，后端服务的接口响应非常慢，是因为数据库未创建索引导致。
如果QPS低的时候，因为后端服务有6个高配置的节点，虽然接口慢，还未影响到服务的正常运行。
但是，当QPS很高的时候，因为慢接口的访问会分散到所有节点，所以最后导致整个服务的6个节点都宕机假死了。
这个时候，服务的健康状态已经是不健康了，从两个方面可以观察出来：
-
服务注册中心consul的服务健康检测
-
k8s容器的pod 探针检测（livenessProbe和readinessProbe）
服务的整体响应时间慢，包括/health健康检测接口的响应超时，所以此时健康状态是异常。
K8S容器的Pod因为探针检测服务是不健康的，所以会不断地重启。
因为服务的Slow start–慢启动，加上我们没有对后端服务进行逐步放量的机制，导致服务刚启动，在高QPS的时候，外部请求又大量地请求进来，新启动的服务终被拖垮。
所以下面的两个处理方案都被证明是失败的：
- 1、重启大法，这个可以解决jvm的full gc等内存问题，但是搞不定高qps的慢接口。
- 2、原先的6个节点扩容至10个，也是枉然，仍无济于事。
问题的正确解决方案应该是限流或熔断。
二、kong的熔断
熔断限流，是需要基于服务的指标来定的。除了购买云上的一些服务外，业界有sentinel这样的开源项目，但我们都没有接入。
也就是说，我们只能祈求不要大量访问我们的慢接口了，让我们的服务喘口气，否则缓不过来。
显然，这个也不现实，主动权交给用户，呵呵~~
幸运的是，我们在java服务的上层还有一个kong网关，
kong，作为api网关，具备以下作用：
- 隔离外网系统与内网系统
- 通过解耦，使得微服务系统的各方能够独立、高效；网关实现非功能性的要求
- 脚手架，方便通过扩展机制对请求进行一系列加工和处理
- 为服务熔断，灰度发布，线上测试提供方案
这里，我们就要介绍一种手动熔断的处理办法。
要做熔断，前提是找出慢接口，也即被熔断的对象。
1、新建路由route
2、配置插件pre-function
在新建的路由下，配置插件pre-function，对慢接口进行拦截，不让请求到后端服务。
这就是隔离外网系统与内网系统的好处。
另外插件式的配置，让kong作为api网关，扩展性的作用表现得非常明显。
编写function的内容：
return kong.response.exit(503, '{code: 400, msg: "该功能暂不可用，请稍后再试！"}', {["Content-Type"] = 'application/json' })
三、总结
本文通过线上实际发生的一个生产事故，梳理了我们的解决思路，对于高频慢接口的访问，最后只能通过kong的熔断来解决。
事实证明，重启银弹和扩容银弹并不适用此，对于fullgc等jvm内存问题可能适用。
这个生产事故，也给我们一个提醒，需要及时排查慢接口和数据库的慢查询，它们就像是航船的漏洞一样，小洞如果不及时堵上，等变大了，想堵就来不及了。
