耳根,武道至尊帝临小说,有声

為什么使用API-Gateway

方便客戶端維護– 每個請求方不用管理多個api url，統(tǒng)一訪問api-gateway即可
接口重構(gòu)時調(diào)用方不須了解接口本身等拆分和聚合
客戶端無須關(guān)心接口協(xié)議
統(tǒng)一權(quán)限控制、接口請求訪問日志統(tǒng)計
安全，是保護內(nèi)部服務(wù)而設(shè)計的一道屏障
開源-最大好處

當然也有一個很大的缺點，api-gw很可能成為性能瓶頸，因為所有的請求都經(jīng)過這里，可以通過橫向擴展和限流解決這個問題。

在眾多API GATEWAY框架中，Mashape開源的高性能高可用API網(wǎng)關(guān)和API服務(wù)管理層——KONG（基于NGINX）特點尤為突出，它可以通過插件擴展已有功能，這些插件（使用lua編寫）在API請求響應(yīng)循環(huán)的生命周期中被執(zhí)行。于此同時，KONG本身提供包括HTTP基本認證、密鑰認證、CORS、TCP、UDP、文件日志、API請求限流、請求轉(zhuǎn)發(fā)及NGINX監(jiān)控等基本功能。目前，Kong在Mashape管理了超過15,000個API，為200,000開發(fā)者提供了每月數(shù)十億的請求支持。

Kong是一款基于Nginx_Lua模塊寫的高可用，由于Kong是基于Nginx的，所以可以水平擴展多個Kong服務(wù)器，通過前置的負載均衡配置把請求均勻地分發(fā)到各個Server，來應(yīng)對大批量的網(wǎng)絡(luò)請求。

kong架構(gòu)

Kong主要有三個組件：

Kong Server ：基于nginx的服務(wù)器，用來接收API請求。 Apache Cassandra/PostgreSQL ：用來存儲操作數(shù)據(jù)。 Kong dashboard：官方推薦UI管理工具，當然，也可以使用 restfull 方式管理admin api。

Kong采用插件機制進行功能定制，插件集（可以是0或N個）在API請求響應(yīng)循環(huán)的生命周期中被執(zhí)行。插件使用Lua編寫，目前已有幾個基礎(chǔ)功能：HTTP基本認證、密鑰認證、CORS（Cross-Origin Resource Sharing，跨域資源共享）、TCP、UDP、文件日志、API請求限流、請求轉(zhuǎn)發(fā)以及Nginx監(jiān)控。

Kong網(wǎng)關(guān)的特性

Kong網(wǎng)關(guān)具有以下的特性：

可擴展性: 通過簡單地添加更多的服務(wù)器，可以輕松地進行橫向擴展，這意味著您的平臺可以在一個較低負載的情況下處理任何請求；模塊化: 可以通過添加新的插件進行擴展，這些插件可以通過RESTful Admin API輕松配置；在任何基礎(chǔ)架構(gòu)上運行: Kong網(wǎng)關(guān)可以在任何地方都能運行。您可以在云或內(nèi)部網(wǎng)絡(luò)環(huán)境中部署Kong，包括單個或多個數(shù)據(jù)中心設(shè)置，以及public，private 或invite-only APIs。

Kong核心基于OpenResty構(gòu)建，實現(xiàn)了請求/響應(yīng)的Lua處理化； Kong插件攔截請求/響應(yīng)，如果接觸過Java Servlet，等價于攔截器，實現(xiàn)請求/響應(yīng)的AOP處理； Kong Restful 管理API提供了API/API消費者/插件的管理；數(shù)據(jù)中心用于存儲Kong集群節(jié)點信息、API、消費者、插件等信息，目前提供了PostgreSQL和Cassandra支持，如果需要高可用建議使用Cassandra； Kong集群中的節(jié)點通過gossip協(xié)議自動發(fā)現(xiàn)其他節(jié)點，當通過一個Kong節(jié)點的管理API進行一些變更時也會通知其他節(jié)點。每個Kong節(jié)點的配置信息是會緩存的，如插件，那么當在某一個Kong節(jié)點修改了插件配置時，需要通知其他節(jié)點配置的變更。

Kong網(wǎng)關(guān)插件

身份認證插件：Kong提供了Basic Authentication、Key authentication、OAuth2.0 authentication、HMAC authentication、JWT、LDAP authentication認證實現(xiàn)。安全控制插件：ACL（訪問控制）、CORS（跨域資源共享）、動態(tài)SSL、IP限制、爬蟲檢測實現(xiàn)。流量控制插件：請求限流（基于請求計數(shù)限流）、上游響應(yīng)限流（根據(jù)upstream響應(yīng)計數(shù)限流）、請求大小限制。限流支持本地、Redis和集群限流模式。分析監(jiān)控插件：Galileo（記錄請求和響應(yīng)數(shù)據(jù)，實現(xiàn)API分析）、Datadog（記錄API Metric如請求次數(shù)、請求大小、響應(yīng)狀態(tài)和延遲，可視化API Metric）、Runscope（記錄請求和響應(yīng)數(shù)據(jù)，實現(xiàn)API性能測試和監(jiān)控）。協(xié)議轉(zhuǎn)換插件：請求轉(zhuǎn)換（在轉(zhuǎn)發(fā)到upstream之前修改請求）、響應(yīng)轉(zhuǎn)換（在upstream響應(yīng)返回給客戶端之前修改響應(yīng)）。日志應(yīng)用插件：TCP、UDP、HTTP、File、Syslog、StatsD、Loggly等。

Kong網(wǎng)關(guān)請求流程

為了更好地理解系統(tǒng)，這是使用Kong網(wǎng)關(guān)的API接口的典型請求工作流程：

請求流程

當Kong運行時，每個對API的請求將先被Kong命中，然后這個請求將會被代理轉(zhuǎn)發(fā)到最終的API接口。在請求（Requests）和響應(yīng)（Responses）之間，Kong將會執(zhí)行已經(jīng)事先安裝和配置好的任何插件，授權(quán)您的API訪問操作。Kong是每個API請求的入口點（Endpoint）。

helm 安裝

先創(chuàng)建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

再創(chuàng)建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監(jiān)聽的端口為：

· 8000：此端口是KONG用來監(jiān)聽來自客戶端傳入的HTTP請求，并將此請求轉(zhuǎn)發(fā)到上有服務(wù)器；

· 8443：有的地方使用8443代替8000，此端口是KONG用來監(jiān)聽來自客戶端傳入的HTTP請求的。它跟8000端口的功能類似，但是它只是用來監(jiān)聽HTTP請求的，沒有轉(zhuǎn)發(fā)功能。可以通過修改配置文件來禁止它；

· 8001：Admin API，通過此端口，管理者可以對KONG的監(jiān)聽服務(wù)進行配置；

· 8444：有的地方使用8444代替8001，通過此端口，管理者可以對HTTP請求進行監(jiān)控.

如果不想使用postgre數(shù)據(jù)庫,可以自己進入容器配置,或者將配置文件通過configmap掛載進去

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

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

# 配置默認數(shù)據(jù)庫
vi ./local.js
models: {
connection: process.env.DB_ADAPTER || 'localDiskDb',
},
# 改成
models: {
connection: process.env.DB_ADAPTER || 'mysql', // 這里可以用‘mysql’，‘mongo’，‘sqlserver’，‘postgres’
},
# 保存

# 修改數(shù)據(jù)庫默認配置
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'
},
# 保存

# 創(chuàng)建數(shù)據(jù)庫
mysql -uroot -proot // 這里不建議用明文密碼
CREATE DATABASE konga_database CHARACTER SET utf8 COLLATE utf8_general_ci;

向kong中配置一個服務(wù)

在這一節(jié)，你會添加一個API到Kong.為了達到這個目的，首先你需要添加一個服務(wù)(Service)，這是Kong用來指定它管理的上游Api和微服務(wù)的名稱。

為了達成目標，我們將會創(chuàng)建一個Service指向Mockbin API，MockBin是一個”回顯”類型的公共網(wǎng)站，它返回請求者的請求，作為響應(yīng)。這非常有助于我們學習Kong如何代理你的API請求。

在你開始請求Service之前，你需要先添加一個Route。Route定義了請求在到達Kong以后如何發(fā)送到他們的Service.一個Service可以有多個Route.

在配置完Service和Route以后，你就可以通過Kong使用他們發(fā)送請求啦。

Kong暴露了一個RESTful管理Api在8001端口上，Kong的配置，包括添加Service和Route,都是通過這個Api發(fā)送請求.

使用管理Api添加你的Service

執(zhí)行以下cURL請求，添加你的第一個Service(指向Mockbin API):

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

為服務(wù)添加一個路由

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

通過Kong轉(zhuǎn)發(fā)你的請求

執(zhí)行下面的cURL請求，驗證Kong是否正確轉(zhuǎn)發(fā)到你的Service. 注意，默認情況下，Kong在8000端口處理代理請求.

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

成功響應(yīng)意味著現(xiàn)在Kong已經(jīng)將http://localhost:8000轉(zhuǎn)發(fā)到我們在第一步中配的url上，并且將響應(yīng)轉(zhuǎn)發(fā)給我們。Kong之所以知道這么干，是通過在cURL請求里定義的Header:

Host:

啟動插件

下面的步驟中，你會配置key-auth插件，為你的Service添加認證功能。在添加這個插件之前，你的Service所有的請求都會代理到上游。一旦你添加配置了這個插件，只有帶正確的API key的請求會被代理，其他的請求會被Kong拒絕,從而保護你的上游服務(wù)免于未授權(quán)調(diào)用。

配置key-auth插件

為你在Kong中配置的服務(wù)配置key-auth插件，執(zhí)行以下cURL請求執(zhí)行以下cURL請求，添加你的第一個Service(指向Mockbin API):

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

注意：這個插件同時接受config.key_names參數(shù)，默認值是[‘a(chǎn)piKey’]這是一個header參數(shù)名數(shù)組，用于在請求時發(fā)送apiKey,任意一個都支持.

驗證插件是否正確配置執(zhí)行以下的cURL請求，驗證key-auth插件是否在Service上正確配置：

你會收到一個類似下面的響應(yīng)：

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

由于你沒有在header或參數(shù)里添加指定需要的apiKey，響應(yīng)應(yīng)該是401 Unauthorized

HTTP/1.1 401 Unauthorized
...

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

添加信任用戶Consumer

通過RESTful API創(chuàng)建一個Consumer

執(zhí)行下面的命令，創(chuàng)建一個叫Jason的用戶

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

響應(yīng)大致如下:

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參數(shù)，關(guān)聯(lián)到庫中已存在的Consumer

為Consumer發(fā)放憑證

給剛創(chuàng)建的用戶Jason創(chuàng)建一個key

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

驗證你的Consumer憑證有效

現(xiàn)在，我們可以執(zhí)行下面的命令，驗證剛剛給Jason發(fā)放的憑證是否有效.

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

聲明：本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人，不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學習之用，如有內(nèi)容侵權(quán)或者其他違規(guī)問題，請聯(lián)系本站處理。舉報投訴