開源API網(wǎng)關Kong基本介紹和安裝驗證
今天準備介紹下開源API網(wǎng)關Kong,在Gtihub搜索API網(wǎng)關類的開源產品,可以看到Kong網(wǎng)關常年都是排第一的位置,而且當前很多都有一定研發(fā)能力的企業(yè)在API網(wǎng)關產品選型的時候基本也會選擇Kong網(wǎng)關,并基于Kong網(wǎng)關進行二次開發(fā)和定制。
API網(wǎng)關概述

簡單來說API網(wǎng)關就是將所有的微服務提供的API接口服務能力全部匯聚進來,統(tǒng)一接入進行管理,也正是通過統(tǒng)一攔截,就可以通過網(wǎng)關實現(xiàn)對API接口的安全,日志,限流熔斷等共性需求。如果再簡單說下,通過網(wǎng)關實現(xiàn)了幾個關鍵能力。
- 內部的微服務對外部訪問來說位置透明,外部應用只需和網(wǎng)關交互
- 統(tǒng)一攔截接口服務,實現(xiàn)安全,日志,限流熔斷等需求
從這里,我們就可以看到API網(wǎng)關和傳統(tǒng)架構里面的ESB總線是類似的,這些關鍵能力本身也是ESB服務總線的能力,但是ESB服務總線由于要考慮遺留系統(tǒng)的接入,因此增加了:
- 大量適配器實現(xiàn)對遺留系統(tǒng)的遺留接口適配,多協(xié)議轉換能力
- 進行數(shù)據(jù)的復制映射,路由等能力
對于兩者,我原來做過一個簡單的對比,大家可以參考。

基于Openresty開發(fā)API網(wǎng)關

在談API網(wǎng)關前,我們先談下Openresty。在前面文章談到過,當前適合用于API網(wǎng)關的架構,一種是基于Openresty的,一種是基于Go語言的。
OpenResty® 是一個基于 Nginx 與 Lua 的高性能 Web 平臺,其內部集成了大量精良的 Lua 庫、第三方模塊以及大多數(shù)的依賴項。用于方便地搭建能夠處理超高并發(fā)、擴展性極高的動態(tài) Web 應用、Web 服務和動態(tài)網(wǎng)關。
OpenResty® 通過匯聚各種設計精良的 Nginx 模塊(主要由 OpenResty 團隊自主開發(fā)),從而將 Nginx 有效地變成一個強大的通用系統(tǒng) Web 應用平臺。這樣,Web 開發(fā)人員和系統(tǒng)工程師可以使用 Lua 腳本語言調動 Nginx 支持的各種 C 以及 Lua 模塊,快速構造出足以勝任 10K 乃至 1000K 以上單機并發(fā)連接的高性能 Web 應用系統(tǒng)。
OpenResty® 的目標是讓你的Web服務直接跑在 Nginx 服務內部,充分利用 Nginx 的非阻塞 I/O 模型,不僅僅對 HTTP 客戶端請求,甚至于對遠程后端諸如 MySQL、PostgreSQL、Memcached 以及 Redis 等都進行一致的高性能響應。
- 為何Openresty適合用于API網(wǎng)關開發(fā)?
對于API網(wǎng)關,有一個最基礎的核心功能即需要實現(xiàn)接口服務代理路由,而這個本身也是Nginx反向代理能夠提供的一個標準功能。
如果應用場景比較簡單,僅僅是實現(xiàn)統(tǒng)一接口對外暴露,可以看到很多企業(yè)實際并沒有采用API網(wǎng)關,而是直接采用了Nginx來替代API網(wǎng)關的服務代理路由功能。
其次,對于常規(guī)的API網(wǎng)關的中間件研發(fā),在研發(fā)完成后本身還要依托一個Web容器進行部署,同時還需要自己去實現(xiàn)類似路由代理等各種能力。
在這種場景下可以看到,依托于Nginx,在其內部來擴展一個Web容器能力,既可以充分的利用Nginx本身的代理路由和性能優(yōu)勢就是一個重要的選擇。而OpenResty本身可以看做是基于Nginx服務器,在其worker里面內嵌了一個LuaJVM,通過這種方式來實現(xiàn)了兩者的融合。同時又可以通過開發(fā)和定制各種Lua庫來進行快速的功能擴展。
也正是這樣原因,基于Openresty來擴展動態(tài)網(wǎng)關功能是一個很好的選擇。
- OpenResty的安裝
在Centos下可以通過yum很方便的安裝OpenResty,具體如下:
- //安裝yum-utils
- # sudo yum install yum-utils
- //添加 openresty 倉庫
- sudo yum-config-manager --add-repo https://openresty.org/package/centos/openresty.repo
- //安裝openresty
- # sudo yum install openresty
- //安裝命令行工具
- # sudo yum install openresty-resty
- //至此安裝成功,默認安裝在 /usr/local/openresty
- //測試
- # sudo /sbin/service openresty start
- # sudo /sbin/service openresty stop
注意在安裝完成后如果通過瀏覽器訪問,需要先關閉防火墻或者打開放行80端口。
Kong網(wǎng)關概述

首先我們看下GitHub上對Kong網(wǎng)關的一些介紹
當我們決定對應用進行微服務改造時,應用客戶端如何與微服務交互的問題也隨之而來,畢竟服務數(shù)量的增加會直接導致部署授權、負載均衡、通信管理、分析和改變的難度增加。
面對以上問題,API GATEWAY是一個不錯的解決方案,其所提供的訪問限制、安全、流量控制、分析監(jiān)控、日志、請求轉發(fā)、合成和協(xié)議轉換功能,可以解放開發(fā)者去把精力集中在具體邏輯的代碼,而不是把時間花費在考慮如何解決應用和其他微服務鏈接的問題上。
Kong網(wǎng)關是一款基于OpenResty(Nginx + Lua模塊)編寫的高可用、易擴展的,由Mashape公司開源的API Gateway項目。Kong是基于NGINX和Apache Cassandra或PostgreSQL構建的,能提供易于使用的RESTful API來操作和配置API管理系統(tǒng),所以它可以水平擴展多個Kong服務器,通過前置的負載均衡配置把請求均勻地分發(fā)到各個Server,來應對大批量的網(wǎng)絡請求。
KONG本身提供包括HTTP基本認證、密鑰認證、CORS、TCP、UDP、文件日志、API請求限流、請求轉發(fā)及NGINX監(jiān)控等基本功能。目前,Kong在Mashape管理了超過15,000個API,為200,000開發(fā)者提供了每月數(shù)十億的請求支持。
Kong網(wǎng)關核心組件
- Kong Server :基于nginx的服務器,用來接收API請求。
- Apache Cassandra/PostgreSQL :用來存儲操作數(shù)據(jù)。
- Kong dashboard:官方推薦UI管理工具,也可以使用開源的Konga平臺
Kong采用插件機制進行功能定制,當前本身已經(jīng)具備了類似安全,限流,日志,認證,數(shù)據(jù)映射等基礎插件能力,同時也可以很方便的通過Lua定制自己的插件。插件完全是一種可以動態(tài)插拔的模式,通過插件可以方便的實現(xiàn)Kong網(wǎng)關能力的擴展。
Kong網(wǎng)關核心組件關鍵特性
- Cloud-Native云原生:與平臺無關,Kong可以在從裸機到容器的任何平臺上運行,并且可以在每個云上本地運行。
- Kubernetes集成能力:使用官方的Ingress Controller通過本地Kubernetes CRD聲明性地配置Kong,以路由和連接所有L4 + L7層網(wǎng)絡流量。
- 動態(tài)負載均衡:在多個上游服務之間平衡流量。
- 基于哈希的負載均衡:具有一致的哈希/粘性會話的負載均衡。
- 斷路器:智能跟蹤不健康的上游服務。
- 健康檢查:主動和被動監(jiān)視上游服務。
- 服務發(fā)現(xiàn):在Consul之類的第三方DNS解析器中解析SRV記錄。
- Serverless:直接從Kong調用和保護AWS Lambda或OpenWhisk功能。
- WebSockets:通過WebSockets與您的上游服務進行通信。
- gRPC:與gRPC服務進行通信,并通過日志記錄和可觀察性插件觀察流量
- OAuth2.0:輕松將OAuth2.0身份驗證添加到您的API。
- 日志功能:通過HTTP,TCP,UDP或磁盤Log對系統(tǒng)的請求和響應。
- 安全性:ACL,僵尸程序檢測,允許/拒絕IP等...
- Syslog:登錄到系統(tǒng)日志。
- SSL:為基礎服務或API設置特定的SSL證書。
- 監(jiān)控:對關鍵負載和性能服務器指標提供動態(tài)實時監(jiān)控。
- 轉發(fā)代理:使Kong連接到透明的中介HTTP代理。
- 認證:HMAC,JWT,Basic等。
- 限流:基于許多變量的阻止和限制請求。
- 轉換:添加,刪除或處理HTTP請求和響應。
- 緩存:在代理層緩存并提供響應。
- CLI:從命令行控制Kong群集。
- 開放API接口:Kong可以使用其RESTful API進行操作,以實現(xiàn)最大的靈活性。
- 跨區(qū)域復制:跨不同區(qū)域的配置始終是最新的。
- 故障檢測和恢復:如果您的Cassandra節(jié)點之一發(fā)生故障,則Kong不會受到影響。
- 群集:所有Kong節(jié)點自動加入群集,并在各個節(jié)點之間更新其配置。
- 可擴展性:Kong本質上分布,只需添加節(jié)點即可水平擴展。
- 性能:Kong通過擴展和使用NGINX作為核心輕松處理負載。
- 插件:可擴展的體系結構,用于向Kong和API添加功能。
Kong網(wǎng)關的主要功能分析

對于Kong網(wǎng)關本身基于OpenResty構建,因此前面介紹的OpenResty本身的特性也就成了Kong網(wǎng)關的特性,同時Kong網(wǎng)關本身天然和OpenResty融合在一起,不再需要依賴其他的中間件或Web容器進行部署。
其次就是Kong網(wǎng)關本身的插件化開發(fā)機制,通過插件對Http接口請求和響應進行攔截,在攔截處就可以實現(xiàn)各種API接口管控和治理的要求。插件通過Lua語言開發(fā),可以動態(tài)插拔。
要實現(xiàn)和Kong網(wǎng)關本身的集成和管理本身也很簡單,Kong網(wǎng)關提供各類的Rest API接口,可以很方便的實現(xiàn)和Kong網(wǎng)關能力的對接。也就是說你完全可以自己開發(fā)要給API管控治理平臺,而底層引擎用Kong網(wǎng)關。
支持高可用集群,節(jié)點之間的發(fā)現(xiàn)采用的gossip協(xié)議,當Kong節(jié)點啟動后,會將自己的IP信息加入到node列表,廣播給任何其他的Kong節(jié)點,當另一個Kong節(jié)點啟動后,會去讀取數(shù)據(jù)庫中的node列表,并將自己的信息加入到列表中。
另外再來看下Kong API網(wǎng)關提供的一些基本功能:
- API注冊和服務代理
對于原始的API接口進行注冊,并提供服務代理能力,即不同的API接口注冊到網(wǎng)關后,網(wǎng)關可以提供一個統(tǒng)一的訪問地址和接口。這和ESB總線的代理服務道理是一致的,在服務注冊到API網(wǎng)關后,所有的內部服務對外界都是透明的,外部的服務訪問必須要通過API網(wǎng)關進行。
該部分對應到Kong API網(wǎng)關的服務注冊和Routing部分的功能和能力上。
- 負載均衡
由于Kong API網(wǎng)關本身底層也是基于Nginx的,因此對應負載均衡的能力實際上是通過底層的Nginx來完成的。要在Kong上面實現(xiàn)負載均衡和API注冊代理實際上需要分開為兩個步驟進行。
即首先是要配置負載均衡能力,建立Upstream組,并添加多個Target,其次才是進行API注冊。
- AUTHENTICATION實現(xiàn)
通過OAuth 2.0 Authentication插件實現(xiàn)user端口的用戶訪問限制。其具體步驟如下:
- 注冊Oauth2插件,配置參考
- 添加Consumer及Consumer對應的credentials
- 申請accesstoken并訪問,如果不帶token訪問將被拒絕
安全和訪問控制
支持最基本的基于IP的安全訪問控制和黑白名單設置。即為相應的端口添加IP Restriction插件擴展,并設置白名單(只有名單內的IP可以訪問API)。
這和我們當前ESB的基于IP的訪問控制和授權是一個道理。但是我們的ESB更加靈活,多了業(yè)務系統(tǒng)這一層,即可以直接對業(yè)務系統(tǒng)這層統(tǒng)一進行授權。
如果沒有授權,在進行訪問的時候將返回Your IP address is not allowed的訪問錯誤。
- 流量控制-Traffic Control
流量控制在當前Kong網(wǎng)關上,從GitHub上的參考來看,主要是實現(xiàn)了可以基于單位時間內的訪問次數(shù)進行流量控制,如果超過了這個訪問次數(shù),則直接提示流控約束且無法訪問的提示。當前的流量控制,暫時不支持基于數(shù)據(jù)量的流控。
當前的流控暫時沒有看到微服務網(wǎng)關常用的熔斷操作,即服務并發(fā)或服務響應時間大過某個臨界值的時候,直接對服務進行熔斷和下線操作。
- 日志Logging實現(xiàn)
通過File-log插件實現(xiàn)對于每次訪問日志的獲取,需要注意為日志文件寫權限,日志格式參考Log Format。具體包括兩個步驟。
- 為端口添加File-log插件,并設置為日志文件路徑設為:/tmp/file.log
- 添加日志插件后,每次訪問都會被記錄
當前Kong網(wǎng)關日志都是寫入到文件系統(tǒng)中,但是這塊可以很方便的定制日志插件將日志寫入到緩存庫,時序數(shù)據(jù)庫或分布式數(shù)據(jù)庫。另外當前的日志LOGGING是沒有提供日志查詢的前端功能界面的,如果需要的話還需要自己開發(fā)對應的日志查詢功能。
這個日志功能和我們當前的ESB總線的日志Log完全是類似的。但是我們ESB這塊的能力更加強,包括后續(xù)的服務運行日志的統(tǒng)計分析和報表查看等。
Kong網(wǎng)關插件說明

從上圖可以看到,Kong網(wǎng)關是基于OpenResty應用服務器,OpenResty是一個基于 Nginx 與 Lua 的高性能 Web 平臺,其內部集成了大量精良的 Lua 庫、第三方模塊以及大多數(shù)的依賴項。用于方便地搭建能夠處理超高并發(fā)、擴展性極高的動態(tài) Web 應用、Web 服務和動態(tài)網(wǎng)關。而Kong 核心基于OpenResty構建,并且擁有強大的插件擴展功能。
在Http請求到達Kong網(wǎng)關后,轉發(fā)給后端應用之前,可以通過網(wǎng)關的各種插件對請求進行流量控制,安全,日志等各方面的處理能力。當前Kong的插件分為開源版和社區(qū)版,社區(qū)版還有更多的定制功能,但是社區(qū)版是要收費的。
目前,KONG開源版本一共開放28個插件,如下:
- acl、aws-lambda、basic-auth、bot-detection、correlation-id、cors、datadog、file-log、galileo、hmac-auth、http-log、ip-restriction、jwt、key-auth、ldap-auth、loggly、oauth2、rate-limiting、request-size-limiting、request-termination、request-transformer、response-ratelimiting、response-transformer、runscope、statsd、syslog、tcp-log、udp-log。
以上這些插件主要分五大類,Authentication認證,Security安全,Traffic Control流量控制,Analytics & Monitoring分析&監(jiān)控,Logging日志,其他還有請求報文處理類。插件類似AOP開發(fā)中的橫切功能,可以靈活的配置進行攔截控制,下面選擇一些關鍵性的插件進行簡單的說明。
- 黑白名單控制能力-ip-restriction
Kong提供的IP黑白名單控制能力還算相當強,從配置項里面可以看到主要可以針對兩個維度進行配置,一個是針對所有的API接口還是針對特定的API接口,一個是針對所有的消費方還是特定的某個消費方。
對于IP配置可以是一個區(qū)段,也可以是特定的IP地址。但是黑白名單不能同時配置,其次當前沒有一個功能是針對某一個系統(tǒng)提供的所有服務都啟用黑名單或白名單功能。
- 日志記錄能力-syslog, file-log,http-log
這里主要日志的插件比較多,一個是sysLog在配置后可以直接將Kong產生的日志寫入到應用服務器的系統(tǒng)日志文件中。如果配置了file-log則是單獨寫入到你指定的file文件中。對于http-log則是對于http服務請求,可以詳細的記錄請求的輸入和輸出報文信息,但是具體是記錄到哪里,需要通過config.http_endpoint配置。
如果需要將API接口調用消息報文日志寫入到分布式存儲或數(shù)據(jù)庫中,則需要自己定義相應的日志插件來接入寫入問題。
- 熔斷插件-request-termination
該插件用來定義指定請求或服務不進行上層服務,而直接返回指定的內容,用來為指定的請求或指定的服務進行熔斷。注意Kong的熔斷插件感覺是臨時對服務的禁用,而不是說當達到某一種監(jiān)控閾值的時候自動觸發(fā)熔斷。從官方文檔的應用場景也可以看到這點。
如果僅僅是這種方式的熔斷話,實際上意義并不是很大。但是可用的地方就在于當某個業(yè)務系統(tǒng)進行發(fā)版部署的時候我們可以對該業(yè)務系統(tǒng)或該業(yè)務系統(tǒng)所提供的所有服務進行熔斷。
- 限流插件-rate-limiting
Kong當前提供的限流相對來說還是比較弱,即主要是控制某一個API接口服務在單位時間內最多只能夠調用多少次,如果超過這個次數(shù)那么網(wǎng)關就直接拒絕訪問并返回錯誤提示信息。而在前面我講限流和流量控制的時候經(jīng)常會說到,就是限流實際上一個是根據(jù)服務調用次數(shù),一個是根據(jù)服務調用數(shù)據(jù)量,需要在這兩個方面進行限流。而里面更加重要的反而是數(shù)據(jù)量的限流,因為大數(shù)據(jù)量報文往往更加容易造成內存溢出異常。
- 安全認證類插件
當前Kong網(wǎng)關提供basic-auth,key-auth、ldap-auth,hmac-auth多種認證插件。
Basic-auth基本認證插件,即我們根據(jù)用戶名和密碼來生成一個base64編碼,同時將該編碼和目標服務綁定,這樣在消費目標服務的時候就需要在報文頭填寫這個Base64編碼信息。
Key-auth認證插件則是利用提前預設好的關鍵字名稱,如下面設置的keynote = apices,然后為consumer設置一個key-auth 密鑰,假如key-auth=test@keyauth。在請求api的時候,將apikey=test@keyauth,作為一個參數(shù)附加到請求url后,或者放置到headers中。
Hmac-auth插件是設置綁定的service和rout,以啟動hmac驗證。然后在Consumers頁面中Hmac credentials of Consumer設置中添加一個username和secret。
- 請求報文容量限制-request-size-limiting
該插件用于限制請求報文的數(shù)據(jù)量大小,可以限制單個服務,也可以顯示所有的API接口服務。這個實際上是很有用的一個功能,可以防止大消息報文調用導致整個API網(wǎng)關內存溢出。
- 支持OAuth2.0身份認證-oauth2
Kong網(wǎng)關支持OAuth2.0身份認證,OAuth2.0 協(xié)議根據(jù)使用不同的適用場景,定義了用于四種授權模式。即Authorization code(授權碼模式),Implicit Grant(隱式模式),Resource Owner Password Credentials(密碼模式),Client Credentials(客戶端模式)。
在四種方式中經(jīng)常采用的還是授權碼這種標準的 Server 授權模式,非常適合 Server 端的 Web 應用。一旦資源的擁有者授權訪問他們的數(shù)據(jù)之后,他們將會被重定向到 Web 應用并在 URL 的查詢參數(shù)中附帶一個授權碼(code)。
在客戶端里, code 用于請求訪問令牌(access_token)。并且該令牌交換的過程是兩個服務端之前完成的,防止其他人甚至是資源擁有者本人得到該令牌。另外,在該授權模式下可以通過 refresh_token 來刷新令牌以延長訪問授權時間,也是最為復雜的一種方式。
- 簡單轉換能力
對于簡單轉換能力通過request-transformer 和 response transformer兩個插件來完成。Kong網(wǎng)關提供對輸入和輸出報文簡單轉換的能力,這部分內容后續(xù)再詳細展開介紹。從當前配置來看,主要是對消息報文提供了Add, Replace,Rename,Append等各種簡單操作能力。
- Kong網(wǎng)關和其它網(wǎng)關對比
對于開源的Kong網(wǎng)關和其它網(wǎng)關的對比如下。

從上面對比圖也可以看到,Kong網(wǎng)關在功能,性能,插件可擴展性各方面都能夠更好的滿足企業(yè)API網(wǎng)關的需求。因此我們也是基于Konga來進一步定制對Kong網(wǎng)關的管控治理平臺。

在整個定制中增加了基于DB適配的Http Rest API接口的自動發(fā)布,API服務自動化注冊,服務日志采集和服務日志查詢,常見映射模板定制,接口服務的自動化測試等方面的能力。
Kong網(wǎng)關的安裝

在這里以在Centos7下安裝Kong2.2版本說明。注意centos7安裝Postgresql不再列出,可以參考網(wǎng)上的文章進行安裝。
- # 安裝kong-yum源
- $wget https://bintray.com/kong/kong-rpm/rpm -O bintray-kong-kong-rpm.repo
- $export major_version=`grep -oE '[0-9]+\.[0-9]+' /etc/redhat-release | cut -d "." -f1`
- $sed -i -e 's/baseurl.*/&\/centos\/'$major_version''/ bintray-kong-kong-rpm.repo
- $mv bintray-kong-kong-rpm.repo /etc/yum.repos.d/
- # 清空緩存,重新生成緩存
- $yum clean all && yum makecache
- # 查看yum源信息
- $yum repolist
- # 更新yum源
- $yum update -y
- #############################
- #通過yum安裝kong
- #注意如果出現(xiàn)和openresty不兼容,需要先下載老版本的openresty
- $yum install -y kong
- # 查看配置文件位置
- $whereis kong
- $kong: /etc/kong /usr/local/bin/kong /usr/local/kong
- #############################
- #安裝postgresql數(shù)據(jù)庫(略)
- #############################
- #數(shù)據(jù)庫創(chuàng)建kong用戶
- $su - postgres
- $psql -U postgres
- CREATE USER kong;
- CREATE DATABASE kong OWNER kong;
- ALTER USER kong with encrypted password 'kong';
- #修改kong,postgresql連接配置
- $cp -r /etc/kong/kong.conf.default /etc/kong/kong.conf
- $vi /etc/kong/kong.conf
- database = postgres
- pg_host = 172.28.102.62
- pg_port = 5432
- pg_timeout = 5000
- pg_user = kong
- pg_password = kong
- pg_database = kong
- # 初始化數(shù)據(jù)庫
- $kong migrations bootstrap [-c /etc/kong/kong.conf]
- 注意執(zhí)行過程如遇到 failed to retrieve PostgreSQL server_version_num: FATAL: Ident authentication failed for user "kong",請給該用戶設定密碼,并修改postgres的授權方式為MD5,操作如下:
- $alter user kong with password 'kong';
- # 啟動kong
- $kong start [-c /etc/to/kong.conf]
- #檢查 KONG 是否正確運行
- $curl -i http://localhost:8001/
- 或者
- $kong health
- #停止 KONG
- $ kong stop
Kong-Dashboard安裝
對于Kong網(wǎng)關本身也提供了Kong Dashboard管理頁面,下面再看下Dashboard的安裝。在安裝Dashboard前需要首先安裝node.js,具體如下:
- #解壓安裝包
- $wget http://nodejs.org/dist/v8.1.0/node-v8.1.0.tar.gz
- $tar zxvf node-v8.1.0.tar.gz
- $cd node-v8.1.0
- #進行編譯和安裝(注意編譯需要很長時間)
- $./configure –prefix=/usr/local/node/*
- $make
- $make install
- ln -s /usr/local/node/bin/* /usr/sbin/
- #npm 配置
- npm set prefix /usr/local
- echo -e '\nexport PATH=/usr/local/lib/node_modules:$PATH' >> ~/.bashrc
- source ~/.bashrc
在node.js安裝完成后可以安裝Dashboard
- #從git庫克隆
- git clone https://github.com/PGBI/kong-dashboard
- #安裝Kong Dashboard:
- npm install -g kong-dashboard@v2
- #啟動kong-dashboard,注意和老版本有變化
- #啟動時候可以自己指定端口號如9001
- kong-dashboard start -p 9001
- #訪問kong-dashboard
- http://localhost:9001
在啟動后再配置Dashboard需要綁定的Kong Server,如下:

訪問Dashboard界面如下:

可以看到Dashboard2.0版本的界面已經(jīng)和V1版本有了較大的變化,在Dashboard上可以實現(xiàn)最近的API接口注冊接入,路由,安全管理,限流熔斷配置的。由于本身還有另外一個開源的kong網(wǎng)關管理平臺Konga,因此后續(xù)準備基于Konga來對網(wǎng)關的關鍵功能進一步做說明和介紹。