Kong 在好大夫的落地实践

Kong 在好大夫的落地实践

API 网关(API-Gateway)是整体系统的唯一入口，作为流量入口，统一处理请求。它具有以下传统的功能：

• 反向代理和负载均衡；

• 动态上游、动态 SSL 证书和动态限流限速等运行时的动态功能；

• 对上游的主动和被动健康监测。

其他附加功能：

• 身份认证，限流熔断，统计，性能分析等。

网关主要有两种类型:

• 接入层网关，为多样的客户端提供统一的流量入口，通过不同路由策略进行负载均衡，主要负责的是路由，限流，日志，缓存等功能,我们使用的是Kong；

• 应用层网关，提供服务注册、服务发现以及熔断功能，我们当前使用的是sidecar(ZuulFilter)。

好大夫的接入层网关最初使用的 nginx，在 2020 年初替换成 Kong。

2.1 为什么我们用 Kong 替换现有的 Nginx？

名词解释：

• BFF（Backend For Frontend）聚合层：将后端微服务适配到不同前端；

• Sidecar：我们使用的应用层网关，实现异构语言的服务注册和发现，以及熔断限流功能；

• Microservices：微服务。

先聊一聊好大夫在线的架构:

1. API网关层，提供客户端流量的唯一入口，用于做反向代理和负载均衡，最初使用的nginx提供一些如路由、缓存、访问控制等基本功能；

2. BFF层，我们主要有PHP（老）和NodeJs（新）两类，这一层主要是做接口聚合，以及业务逻辑层的权限验证等；

3. BackEnd层，是我们的微服务层，是多语言实现的(php,java,python)，其中php,python通过sidecar注册到Eureka上，java本身支持服务注册和发现到Eureka。

我们引入网关 Kong 的契机是线上的流量有一部分是模拟用户抓取类流量，它的特点在于 QPS 的波动很大，当一波集中的抓取到来时，BackEnd 服务可能会因为 QPS 突增，导致机器负载的升高，响应变慢，同时影响正常用户的访问。如果不及时处理可能会引起雪崩效应。

为了解决这个问题，我们需要细化区分各种流量，要有较强的识别和控制能力，以保障正常用户、正常抓取的流量，同时排除掉异常访问的流量。在未引入 Kong 之前，我们能想到的办法是在 Api 网关 nginx 层做流量控制，以及在我们的应用层网关 sidecar 做流量控制。但是这两种方案都有一定的问题：

1. 使用nginx进行流量限制，问题在于nginx的配置规则是以静态文件的形式进行管理的，无法通过api或者后台灵活的修改流量的封禁、降级和调度策略，同时配置生效需要reload；

2. 从我们的架构图可以看出，应用层网关Sidecar只负责处理服务出口的流量(即请求发起端)，发起端可能来自各个系统，因此通过Sidecar进行发起端限流，限流值设置的波动会非常大，粒度也因为过细而不好控制。

以上两种解决方案，对我们日常精细化运维流量都不够友好，所以经过调研，决定在接入层引入 Kong 来替换 nginx，进而从源头细化流量。

2.2 网关选型，为什么选择 Kong