kong笔记——认识kong

背景

最近公司打算重构API网关，给定的硬性条件是支持lua脚本，kubernetes可部署，可解析lua，另外需要支持身份认证，IP黑白名单，限流，负载均衡等一些功能，为此，在技术选型上锁定了kong以及APISIX，最终选择了kong。

为什么选择kong

其原因如下：

1. 社区活跃度高，遇到问题可以及时解决（github目前已经30.2k star了）；

2. 成熟度，性能好（kong是基于nginx衍生出的一个openResty应用）

3. 拓展性好，功能相对齐全，耦合低

   • 以lua插件的方式进行业务功能拓展；
   • 自身支持API网关的基本特性(权限控制，安全，负载均衡，请求分发，监控等等),无需重新开发
   • 一个独立的应用，与框架无耦合

   举一个例子：Zuul，其自身只提供基本的路由功能，如果想使用其他功能，就需自研，而这些成本是很高的，另外，他与spring cloud深度集成，就需要引入其他的框架；

   另外，附一个性能测试链接：Kong1.4 vs SC Gateway2.2 vs Zuul1.3 性能测试

目前市面上的开源的API网关除了kong还有：

1. Traefik

   Traefik 是一个现代 HTTP 反向代理和负载均衡器，可以轻松部署微服务，Traeffik 可以与您现有的组件（Docker、Swarm，Kubernetes，Marathon，Consul，Etcd，…）集成，并自动动态配置。

2. Ambassador

   Ambassador 是一个开源的微服务 API 网关，建立在 Envoy 代理之上，为用户的多个团队快速发布，监控和更新提供支持，支持处理 Kubernetes ingress controller 和负载均衡等功能，可以与 Istio 无缝集成。

3. Tyk

   Tyk是一个开源的、轻量级的、快速可伸缩的 API 网关，支持配额和速度限制，支持认证和数据分析，支持多用户多组织，提供全 RESTful API。基于 go 编写。

4. Zuul

   Zuul 是一种提供动态路由、监视、弹性、安全性等功能的边缘服务。Zuul 是 Netflix 出品的一个基于 JVM 路由和服务端的负载均衡器。

其对比如下：

	Kong	Traefik	Ambassador	Tyk	Zuul
基本
主要用途	企业级API管理	微服务网关	微服务网关	微服务网关	微服务网关
学习曲线	适中	simple	simple	适中	simple
成本	开源/企业版	开源	开源/pro	开源/企业版	开源
社区star	20742	21194	1719	4299	7186
配置
配置语言	Admin Rest api, Text file(nginx.conf 等)	TOML	YAML(kubernetes annotation)	Tyk REST API	REST API，YAML静态配置
配置端点类型	命令式	声明式	声明式	命令式	命令式
拖拽配置	yes	no	no	no	no
管理模式	configurable	decentralised, self-service	decentralised, self-service	decentralised, self-service	decentralised, self-service
部署
kubernetes	适中(k8s yaml,helm chart)	easy	easy	适中(k8s yaml,helm chart)	适中(k8s yaml,helm chart)
Cloud IAAS	high	easy	N/A	easy	easy
Private Data Center	high	easy	N/A	easy	easy
部署模式	金丝雀(企业版)	金丝雀	金丝雀，shadow	金丝雀	金丝雀
state	postgres,cassandra	kubernetes	kubernetes	redis	内存文件
可扩展性
扩展功能	插件	自己实现	插件	插件	自己实现
扩展方法	水平	水平	水平	水平	水平
功能
服务发现	动态	动态	动态	动态	动态
协议	http,https,websocket	http,https,grpc,websocket	http,https,grpc,websocket	http,https,grpc,websocket	http,https
基于	kong+nginx	traefik	envoy	tyk	zuul
ssl 终止	yes	yes	yes	yes	no
websocket	yes	yes	yes	yes	no
routing	host,path,method	host,path	host,path,header	host,path
限流	yes	no	yes	yes	需要开发
熔断	yes	yes	no	yes	需要其他组件
重试	yes	yes	no	yes	yes
健康检查	yes	no	no	yes	yes
负载均衡算法	轮询，哈希	轮询，加权轮询	加权轮询	轮询	轮询，随机，加权轮询，自定义
权限	Basic Auth, HMAC, JWT, Key, LDAP, OAuth 2.0, PASETO, plus paid Kong Enterprise options like OpenID Connect	basic	yes	HMAC，JWT，Mutual TLS，OpenID Connect，基本身份验证，LDAP，社交OAuth（例如GPlus，Twitter，Github）和传统基本身份验证提供程序	开发实现
tracing	yes	yes	yes	yes	需要其他组件
istio集成	no	no	yes	no	no
dashboard	yes	yes	grafana,Prometheus	yes	no

引用链接：微服务五种开源API网关实现组件对比

什么是kong

Kong 由Mashape公司开源，是一个在 Nginx 中运行的Lua应用程序，并且可以通过lua-nginx模块实现，Kong不是用这个模块编译Nginx，而是与 OpenResty 一起发布，OpenResty已经包含了 lua-nginx-module， OpenResty 不是 Nginx 的分支，而是一组扩展其功能的模块。

三者的关系如下：

• Nginx是模块化设计的反向代理软件，C语言开发:
• OpenResty是以Nginx为核心的Web开发平台，可以解析执行Lua脚本
• Kong是OpenResty的一个应用，是一个API网关，具有API管理和请求代理的功能

核心思想

实现数据库抽象，路由和插件管理，插件可以存在于单独的代码库中，并且可以在几行代码中注入到请求生命周期的任何位置。

透过kong的nginx文件，我们可以看出kong的生命周期：

server {
    server_name kong;
    listen 0.0.0.0:8000 reuseport backlog=16384;
    listen 0.0.0.0:8443 ssl http2 reuseport backlog=16384;

    rewrite_by_lua_block {
        Kong.rewrite()
    }

    access_by_lua_block {
        Kong.access()
    }

    header_filter_by_lua_block {
        Kong.header_filter()
    }

    body_filter_by_lua_block {
        Kong.body_filter()
    }

    log_by_lua_block {
        Kong.log()
    }

    location / {
        proxy_pass            $upstream_scheme://kong_upstream$upstream_uri;
    }

}

函数名	LUA-NGINX-MODULE Context	描述
:init_worker()	init_worker_by_lua	在每个 Nginx 工作进程启动时执行
:certificate()	ssl_certificate_by_lua	在SSL握手阶段的SSL证书服务阶段执行
:rewrite()	rewrite_by_lua	从客户端接收作为重写阶段处理程序的每个请求执行。在这个阶段，无论是API还是消费者都没有被识别，因此这个处理器只在插件被配置为全局插件时执行
:access()	access_by_lua	为客户的每一个请求而执行，并在它被代理到上游服务之前执行（路由）
:header_filter()	header_filter_by_lua	从上游服务接收到所有响应头字节时执行
:body_filter()	body_filter_by_lua	从上游服务接收的响应体的每个块时执行。由于响应流回客户端，它可以超过缓冲区大小，因此，如果响应较大，该方法可以被多次调用
:log()	log_by_lua	当最后一个响应字节已经发送到客户端时执行

部署

对于kong的部署，由于它是基于Nginx的，所以只需要添加多台服务器就可以配置成一个集群，通过前置的负载均衡配置把请求均匀地分发到各个 Server，来应对大批量的网络请求。

组件

共分为3大块：

1. kong server : 基于nginx的服务器，用来接收API请求。
2. Apache Cassandra/PostgreSQL ：用来存储操作数据。
3. Kong dashboard：官方推荐UI管理工具（缺点是仅仅可以集成kong2.0版本一下，不支持最新的kong版本！！），当然，也可以使用 restfull 方式 管理admin api。Konga另一款经典用于UI管理工具（可支持最新的kong版本）。

特性

• 可扩展: 通过简单地添加更多的机器，可以轻松地平行扩展，这意味着您的平台可以在一个较低负载的情况下处理任何请求。
• 模块化: 可以通过添加新的插件进行扩展，这些插件可以通过RESTful Admin API轻松配置。
• 在任何基础架构上运行: Kong可以在任何地方都能运行。您可以在云或内部部署环境中部署Kong，包括单个或多个数据中心设置，以及public，private 或invite-only APIs。

• Kong核心基于OpenResty构建，实现了请求/响应的Lua处理化；
• Kong插件拦截请求/响应，如果接触过Java Servlet，等价于拦截器，实现请求/响应的AOP处理；
• Kong Restful 管理API提供了API/API消费者/插件的管理；
• 数据中心用于存储Kong集群节点信息、API、消费者、插件等信息，目前提供了PostgreSQL和Cassandra支持，如果需要高可用建议使用Cassandra；
• Kong集群中的节点通过gossip协议自动发现其他节点，当通过一个Kong节点的管理API进行一些变更时也会通知其他节点。每个Kong节点的配置信息是会缓存的，如插件，那么当在某一个Kong节点修改了插件配置时，需要通知其他节点配置的变更。

具体如下：

• 云原生: 与平台无关，Kong可以从裸机运行到Kubernetes
• 动态路由：Kong 的背后是 OpenResty+Lua，所以从 OpenResty 继承了动态路由的特性
• 基于hash的负载均衡：基于hashing/sticky session的负载均衡
• 断路器：能追踪不健康的upstream services
• 健康检测：对upstream services进行主动或者被动地监控
• 服务发现：可结合consul提供服务注册等功能
• WebSockets：通过WebSockets和upstream service进行通信
• OAuth2.0：可对API方便地添加OAuth2.0进行授权
• 日志：通过HTTP/TCP/UDP等方式进行日志相关操作
• 安全：ACL，机器人检测，黑白名单IP等
• 系统日志：日志可输入到系统日志中
• 监控：提供实时监控功能
• 认证：HMAC/JWT以及基本认证方式
• 限流（Rate-Limiting）：基于多变量对请求进行阻塞或者限制
• 转换：对TTP请求和相应进行添加/删除/操纵等操作
• 缓存：在代理层进行缓存和响应处理
• CLI：通过命令行对kong的集群进行控制
• REST API：可灵活地通过RESTful API对kong进行操作
• 失败检测与恢复：Cassandra某一节点停止也不会影响kong的功能
• 集群：所有的kong节点都能自动加入集群，并保证配置在整个节点间得到更新
• 可扩展性：kong可以通过添加节点很容易地实现横向扩展
• 性能：使用nginx作为内核，kong具有nginx的高性能
• plugin：可以对kong和API进行扩展

插件

目前已经提供的插件有:

1. 身份认证插件：Kong提供了Basic Authentication、Key authentication、OAuth2.0 authentication、HMAC authentication、JWT、LDAP authentication认证实现。
2. 安全控制插件：ACL（访问控制）、CORS（跨域资源共享）、动态SSL、IP限制、爬虫检测实现。
3. 流量控制插件：请求限流（基于请求计数限流）、上游响应限流（根据upstream响应计数限流）、请求大小限制。限流支持本地、Redis和集群限流模式。
4. 分析监控插件：Galileo（记录请求和响应数据，实现API分析）、Datadog（记录API Metric如请求次数、请求大小、响应状态和延迟，可视化API Metric）、Runscope（记录请求和响应数据，实现API性能测试和监控）。
5. 协议转换插件：请求转换（在转发到upstream之前修改请求）、响应转换（在upstream响应返回给客户端之前修改响应）。
6. 日志应用插件：TCP、UDP、HTTP、File、Syslog、StatsD、Loggly等。

kong目前提供了37个插件，其中商业收费7个，30个开源免费的插件，可以设定到api/服务/路由粒度上，详情如下：

类别	免费/收费	name	插件名	使用场景
认证	免费	basic-auth	Basic Authentication	对于服务或者路由提供用户名/密码基本认证机制
认证	免费	key-auth	Key Authentication	对于服务或者路由提供用关键字认证机制
认证	收费	-	OpenID Connect	提供与三方OpenID的集成方式
认证	免费	oauth2	OAuth 2.0 Authentication	添加OAuth 2.0认证
认证	收费	-	OAuth 2.0 Introspection	提供与三方OAuth 2.0认证服务器的集成方式
认证	免费	hmac-auth	HMAC Authentication	提供HMAC（Hashed Message Authentication Code）签名认证方式
认证	免费	jwt	JWT	提供JWT(JSON WEB Token)的认证方式
认证	免费	ldap-auth	LDAP Authentication	提供了与LDAP认证服务器的集成方式
安全	免费	acl	ACL	通过ACL(Access Control List)的组名称对服务或者路由进行黑白名单的访问控制
安全	免费	cors	CORS	对服务或者路由提供CORS支持
安全	免费	ip-restriction	IP Restriction	通过IP地址对服务或者路由进行黑白名单的访问控制
安全	免费	bot-detection	Bot Detection	对服务或者路由提供机器人检出并能进行黑白名单的设定
安全	免费	ssl	Dynamic SSL	对路由或者API提供ssl支持
流量控制	收费	-	EE Canary Release	提供金丝雀发布支持
流量控制	收费	-	EE Forward Proxy	提供企业内网中前向代理的支持
流量控制	收费	-	EE Proxy Caching	提供代理缓存的加速功能
流量控制	免费	request-size-limiting	Request Size Limiting	可以对请求的body的size进行限制
流量控制	免费	rate-limiting	Rate Limiting	提供对给定时间段HTTP请求数目的控制功能
流量控制	收费	-	EE Rate Limiting	CE版本Rate Limiting的强化
流量控制	免费	response-ratelimiting	Response Rate Limiting	基于用户响应Header的信息，提供对HTTP请求数目的控制功能
流量控制	免费	request-termination	Request Termination	根据响应的状态码和信息，可停止对某个服务或者路由的流量
Serverless	免费	aws-lambda	AWS Lambda	调用和管理AWS Lambda函数
Serverless	免费	openwhisk	Apache OpenWhisk	调用和管理OpenWhisk
分析&监控	免费	zipkin	Zipkin	提供兼容zipkin的方式对用户请求进行追踪
分析&监控	免费	datadog	Datadog	可将API的指标信息在datadog上进行可视化地展示
分析&监控	免费	runscope	Runscope	结合runscope进行API性能测试和监控
转换	免费	request-transformer	Request Transformer	通过kong对请求进行转换
转换	收费	-	EE request Transformer	request Transformer的强化版
转换	免费	response-transformer	Response Transformer	通过kong对响应进行转换
转换	免费	correlation-id	Correlation ID	通过kong实现请求和响应之间的关联
日志	免费	tcp-log	TCP	发送请求和响应日志到TCP服务器
日志	免费	udp-log	UDP	发送请求和响应日志到UDP服务器
日志	免费	http-log	HTTP	发送请求和响应日志到HTTP服务器
日志	免费	file-log	File	发送请求和响应日志到磁盘的文件中
日志	免费	statsd	StatsD	发送请求和响应日志到StatsD服务器
日志	免费	syslog	Syslog	发送请求和响应日志到syslog中
日志	免费	syslog	Loggly	发送请求和响应日志到Loggly服务器

kong的架构

从技术的角度讲，Kong 可以认为是一个 OpenResty 应用程序。 OpenResty 运行在 Nginx 之上，使用 Lua 扩展了 Nginx。 Lua 是一种非常容易使用的脚本语言，可以让你在 Nginx 中编写一些逻辑操作。之前我们提到过一个概念 Kong = OpenResty + Nginx + Lua，但想要从全局视角了解 Kong 的工作原理，还是直接看源码比较直接。我们定位到本地的 Kong 文件夹，按照上图中的目录层级来识识 Kong 的庐山真面目。

1. Kong 文件下包含了全部源码和必要组件，分析他们，我们便得到了 Kong 的架构。0.13.x 是目前 Kong 的最新版本。
2. 从 2 号块中可以看到 nginx.conf ，这其实便是一个标准的 Nginx 目录结构，这也揭示了 Kong 其实就是运行在 Nginx 的基础之上，而进行的二次封装。由 share 文件夹向下展开下一次分析。
3. share 文件夹中包含了 OpenResty 的相关内容，其实背后就是一堆 Lua 脚本，例如 lapis 包含了数据库操作，Nginx 生命周期，缓存控制等必要的 Lua 脚本，logging 包含了日志相关的 Lua 脚本，resty 包含了 dns，健康检查等相关功能的 Lua 脚本…而其中的 kong 目录值得我们重点分析，他包含了 Kong 的核心对象。
4. api 和 core 文件夹，封装了 Kong 对 service，route，upstream，target 等核心对象的操作代码（这四个核心对象将会在下面的小节重点介绍），而 plugins 文件夹则是 Kong 高可扩展性的根源，存放了 kong 的诸多扩展功能。
5. plugins 文件夹包含了上一节提到的 Kong 的诸多插件功能，如权限控制插件，跨域插件，jwt 插件，oauth2 插件…如果需要自定义插件，则需要将代码置于此处。

从上述文件夹浏览下来，大概可以看到它和 Nginx 的相似之处，并在此基础之上借助于 Lua 对自身的功能进行了拓展，除了 nginx.conf 中的配置，和相对固定的文件层级，Kong 还需要连接一个数据库来管理路由配置，服务配置，upstream 配置等信息，是的，由于 Kong 支持动态路由的特性，所以几乎所有动态的配置都不是配置在文件中，而是借助于 Postgres 或者 Cassandra 进行管理。

Kong 对外暴露了 Restful API，最终的配置便是落地在了数据库之中。

引用链接：https://mp.weixin.qq.com/s/CWGy6cwy6QGLvwByurEGbw

kong的应用

API 网关可以通过实现一些中间件来解决一些问题，这些中间件的功能你就不用再到每个service中实现了。你也是知道的，不同的团队使用不同的方式来实现了不同的微服务。

如果你不去做一些中心化和抽象化的事情，你将会死于不同的认证方式以及不同的速率限制实现，五花八门。你肯定希望避免这样的糟糕局面。

API网关不仅可以帮你解决API的管理部分，而且还可以解决下面两件事情：

• 分析（Analytics） – API网关可以和你的分析基础设施保持透明的交互和通信，因为API网关是每个请求（request）的入口，必经地。API网关可以看到所有的数据，可以知道经过你的service的流量。这就相当于你有一个集中的地方，你可以把所有的这些信息push到你的监控或分析工具，比如Kibana或者Splunk。
• 自动化（Automation） –网关还有助于自动化部署，还可以帮助你实现自动化登入验证（on boarding）。 什么是登入（on boarding）呢？ 如果你有API，并且你希望有身份验证，你可能需要一些功能可以允许用户为该API创建登入凭据（credentials）然后开始使用（消费）API。 开发人员门户网站或你的文档中心等都可以与网关集成来配置这些凭据（credentials），这样你就不用从头开始构建一些功能了。

Kong作为API网关提供了API管理功能，及围绕API管理实现了一些默认的插件，另外还具备集群水平扩展能力，从而提升整体吞吐量。Kong本身是基于OpenResty，可以在现有Kong的基础上进行一些扩展，从而实现更复杂的特性。

虽然有一些特性Kong默认是缺失的，如API级别的超时、重试、fallback策略、缓存、API聚合、AB测试等，这些功能插件需要企业开发人员通过Lua语言进行定制和扩展。

拓展

为什么需要API网关

传统方式的四大痛点：

痛点	说明
重复多	在多个微服务中，共通的功能重复，比如认证或者日志相关共通模块
巨石化	单个服务仍然后变成尾大不掉的巨石应用的趋势
影响大	影响较大，很难做到扩展功能而能不影响其他服务
效率低	由于系统限制，导致生产性低下

加了网关之后：

如何选择微服务 API 网关：对比 Kong、APISIX、Tyk、Apigee 和其他网关: 主要说明了API网关的作用，以及API网关在选型上的注意点是什么

总结

kong作为一款API网关的应用实现，其优点很明显：

1. 自带一些API网关的基本特性，无需再次开发，即开箱即用；
2. 基于nginx开发，性能好；
3. 拓展性好，如果自带的插件不满足生产，可自行开发插件，不过需要会lua语法；
4. 有可视化的dashboard，方便查看。