前言
前幾天開源釋出了 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 加⭐⭐