kong 网关教程入门[通俗易懂]

大家好，又见面了，我是你们的朋友全栈君。

全栈工程师开发手册 （作者：栾鹏） 架构系列文章

为什么使用API-Gateway

1. 方便客户端维护– 每个请求方不用管理多个api url，统一访问api-gateway即可

2. 接口重构时调用方不须了解接口本身等拆分和聚合

3. 客户端无须关心接口协议

4. 统一权限控制、接口请求访问日志统计

5. 安全，是保护内部服务而设计的一道屏障

5. 开源-最大好处

当然也有一个很大的缺点，api-gw很可能成为性能瓶颈，因为所有的请求都经过这里，可以通过横向扩展和限流解决这个问题。

在众多API GATEWAY框架中，Mashape开源的高性能高可用API网关和API服务管理层——KONG（基于NGINX）特点尤为突出，它可以通过插件扩展已有功能，这些插件（使用lua编写）在API请求响应循环的生命周期中被执行。于此同时，KONG本身提供包括HTTP基本认证、密钥认证、CORS、TCP、UDP、文件日志、API请求限流、请求转发及NGINX监控等基本功能。目前，Kong在Mashape管理了超过15,000个API，为200,000开发者提供了每月数十亿的请求支持。

Kong是一款基于Nginx_Lua模块写的高可用，由于Kong是基于Nginx的，所以可以水平扩展多个Kong服务器，通过前置的负载均衡配置把请求均匀地分发到各个Server，来应对大批量的网络请求。

kong架构

Kong主要有三个组件：

Kong Server ：基于nginx的服务器，用来接收API请求。 Apache Cassandra/PostgreSQL ：用来存储操作数据。 Kong dashboard：官方推荐UI管理工具，当然，也可以使用 restfull 方式 管理admin api。

Kong采用插件机制进行功能定制，插件集（可以是0或N个）在API请求响应循环的生命周期中被执行。插件使用Lua编写，目前已有几个基础功能：HTTP基本认证、密钥认证、CORS（Cross-Origin Resource Sharing，跨域资源共享）、TCP、UDP、文件日志、API请求限流、请求转发以及Nginx监控。

Kong网关的特性

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网关插件

身份认证插件：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的请求将先被Kong命中，然后这个请求将会被代理转发到最终的API接口。在请求（Requests）和响应（Responses）之间，Kong将会执行已经事先安装和配置好的任何插件，授权您的API访问操作。Kong是每个API请求的入口点（Endpoint）。

helm 安装

先创建pv

kind: PersistentVolume
apiVersion: v1
metadata:
  name: kong-postgre
  labels:
    release: stable
spec:
  capacity:
    storage: 8Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  hostPath:
    path: /data/pv/kong/postgre

使用helm安装kong

helm install stable/kong

再创建kong-dashboard

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kong-dashboard-deployment    
spec:  
  selector:    
    matchLabels:
      app: kong-dashboard-pod  
      version: v1.0.0
  replicas: 1  
  template: 
    metadata:
      labels:
        app: kong-dashboard-pod 
        version: v1.0.0
    spec: 
      volumes: 
      - name: tz-config
        hostPath:
          path: /usr/share/zoneinfo/Asia/Shanghai

      containers:
      - name: kong-dashboard-container    
        image: pgbi/kong-dashboard   
        ports:    
        - containerPort: 8080
        args: 
        - 'start'
        - '--kong-url'
        - 'http://my-kong-kong-admin:8444'
        - '--insecure'
#        - '--basic-auth'
#        - 'intellif=introcks'
#        command: ['sleep','30000']    
        volumeMounts:
        - name: tz-config
          mountPath: /etc/localtime
---
apiVersion: v1
kind: Service         
metadata:            
  name: kong-dashboard-service  
spec:           
  type: NodePort     
  ports:
  - port: 8080    
    targetPort: 8080  
    protocol: TCP
    nodePort: 31500
    name: http-kong-dashboard
  selector:
    app: kong-dashboard-pod 
    version: v1.0.0

默认情况下，KONG监听的端口为：

· 8000：此端口是KONG用来监听来自客户端传入的HTTP请求，并将此请求转发到上有服务器；

· 8443：有的地方使用8443代替8000， 此端口是KONG用来监听来自客户端传入的HTTP请求的。它跟8000端口的功能类似，但是它只是用来监听HTTP请求的，没有转发功能。可以通过修改配置文件来禁止它；

· 8001：Admin API，通过此端口，管理者可以对KONG的监听服务进行配置；

· 8444：有的地方使用8444代替8001，通过此端口，管理者可以对HTTP请求进行监控.

如果不想使用postgre数据库,可以自己进入容器配置,或者将配置文件通过configmap挂载进去

# 示例配置位置
/config/local_example.js

# 拷贝一份
cd ./config/
cp local_example.js ./local.js

# 配置默认数据库
vi ./local.js
models: {
    connection: process.env.DB_ADAPTER || 'localDiskDb',
},
# 改成
models: {
    connection: process.env.DB_ADAPTER || 'mysql', // 这里可以用‘mysql’，‘mongo’，‘sqlserver’，‘postgres’
},
# 保存

# 修改数据库默认配置
vi connections.js
mysql: {
    adapter: 'sails-mysql',
    host: process.env.DB_HOST || 'localhost',
    port: process.env.DB_PORT || 3306,
    user: process.env.DB_USER || 'root',
    password: process.env.DB_PASSWORD || null,
    database: process.env.DB_DATABASE || 'konga_database'
},
# 改成
mysql: {
    adapter: 'sails-mysql',
    host: process.env.DB_HOST || 'localhost',
    port: process.env.DB_PORT || 3306,
    user: process.env.DB_USER || 'root',
    password: process.env.DB_PASSWORD || 'root',
    database: process.env.DB_DATABASE || 'konga_database'
},
# 保存

# 创建数据库
mysql -uroot -proot // 这里不建议用明文密码
CREATE DATABASE konga_database CHARACTER SET utf8 COLLATE utf8_general_ci;

向kong中配置一个服务

在这一节，你会添加一个API到Kong.为了达到这个目的，首先你需要添加一个服务(Service)，这是Kong用来指定它管理的上游Api和微服务的名称。

为了达成目标，我们将会创建一个Service指向Mockbin API，MockBin是一个”回显”类型的公共网站，它返回请求者的请求，作为响应。这非常有助于我们学习Kong如何代理你的API请求。

在你开始请求Service之前，你需要先添加一个Route。Route定义了请求在到达Kong以后如何发送到他们的Service.一个Service可以有多个Route.

在配置完Service和Route以后，你就可以通过Kong使用他们发送请求啦。

Kong暴露了一个RESTful管理Api在8001端口上，Kong的配置，包括添加Service和Route,都是通过这个Api发送请求.

1. 使用管理Api添加你的Service

执行以下cURL请求，添加你的第一个Service(指向Mockbin API):

$ curl -i -X POST \
  --url http://localhost:8001/services/ \
  --data 'name=example-service' \
  --data 'url=http://mockbin.org'

1. 为服务添加一个路由

$ curl -i -X POST \
  --url http://localhost:8001/services/example-service/routes \
  --data 'hosts[]=example.com'

1. 通过Kong转发你的请求 执行下面的cURL请求，验证Kong是否正确转发到你的Service. 注意，默认情况下，Kong在8000端口处理代理请求.

    $ curl -i -X GET \
  --url http://localhost:8000/ \
  --header 'Host: example.com'

成功响应意味着现在Kong已经将http://localhost:8000转发到我们在第一步中配的url上，并且将响应转发给我们。Kong之所以知道这么干，是通过在cURL请求里定义的Header:

Host: <given host>

启动插件

下面的步骤中，你会配置key-auth插件，为你的Service添加认证功能。在添加这个插件之前，你的Service所有的请求都会代理到上游。一旦你添加配置了这个插件，只有带正确的API key的请求会被代理，其他的请求会被Kong拒绝,从而保护你的上游服务免于未授权调用。

1. 配置key-auth插件

为你在Kong中配置的服务配置key-auth插件，执行以下cURL请求 执行以下cURL请求，添加你的第一个Service(指向Mockbin API):

$ curl -i -X POST \
  --url http://localhost:8001/services/example-service/plugins/ \
  --data 'name=key-auth'

注意： 这个插件同时接受config.key_names参数，默认值是[‘apiKey’]这是一个header参数名数组，用于在请求时发送apiKey,任意一个都支持.

1. 验证插件是否正确配置 执行以下的cURL请求，验证key-auth插件是否在Service上正确配置：

你会收到一个类似下面的响应：

$ curl -i -X GET \
  --url http://localhost:8000/ \
  --header 'Host: example.com'

由于你没有在header或参数里添加指定需要的apiKey，响应应该是401 Unauthorized

HTTP/1.1 401 Unauthorized
...

{
  "message": "No API key found in request"
}

添加信任用户Consumer

1. 通过RESTful API创建一个Consumer 执行下面的命令，创建一个叫Jason的用户

$ curl -i -X POST \
  --url http://localhost:8001/consumers/ \
  --data "username=Jason"

响应大致如下:

HTTP/1.1 201 Created
Content-Type: application/json
Connection: keep-alive

{
  "username": "Jason",
  "created_at": 1428555626000,
  "id": "bbdf1c48-19dc-4ab7-cae0-ff4f59d87dc9"
}

恭喜，你刚添加了第一个Consumer

提示 Kong同时接受custom_id参数，关联到库中已存在的Consumer

1. 为Consumer发放凭证 给刚创建的用户Jason创建 一个key

$ curl -i -X POST \
  --url http://localhost:8001/consumers/Jason/key-auth/ \
  --data 'key=ENTER_KEY_HERE'

1. 验证你的Consumer凭证有效 现在，我们可以执行下面的命令，验证刚刚给Jason发放的凭证是否有效.

$ curl -i -X GET \
  --url http://localhost:8000 \
  --header "Host: example.com" \
  --header "apikey: ENTER_KEY_HERE"

参考：https://www.pocketdigi.com/book/kong/guides/configuration-reference.html

Kong API Gateway 管理API详解

使用api，我们可以编程控制网关。这也是kong-dashboard做的事情。

参考：https://linuxops.org/blog/kong/admin.html

发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/153171.html原文链接：https://javaforall.cn