Kong是Mashape開源的高性能高可用API網關和API服務管理層。它基于OpenResty，進行API管理，并提供了插件實現API的AOP。Kong在Mashape 管理了超過15,000 個API，為200,000開發者提供了每月數十億的請求支持。本文將從架構、API管理、插件三個層面介紹Kong。

架構

按照康威定律，我們系統架構會拆的很散，系統由一堆服務組成，如下圖所示：

庫存服務、優惠券服務、價格服務時之前都會做一些特殊處理，如限流、黑白名單，日志、請求統計。而這些處理幾乎是所有服務都需要的，這不就是我們常說的AOP嘛，當我們服務多起來的時候，應該將這些通用處理集中到一個地方進行管理，如下圖所示：

和下圖有點相似：

1.為什么要用Kong作為NetCore下的API網關？

開源，云原生(Cloud-Native)，ServiceMesh,快速，彈性，RESTful還有分布式微服務的抽象層
2.基于NGINX構建的網關，擁有更高的性能,并且在2015開源
3.活躍的社區，在github上有111個Contributors,修復bug迅速，基本每3個月一個版本
4.支持插件化，目前支持的插件有32個，包含授權，安全，限流，Serverless，分析和監控，轉換，日志。
5.支持企業版本和社區版本

架構預覽

基于OpenResty(Nginx & Lua Scripting)

上圖很清晰的看見Kong的架構圖，以Nginx作為基礎, OpenResty構建RESTful，支持集群和數據庫存儲數據，插件化，還有支持用RESTful來管理端。

集群架構預覽

這里講下Kong的集群原理吧，Kong在0.11.0版本之前用的是serf來做集群的，那么為什么不用serf做集群呢？開發者給出的理由如下:
1.依賴serf，serf并不屬于Nginx/OpenResty
2.這種依賴相互間通信來同步的機制對于deployment和容器化都有些不便
3.在運行的Kong節點觸發serf需要一些阻塞的I/O
0.11.0版本的實現思路是以數據庫為中心，增加一個cluster events的表，任何Kong node都可以向數據庫發送變更消息，其他節點輪訓數據庫改動，然后更新緩存內容，如果有節點重啟連上數據庫節點就可以工作了。

Kong的安裝

Kong的安裝方式支持很多主流的平臺，目前不支持Windows，支持的安裝方式如下：

Kong的安裝，為了方便我這里就使用docker安裝了
1.創建專屬kong的網絡（docker的最佳實踐）--link 過時了啊
docker network create kong-net
2.選擇你使用的數據庫，默認使用的是PostgreSQL
如果你使用的是Cassandra數據庫：
提示下:Cassandra >=3.0
docker run -d --name kong-database \ --network=kong-net \ -p 9042:9042 \ cassandra:3
如果你使用的是PostgreSQL
docker run -d --name kong-database \ --network=kong-net \ -p 5432:5432 \ -e "POSTGRES_USER=kong" \ -e "POSTGRES_DB=kong" \ postgres:9.6
3.數據庫遷移，初始化庫表結構：

docker run --rm \--network=kong-net \ ? ?-e "KONG_DATABASE=postgres" \ ? ?-e "KONG_PG_HOST=kong-database" \ ? ?-e "KONG_CASSANDRA_CONTACT_POINTS=kong-database" \kong:latest kong migrations up

4.啟動kong

docker run -d --name kong \--network=kong-net \ ? ?-e "KONG_DATABASE=postgres" \ ? ?-e "KONG_PG_HOST=kong-database" \ ? ?-e "KONG_CASSANDRA_CONTACT_POINTS=kong-database" \ ? ?-e "KONG_PROXY_ACCESS_LOG=/dev/stdout" \ ? ?-e "KONG_ADMIN_ACCESS_LOG=/dev/stdout" \ ? ?-e "KONG_PROXY_ERROR_LOG=/dev/stderr" \ ? ?-e "KONG_ADMIN_ERROR_LOG=/dev/stderr" \ ? ?-e "KONG_ADMIN_LISTEN=0.0.0.0:8001, 0.0.0.0:8444 ssl" \-p 8000:8000 \-p 8443:8443 \-p 8001:8001 \-p 8444:8444 \kong:latest

5.看網關有沒有啟動
在本機 curl -i?http://localhost:8001/，或者用瀏覽器訪問8001端口。如果出來一大堆json，表示成功。

以AspNetCore為例子訪問

mkdir AspNetCorecd AspNetCoredotnet new webapidotnet run

我們以netcore做的api為例子訪問localhost:5000/api/values，前面網關搭建起來了，并且支持RESTful，現在有開源的dashboard，我們就用KongDashboard來演示，如何構造搭建和訪問。

# 全局安裝kong-dashboard npm install -g kong-dashboard# 啟動 kong-dashboard kong-dashboard start --kong-url http://localhost:8001# 啟動kong-dashboard，并且自定義端口 kong-dashboard start \ ?--kong-url http://kong:8001 \--port [port]# 啟動kong-dashboard并且啟動基礎認證 kong-dashboard start \ ?--kong-url http://kong:8001 \--basic-auth user1=password1 user2=password2# 看kong-dashboard 啟動參數 kong-dashboard start --help

啟動成功后用瀏覽器打開localhost:8080如下圖所示：

那么我們增加一個NetCoreAPI，在DashBoard，如圖所示：

因為是GET請求，那我我們用瀏覽器訪問，瀏覽器 -> 網關 -> NetCore程序。
打開瀏覽器直接訪問http://localhost:8000/api/values,返回["value1","value2"]則代表正常。
如下圖所示：

最后，AspNetCore微服務下的網關-Kong系列，后面會繼續更新，會講解到Kong的插件的使用，插件的開發，使用的一些坑，網關性能分析和日志可視化，源碼解析等，歡迎大家關注我的github:?https://github.com/WithLin。

相關文章

• 微服務網關Ocelot

• Ocelot API網關的實現剖析

• Ocelot——初識基于.Net Core的API網關

• Ocelot網關

• Ocelot統一權限驗證

• Ocelot監控

• 給Ocelot做一個Docker 鏡像

• Ocelot + Consul實踐

• .NET Core開源API網關 – Ocelot中文文檔

• .NET微服務體系結構中為什么使用Ocelot實現API網關

• .NET Core微服務之基于Ocelot實現API網關服務

• .NET Core微服務之基于Ocelot實現API網關服務（續）

• Ocelot.JwtAuthorize：一個基于網關的Jwt驗證包

• API網關模式

• .NET Core微服務之基于Ocelot+IdentityServer實現統一驗證與授權
  

原文地址：https://www.cnblogs.com/WithLin/p/9343406.html

.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結

以上是生活随笔為你收集整理的AspNetCore微服务下的网关-Kong(一)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。