api网关 kong 教程入门

描述

为什么使用API-Gateway

  1. 方便客户端维护– 每个请求方不用管理多个api url,统一访问api-gateway即可
  2. 接口重构时调用方不须了解接口本身等拆分和聚合
  3. 客户端无须关心接口协议
  4. 统一权限控制、接口请求访问日志统计
  5. 安全,是保护内部服务而设计的一道屏障
  6. 开源-最大好处

当然也有一个很大的缺点,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,来应对大批量的网络请求。

API

kong架构

API

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。

API

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接口的典型请求工作流程:

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'

为服务添加一个路由

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

通过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:

启动插件

下面的步骤中,你会配置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

通过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

为Consumer发放凭证

给刚创建的用户Jason创建 一个key

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

验证你的Consumer凭证有效

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

$ curl -i -X GET
--url http://localhost:8000
--header "Host: example.com"
--header "apikey: ENTER_KEY_HERE"
打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分