网关KONG详解

Kong概述
Kong是一个在Nginx运行的Lua应用程序，由lua-nginx-module实现。Kong和OpenResty一起打包发行，其中已经包含了lua-nginx-module。OpenResty不是Nginx的分支，而是一组扩展其功能的模块。

Kong是一款基于OpenResty（Nginx + Lua模块）编写的高可用、易扩展的，由Mashape公司开源的API Gateway项目。Kong是基于NGINX和Apache Cassandra或PostgreSQL构建的，能提供易于使用的RESTful API来操作和配置API管理系统，所以它可以水平扩展多个Kong服务器，通过前置的负载均衡配置把请求均匀地分发到各个Server，来应对大批量的网络请求。
Kong主要有三个组件：
Kong Server ：基于nginx的服务器，用来接收API请求。
Apache Cassandra/PostgreSQL ：用来存储操作数据。
Kong dashboard：官方推荐UI管理工具，当然，也可以使用 restfull 方式 管理admin api。
Kong网关插件
身份认证插件：Kong提供了Basic Authentication、Key authentication、OAuth2.0 authentication、HMAC authentication、JWT、LDAP authentication认证实现。
安全控制插件：ACL（访问控制）、CORS（跨域资源共享）、动态SSL、IP限制、爬虫检测实现。
流量控制插件：请求限流（基于请求计数限流）、上游响应限流（根据upstream响应计数限流）、请求大小限制。限流支持本地、Redis和集群限流模式。
分析监控插件：Galileo（记录请求和响应数据，实现API分析）、Datadog（记录API Metric如请求次数、请求大小、响应状态和延迟，可视化API Metric）、Runscope（记录请求和响应数据，实现API性能测试和监控）。
协议转换插件：请求转换（在转发到upstream之前修改请求）、响应转换（在upstream响应返回给客户端之前修改响应）。
日志应用插件：TCP、UDP、HTTP、File、Syslog、StatsD、Loggly等。
以及自定义插件
Kong网关请求流程
当Kong运行时，每个对API的请求将先被Kong命中，然后这个请求将会被代理转发到最终的API接口。在请求（Requests）和响应（Responses）之间，Kong将会执行已经事先安装和配置好的任何插件，授权您的API访问操作。Kong是每个API请求的入口点（Endpoint）。
Nginx配置 VS Kong配置
我们来看一个典型 Nginx 的配置对应在 Kong 上是怎么样的，下面是一个典型的 Nginx 配置
upstream passportUpstream {
server localhost:8080 weight=100;
}
server {
listen 80;
location /hello {
proxy_pass http://passportUpstream;
}
}
下面我们开看看其对应 Kong 中的配置

配置 upstream

curl -X POST http://localhost:8001/upstreams
–data “name=passportUpstream”

配置 target

curl -X POST http://localhost:8001/upstreams/passport/targets
–data “target=localhost:8080” --data “weight=100”

配置 service

curl -X POST http://localhost:8001/services
–data “name=getUserInfo” --data “host=passportUpstream”

配置 route

curl -X POST http://localhost:8001/routes
–data “paths[]=/user”
–data “service.id=8695cc65-16c1-43b1-95a1-5d30d0a50409”

curl -X POST http://localhost:8001/routes
–data “hosts[]=.example.com,test.com,.abc.com”
–data “service.id=8695cc65-16c1-43b1-95a1-5d30d0a50409”
这一切配置都是通过其 Http Restful API 来动态实现的，无需我们再手动的 reload Nginx.conf。
在上述的配置中涉及到了几个概念： Upstream、Target、Service、Route 等概念，它们是 Kong 的几个核心概念，也是我们在使用 Kong API 时经常打交道的
Kong关键术语/名词解析
Upstream
Upstream 对象表示虚拟主机名，可用于通过多个服务（目标）对传入请求进行负载均衡。例如：service.v1.xyz 为 Service 对象命名的上游 Host 是 service.v1.xyz 对此服务的请求将代理到上游定义的目标。 相当于nginx中的upstream
Target
目标 IP地址/主机名，其端口表示后端服务的实例。 upstream下的具体机器
Service
相当于nginx中proxy_pass中指定的路径，可以指向upstream也可以直接指向后端服务器
Route
路由实体定义规则以匹配客户端的请求。每个 Route 与一个 Service 相关联，一个服务可能有多个与之关联的路由。与给定路由匹配的每个请求都将代理到其关联的 Service 上。
相当于nginx中的listen和location两个值
Consumer
Consumer 对象表示服务的使用者或者用户。你可以依靠 Kong 作为主数据库存储，也可以将使用者列表与数据库映射，以保持Kong 与现有的主数据存储之间的一致性。
Plugin
插件实体表示将在 HTTP请求/响应生命周期 期间执行的插件配置。它是为在 Kong 后面运行的服务添加功能的，例如身份验证或速率限制。
Certificates
管理HTTPS的证书，上传至此处
APIs
已废弃，使用route和service
对应关系
Upstream : target -> 1:n
Service : Upstream -> 1:1 or 1:0 (Service 可以直接指向具体的 Target，相当于不做负载均衡)
Service : Route -> 1:n
Client 请求的流量通过 Route 指向与之相关的 Service，如果配置插件的话就会作用插件，Service 接到流量后给到相应的 Upstream 的服务上面。
Kong安装部署
这里主要使用下centos环境进行部署。
1、安装Kong
2、安装 PostgreSQL 9.5+
3、授权Kong数据库
4、导入Kong数据
5、启动Kong
6、验证Kong是否成功启动
Kong默认监听下面端口：
8000，监听来自客户端的HTTP流量，转发到你的upstream服务上。
8443，监听HTTPS的流量，功能跟8000一样。可以通过配置文件禁止。
8001，Kong的HTTP监听的api管理接口。
8444，Kong的HTTPS监听的API管理接口。
7、安装kong-dashboard图形化管理
Kong GUI界面
kong-dashboard 比较简单
Konga 功能比较强大，可以管理多个kong，需要配置konga的数据库，界面更友好