前言

前幾天開源釋出了 Kong.Net 專案，收到了大量園友的反饋，開源當天就突破了 100 個star ，可喜可賀，但是從側面也說明，我們 .NetCore 陣營真的非常需要擁抱開源，應該敞開心扉，集眾家之長，為我所用，針對有些朋友還不太瞭解 Kong 的使用方法，本文作一些簡單的介紹。

專案地址：https://github.com/lianggx/Kong.Net 請為我們點選 star 加⭐⭐

宣告

本文準備介紹市面上的一些常見的閘道器，不吹不黑，實事求是，理性討論，從我做起。

微服務閘道器

下圖直觀的為我們展示了Kong閘道器在微服務中的作用

還可以和 kubernetes 進行無縫整合

(來源：https://konghq.com/solutions/kubernetes-ingress/)

上圖是Kong和K8s相結合的結構圖，通過Kong閘道器，可以使業務系統的整合工作變得更加高效且易於管理。

升級位服務網格等部署方案

除了上面的應用場景，Kong 還帶來了下面的服務網格等各種部署方案，任君選擇，童叟無欺！

(來源：https://konghq.com/solutions/kubernetes-ingress/)

為什麼選擇了 Kong

1. Spring系列

其實在選擇 Kong 之前，我也曾嘗試了其它的閘道器，運維級別的比如Nginx咱就不提了，單就 Spring-cloud Gateway 幾乎可以一招吃遍天下，況且還有阿里這個大廠做護法，Nacos/Dubbo 這種實驗室+超高流量的實踐後開源，那也是極其可怕的，唯一的不好就是除了Java外其它語言沒什麼機會與之結合，非用不可也不是不行，但是就是非常麻煩，中小企業可以通過上雲的方案使用雲原生，但是對於自建機房、自建閘道器和服務叢集的，或者是不方便上雲的企業來說，只能選擇Java。

2. 自帶閘道器

.NetCore 在閘道器方面也不是沒有建樹，Ocelot 的star也不少了，但是對於成功的商業應用案例來說，缺少一個有力的推廣人，特別是對於http請求的轉發，其基於HttpClient的特性，使得在大併發的情況下，反應非常遲鈍，一句話：底層太重。不能輕裝上陣，就好像轉換到Linux後，總是在某些方面有點水土不服。

3. 最終選擇

部落格園也有大量關於Ocelot對於其它閘道器的效能對比，這裡我就不再一一列出了，大家有興趣可以在站內搜尋一下關鍵字Ocelot。我在Ocelot的github專案上仔細的查看了每一條issue，並且拿這些issue的回答時間和Kong的issue回答作對比，發現Kong的issue問題響應時間大大快於Ocelot，這可能是因為Kong的貢獻值高達200多人的原因

Kong的高效得益於lua和高水平的貢獻者，該語言是nginx的開發語言，nginx的高效眾所周知，Kong通過Kong Igress Controller和K8s完美結合

為什麼需要Kong.Net客戶端

還有朋友反饋，既然Kong閘道器如此完善，RESTFul API 如此高效，為什麼還需要Kong.Net客戶端呢？這個問題提的非常好!

1. 營銷故事
沃爾瑪曾經有一個經典的營銷案例，說的是啤酒和尿片的故事，說營銷人員通過調查，，發現許多男人在下班後都會到超市買給孩子買尿片，他們就想到，如果在尿片旁邊擺上啤酒，這些男人會不會同時將啤酒丟人購物車中呢，通過一段時間的觀察，超市裡的啤酒銷量大幅提升。從這個故事中我們發現，便利性和易用性是多麼的重要，如果尿片和啤酒在分別堆放在兩個不同的貨架上，那麼如果一個買尿片的男人很大概率不會想起來買啤酒，或者說繞很遠的距離去購買啤酒。

從這個場景中我們看到，便利性是多麼的重要！

2. 為了快速接入

通過Kong.Net，一個從未接觸過Kong閘道器的人就是可以通過幾行程式碼完成接入，他不需要去理解RESTFul API的介面文件，不用擔心傳錯引數，不用關心是否在配置過程中是否由於某個配置錯誤引起不明BUG，這些都是極大的提升開發效率的行為，特別是進一步，通過社群的力量，我們可以一起完善這個SDK，使之越來越高效，BUG越來越少，接入越來越快，這就是開源的力量！

Kong 的安裝部署

Kong閘道器的安裝部署非常簡單，有兩種部署方式，rpm 和 docker ，建議 docker方式部署，因為實在是太方便了，只需要複製官網的幾個命令，相信我，你不用一分鐘就可以部署起來，這裡我就不再搬運官方的 docker 安裝部署教程了，大家可以參考下面的連結，主要怕官網有更新的話，我這搬運有可能就過時了

https://docs.konghq.com/install/docker/?_ga=2.264012361.438943297.1562658881-406131744.1553753787

Kong Dashboard 控制檯

Kong 閘道器的 Dashboard 目前有兩個畢竟大的開源的Dashboard，分別是

// pgbi/kong
https://github.com/PGBI/kong-dashboard/commits/3.0

// pantsel/konga
https://github.com/pantsel/konga

從維護更新的頻率來看，pgbi/kong 在走下坡路，而konga維護良好，建議大家使用konga，他們倆的操作介面大同小異，比如我目前使用的是Konga

安裝方式推薦：docker

Kong 外掛

Kong的外掛基於lua編寫，內建外掛非常豐富，支援驗證、安全、流量控制、監控和統計、日誌等等，甚至支援自定義外掛，你也可以編寫自己的外掛加入到Kong閘道器中

就拿流量控制來說，其控制粒度可以具體某個Target，也可以應用到Global，非常靈活。

Kong 響應

在使用Kong進行轉發後，Kong會向客戶端寫入一個預設的頭資訊

除了預設的頭資訊，你也可以在Kong服務配置中向客戶端寫入自定義的響應頭資訊，非常方便。

健康檢查

Kong的健康檢查機制非常有意思，分為主動式檢查和被動式檢查兩種，而且兩種健康檢查方式的配置基本相同，主動檢查會修改客戶端的狀態，將不健康的客戶端移除，將恢復健康後的客戶端主動加入服務叢集，而被動式檢查則正好相反；特別有意思的是，其健康檢查的路徑為根目錄“/”，當然也支援定義路徑，最重要的是可以自定義httpstatus程式碼，比如你可以定義4.3、404為健康狀態，也可以定義 200、302等一切httpstatus程式碼。

結束語

優秀的開源產品值得我們深入瞭解，並結合.NetCore實際使用，這會讓.NetCore的生態越來越完善，讓社群更強大。
專案地址：https://github.com/lianggx/Kong.Net 請為我們點選 star 加⭐⭐