關於公司引入網關組件的提議

關於公司引入網關組件的提議

Hello，你們好，好久沒有寫博客了，上年紀了，確實老了，有時忽然想寫點什麼又感受沒什麼乾貨，就又放棄了，此次的話原本是準備在公司內網論壇來寫這邊博客(提議書)，後來的話想了想，也算是本身對網關這一塊的一個沉澱，索性就放在了外網，好了，廢話很少說，先說一下背景，去年我司作了一次比較大的改造，把單體項目拆開成了各個子系統，兼着Dubbo的使用，勉強的算是微服務架構了，其實說微服務架構，確實很牽強。做者第一次作微服務架構仍是15年，不知不覺4年過了。如今再提微服務，就是炒冷飯了。微服務自己確實技術含量不高。今天的話主要不是來說微服務，仍是和你們分享一下，我目前想在公司推行的組件-網關！網關的做用我就不嘰嘰歪歪了，你們自行google，其實做爲架構師的而講，盲目的追風，一味的追求技術名詞是大忌。學技術不是學名詞，而是學架構哲學。好了，不嘰歪，直接上文章結構：

1. 公司現有架構
2. 現有架構存在的問題
3. 網關做用
4. 現有網關的幾大派
5. Kong

1 . 公司現有架構

簡單說下公司業務背景，我司是深圳一家一線互聯網公司(原諒我這可恥的"一線"一詞)，專作電子元器件採購網上商城，是一家To B 端的電商網站，根據業務的特性，前臺網站拆分紅了首頁，詳情頁，列表頁，搜索頁等多個子系統，也就是你們說的微服務。而後簡單說下流量的入口架構。因爲這裏可能涉及到公司隱私問題，因此部分組件用某組件代替：

介紹： 其實很簡單，流量經過DNS解析後，會再流入一些安全組件和SLB組件，而後走向三個Nginx，Nginx把流量導向Tomcat層，後面的持久化層我就不畫了，由於不是本文的重點。公司分爲不少子項目，像上文說的，訂單系統，購物車系統，每一個系統的架構都如此，固然了，有些Nginx是共用的。也就是說，可能有A,B,C,D,E5個系統，AB系統的流量走向共用的三個Nginx，其餘的都是單獨的Nginx集羣，核心業務通常是單獨的三個集羣，不是很重要的業務就能夠共用Nginx.這也是大部分公司的常規作法。

一切看上去彷佛很完美.......

2. 現有架構存在的問題

相信大部分小夥伴看到上面的架構後，有種似曾類似的感受，由於業界來說，作的微服務架構，大部分都是這樣的。把項目拆開，系統間的通信走個RPC，用一套服務管理平臺，而後就是微服務了。其實我我的來說，真心不以爲這是微服務來着，我最先在北京某家公司就是差很少這麼一套架構，RPC通信用的你們都比較熟悉的Dubbo，後來又一家公司用的Spring Cloud大禮包，我的來說，對微服務仍是有一點理解。但這裏不糾結微服務的問題，仍是迴歸到架構自己問題上。我這裏先大體說一些這套流量入口存在的一些問題 ：

2.1 配置分散，節點間沒法通信，運維難以維護。

你們都知道，Nginx節點與節點之間是沒有通信的，都是無狀態的。也就是說，假若有Nginx三個節點，A,B,C,分別路由到編號1，2，3的三個Tomcat上，如今想臨時加一個編號爲4的Tomcat，那運維估計有打人的衝動。由於要分別到三個節點上去改配置，而後"nginx -s reload"，你們想想，每一個項目都是這種架構，nginx的數量也是一個很是大的問題,部署問題，改配置問題。

再好比一些公共的插件，好比nginx的限流module，或者一些鑑權module,如JWT,OAUTH2等，這些若是有變動，分別更改多臺機器上的配置，這無疑是場災難。。。

2.2 nginx原生不支持dlb

這個上面其實也提到了，Nginx是沒有動態負載均衡的功能的，改完配置須要重啓nginx，這對流量密度很是高的公司，是沒法接受的。（固然這一點也有不少很好的方案來支持Nginx的動態lb，你們能夠自行google，像與Consul結合等...）

2.3 沒法動態切流量權重(金絲雀發佈，AB發佈等)

其實也很好理解。好比如今Nginx後掛了3個Tomcat節點，其中一點節點想作AB升級，升級到新版本，要臨時把流量切掉，Nginx是沒法支持動態的更改流量權重的。須要改配置文件後重啓。

2.4 沒有暴露API供監控系統和運維人員使用

一個好的組件須要對外暴露出不少內部的指標，但對於Nginx來講，是不能暴露出當前有多少個upstream，當前哪些上游服務(如Tomcat)有問題，當前的具體配置等等....至關因而黑盒使用。這是很讓人頭疼的一件事。更別提暴露API動態更改配置，更改路由信息了...

2.5 沒有服務發現功能

暫時不講。

2.6 動態可擴展性

講實話，Nginx的可擴展性仍是有的，module的形式，但不支持動態的插拔，也讓人很頭疼。好比寫了一個限流的插件，想動態的調整限流力度。沒法作到。

看到上面這些，你們可能會說了，節點多的問題，多幾個運維就OK了，這些動態調配的功能，我不須要，我每次寫好腳本重啓便可。說實話，確實是這樣，這也是爲何大部分中小型公司不須要網關的緣由，由於不是剛需。大部分的公司可能把全部項目的流量所有接入到幾個Nginx上，經過Nginx來轉發到業務Tomcat上，這種架構，對於中小型公司來說，毫無問題！但若是想作一個接入層管理平臺，或者網關平臺。僅僅使用Nginx，是遠遠不夠的。下面再給你們畫一副圖，看看理想中的網關平臺是怎樣的: （下圖省掉一些無關組件，不表明實際架構如此，抓住重點便可）

你們能夠看到，把全部商城的接入層Nginx所有抽取成一套網關集羣。全部流量都從這裏走。那麼問題來了，這個網關平臺和Nginx集羣到底有什麼不一樣呢？看下圖：

其實說白了，我是想定製化一套平臺，解決上面的諸多問題。如今一一對應上來解答：

2.1【 配置分散，節點間沒法通信，運維難以維護。】

這個就不用說了，由於咱們抽取出了一組GateWay集羣，又有管理平臺，因此只要在平臺上配置，無需登錄到各個節點去進行配置。之後咱們的運維同窗就能夠到GateWay管理平臺上配置相似於這樣的數據:

項目	下游節點	權重	心跳檢測URL	節點狀態	操做
訂單系統	192.168.157.123:8888	50	/	存活	-
訂單系統	192.168.157.124:8888	100	/test	死亡	-
訂單系統	192.168.157.125:8888	100	/test1	存活	-

當想爲訂單系統添加一個節點的時候，只須要在管理平臺上新加一下，當想人工摘掉一個節點的時候，也是同樣的在UI平臺操做。總之，把運維培養成傻子，什麼都不用幹，只須要在平臺上配置便可。

2.2【 nginx原生不支持dlb】

這個就更不用說了，咱們的GateWay平臺確定是要支持動態的lb功能的，也就是說，在平臺上配置好，當即生效，無需重啓組件！

2.3 【 沒法動態切流量權重(金絲雀發佈，AB發佈等)】

同理，若是想作一些流量的切換，只須要對權重進行操做便可。也是動態生效的。

2.4 【沒有暴露API供監控系統和運維人員使用】

咱們的網關管理平臺就是根據網關集羣暴露的API來操做網關的。固然具有相關的監控API和操做API了。

2.5 【沒有服務發現功能】

咱們的網關集羣必須具有這個功能，請求能夠直接下發的微服務調用，無需走到Tomcat

2.6 【動態可擴展性】

這個其實也是同樣的道理，咱們的網關平臺要支持動態配置插件，而且實時生效，而且動態的配置插件內容。

好了，大體想作出的效果也看到了，其實網關的做用遠不止這些。後面會和你們細講。你們思路必定要轉換過來。就是說，咱們要一個全局AOP的點，管理着全部API，讓後面的服務專作本身該作的業務 。 其次就是，操做的便捷性，也就是咱們常說的，把運維培養成傻子。。

3. 網關做用

網關做用其實就太多太多了，其實網關這個詞是比較大的，不少搞技術的把網關分爲接入層網關和服務網關，我以爲是很是正確的。每層網關的做用實際上是不同的。接入層的網關最核心的功能就是LB，而後就是創建的LB之上的一些延伸，好比說斷路器，限流，請求聚合，協議轉換等，而服務網關，毋庸置疑，實際上是對微服務的一種代理，最核心的功能就是服務發現了。也就是常說的，面向服務調用，這樣就把下游檢測和微服務體系結合在一塊兒了，這個後面和你們分享。

再有一些常見的功能好比說： 服務分組管控、灰度發佈、熔斷監控、容器化遷移、統一出入口管理，實現協議適配、協議轉發、安全策略（WAF）、防刷、流量管控、日誌監控，能夠對流量進行靈活動態的管控，API網關也起到安全防禦的功能，提供IP黑名單和URL黑名單 我這裏就不一一列舉了，其實說實話，我這邊想在公司推行網關並非由於其做用的多，而是想解決上面說的一些問題的，至於後面的功能，要慢慢接入，從無到有是很是重要的！

網關的穩定性建設十分重要。

網關的穩定性建設十分重要。

網關的穩定性建設十分重要。

4. 現有網關的幾大派

最近作技術選型時，把幾大網關作了下對比，這裏稍微分享下，各大網關的選擇，意見不一，選擇本身適合的纔是最重要的，咱們選技術的時候，不在意它的功能多很少，時尚不時尚，而是能不能解決現有的問題。

4.1 zuul 1.0 & zuul 2.0

zuul1 你們可能比較熟悉，隨着Spring Cloud對zuul1的支持，你們都紛紛使用，我這裏就不畫圖了，直接畫重點:

1. zuul1 目前都結合Spring Cloud大禮包使用，具備服務發現功能，因爲整合了Eureka，因此節點的自動上下架支持的很是好！
2. zuul1屬於線程池模型，不能支持高吞吐量，當後端服務有問題了，須要作斷路器 。
3. 我司需求: 不須要具有服務發現功能，但節點的自動上下架必須有。若是用原生的zuul1確實能夠達到節點路由，但須要本身作斷路器。只有與Spring Cloud結合時，纔有支持好的斷路器使用。

zuul2 ：

1. NIO模型，性能高(沒有官方數據，業界測試結果不理想)
2. 接入APM監控系統困難
3. 學習成本高

4.2 Spring Cloud GateWay

Spring Cloud GateWay :

1. NIO模型，使用WebFlux,與Spring Cloud大禮包結合，自動服務發現。
2. 業界測試結果不理想
3. 組件較新

4.3 Nginx

Nginx派系的網關比較多，orange,kong還有一些基於openresty開發的就不一一列舉了，Nginx派系的是我比較推薦的。

5. Kong

Kong的官方資料比較全，由於這份博客，主要仍是對內的，因此這些知識準備口頭講。這裏給你們丟一張功能圖，基本上網關該有的功能都有了，沒有的功能能夠經過plugin動態擴展:

總結

好了，算了大體寫完了，其實寫的很草率，前面主要講了想引入網關的緣由，後面組件對比的話稍微寫了下本身的一些見解，我這裏給你們的建議是，你們若是使用的是Spring Cloud生態系，使用zuul1 和Spring Cloud GateWay是比較不錯的。鑑於我司不是微服務架構體系，因此我這裏仍是選擇了一個比較純正的API網關Kong,Kong的官方資料很是詳細，使用起來很是瀟灑。是一個我很是喜歡的組件，你們感興趣能夠自行學習。

TODO :

• 動態降級(需接入監控平臺)，人工降級。
• 動態限流規則
• etc ... 凡是能在網關裏作的事，所有能夠作成平臺化配置的東西。固然了，一些高頻功能作。低頻的再考慮。