关于Kong API Gateway测试的心得

近期公司有计划上API Gateway，其中找到两种开源的方案，一个叫Kong(基于Nginx_Lua模块写的)，一个叫Tyk（GO语音写的）。安排运维的兄弟安装Kong，并且对Kong进行了压力测试。

Kong的安装可以通过官方给的rpm,deb包进行安装，也可以通过源码安装，只不过通过源码安装可以对OpenResty进行定制化安装，加入其他的模块进去。在调研的过程中，对于使用Kong，个人认为有如下的注意事项：

1、存储配置信息用什么来存

    官方提供了cassandra和postgre，考虑到公司有DBA，在使用postgre时相对来说比cassandra更加有优势，遂选择了postgre，只不过在API较多的时候需要考虑到postgre的复制和高可用。

2、Kong的使用有两种方式，一种应用通过携带Host头部来增加API应用，另一种是通过不同的uri来提供API应用。两种方式对OpenResty的使用方式都是基于动态增加upstream以及对upstream的DNS resolver来实现。

3、基于第2条，Kong的部署方式我最初的架构图如下

最初方案因没有考虑到后端提供API服务的OpenResty有2台，所以遗漏了DNS在方案中的作用。目前我们使用PowerDNS,想让两台OpenResty的API应用正常工作要么使用Keepalived+OpenResty的方式为Kong提供VIP，要么让Kong上的DNS可以支持DNS轮询。前者始终有一台机器出于不服务状态，后者需要对PowerDNS做集群才可以支持DNS RR。于是乎将方案做了调整变为如下结构：

调整后的方案直接给Kong的服务器提供公网IP，使用双线并做HA，当然调整后的方案依然需要DNS的支持，查找了默认就支持DNS RR的DNS SERVER，找到了SkyDNS，所以Kong服务器上的DNS改为由SkyDNS来承担。

4、在测试过程中发现Kong虽然可以动态添加upstream，但是Upstream中却不支持keepalive指令，在压测的时候OpenResty API Server上有大量的TIME-WAIT连接，测试用的版本为0.8.3，后来在github提交了问题询问此时，得知在0.10的版本中将支持upstream中的keepalive指令。

5、压测的结果

在OpenResty API Server上生成4K的html页面，用wrk进行测试，Kong的每秒请求数为16000/S，平均响应时间40ms

6、Kong的kong.yml是其主配置文件，在部署的时候一定要优化Nginx的配置部分，至于怎么优化可以参考我之前写的关于Nginx的优化