kong笔记——认识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 路由和服务端的负载均衡器。

其对比如下：

引用链接：微服务五种开源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是运行在OpenResty，我们先来看一下OpenResty执行流程：

图出处：OpenResty 执行流程阶段

• init_by_lua： master进程启动后的回调。
• init_worker_by_lua：nginx worker进程启动后的回调。
• rewrite_by_lua：request进来后首先经过rewrite，可以改写URL等。
• access_by_lua：request路由完成之后，进一步处理之前，可以修改request。
• header_filter_by_lua：response准备返回之前，可以修改header。
• body_filter_by_lua：response准备返回之前，可以修改body。
• log_by_lua：用于请求的日志记录。

Kong通过在 openresty 各个阶段加入了lua代码来实现插件的注入和执行，Kong 的 nginx 配置：

init_by_lua_block {
    kong = require 'kong'
    kong.init() // 完成 Kong 的初始化,路由创建，插件预加载等
}
init_worker_by_lua_block {
    kong.init_worker() // 初始化 Kong 事件, worker 之间的事件，由 worker_events 来处理, cluster 节点之间的事件，由 cluster_events 来处理，缓存机制
}

upstream kong_upstream {
    server 0.0.0.1;
    balancer_by_lua_block {
        kong.balancer() //负载均衡
    }
    keepalive 60;
}
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() //插件生效策略的筛选,并执行对应的操作，只能处理全局插件(kong插件级别，全局(作用于所有请求),route(作用于当前路由)，service(作用于匹配到当前service的所有请求))，路由匹配未开始。
    }
    access_by_lua_block {
        kong.access() //1.完成路由匹配，2.确认加载的插件(并加入缓存) 3.进入balancer阶段
    }

    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;
    }

}

部署

对于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/服务/路由粒度上，详情如下：

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，方便查看。