一、背景

在生产环境，后端服务的接口响应非常慢，是因为数据库未创建索引导致。
如果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内存问题可能适用。

这个生产事故，也给我们一个提醒，需要及时排查慢接口和数据库的慢查询，它们就像是航船的漏洞一样，小洞如果不及时堵上，等变大了，想堵就来不及了。