api網關 kong 教程入門
為什么使用API-Gateway
- 方便客戶端維護– 每個請求方不用管理多個api url，統一訪問api-gateway即可
- 接口重構時調用方不須了解接口本身等拆分和聚合
- 客戶端無須關心接口協議
- 統一權限控制、接口請求訪問日志統計
- 安全，是保護內部服務而設計的一道屏障
- 開源-最大好處
當然也有一個很大的缺點，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
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
再創建kong-dashboard
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發送請求.
- 使用管理Api添加你的Service
執行以下cURL請求，添加你的第一個Service(指向Mockbin API):
--url http://localhost:8001/services/
--data 'name=example-service'
--data 'url=http://mockbin.org'
為服務添加一個路由
--url http://localhost:8001/services/example-service/routes
--data 'hosts[]=example.com'
通過Kong轉發你的請求
執行下面的cURL請求，驗證Kong是否正確轉發到你的Service. 注意，默認情況下，Kong在8000端口處理代理請求.
--url http://localhost:8000/
--header 'Host: example.com'
成功響應意味著現在Kong已經將http://localhost:8000轉發到我們在第一步中配的url上，并且將響應轉發給我們。Kong之所以知道這么干，是通過在cURL請求里定義的Header:
啟動插件
下面的步驟中，你會配置key-auth插件，為你的Service添加認證功能。在添加這個插件之前，你的Service所有的請求都會代理到上游。一旦你添加配置了這個插件，只有帶正確的API key的請求會被代理，其他的請求會被Kong拒絕,從而保護你的上游服務免于未授權調用。
- 配置key-auth插件
為你在Kong中配置的服務配置key-auth插件，執行以下cURL請求 執行以下cURL請求，添加你的第一個Service(指向Mockbin API):
--url http://localhost:8001/services/example-service/plugins/
--data 'name=key-auth'
注意：這個插件同時接受config.key_names參數，默認值是[‘apiKey’]這是一個header參數名數組，用于在請求時發送apiKey,任意一個都支持.
- 驗證插件是否正確配置 執行以下的cURL請求，驗證key-auth插件是否在Service上正確配置：
你會收到一個類似下面的響應：
--url http://localhost:8000/
--header 'Host: example.com'
由于你沒有在header或參數里添加指定需要的apiKey，響應應該是401 Unauthorized
...
{
"message": "No API key found in request"
}
添加信任用戶Consumer
通過RESTful API創建一個Consumer
執行下面的命令，創建一個叫Jason的用戶
--url http://localhost:8001/consumers/
--data "username=Jason"
響應大致如下:
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
--url http://localhost:8001/consumers/Jason/key-auth/
--data 'key=ENTER_KEY_HERE'
驗證你的Consumer憑證有效
現在，我們可以執行下面的命令，驗證剛剛給Jason發放的憑證是否有效.
--url http://localhost:8000
--header "Host: example.com"
--header "apikey: ENTER_KEY_HERE"
-
服務器
+關注
關注
12文章
9303瀏覽量
86061 -
API
+關注
關注
2文章
1510瀏覽量
62394 -
教程
+關注
關注
25文章
265瀏覽量
54222 -
日志
+關注
關注
0文章
139瀏覽量
10679
發布評論請先 登錄
相關推薦
API信息全掌控，方便你的日志管理——阿里云推出API網關打通日志服務
什么是API網關為什么需要API網關
基于API 網關的微服務治理方案
local-data-api-gateway本地數據API網關
Service Mesh和API網關正在逐步融合
庖丁解牛：Apache APISIX 3.0與Kong 3.0功能背后的趨勢
關于API網關策略的知識分享
API 網關詳細介紹（上）
API 網關詳細介紹（下）
云原生 API 網關 APISIX入門
為什么需要 API 網關？
企業怎么選擇API網關
工商網監
評論