api gateway kong融合高频慢速接口 - I. 背景情况

在生产环境，后端服务的接口响应非常慢，是因为数据库未创建索引导致。
如果QPS低的时候，因为后端服务有6个高配置的节点，虽然接口慢，还未影响到服务的正常运行。
但是，当QPS很高的时候，因为慢接口的访问会分散到所有节点，所以最后导致整个服务的6个节点都宕机假死了。
这个时候，服务的健康状态已经是不健康了，从两个方面可以观察出来：

• 服务注册中心consul的服务健康检测
  

• k8s容器的pod 探针检测（livenessProbe和readinessProbe）

服务的整体响应时间慢，包括/health健康检测接口的响应超时，所以此时健康状态是异常。
K8S容器的Pod因为探针检测服务是不健康的，所以会不断地重启。

因为服务的Slow start–慢启动，加上我们没有对后端服务进行逐步放量的机制，导致服务刚启动，在高QPS的时候，外部请求又大量地请求进来，新启动的服务终被拖垮。

所以下面的两个处理方案都被证明是失败的：

• 1、重启大法，这个可以解决jvm的full gc等内存问题，但是搞不定高qps的慢接口。
• 2、原先的6个节点扩容至10个，也是枉然，仍无济于事。

问题的正确解决方案应该是限流或熔断。