關於公司引入閘道器元件的提議
Hello，大家好，很久沒有寫部落格了，上年紀了，確實老了，有時突然想寫點什麼又感覺沒什麼乾貨，就又放棄了，這次的話本來是準備在公司內網論壇來寫這邊部落格(提議書)，後來的話想了想，也算是自己對閘道器這一塊的一個沉澱，索性就放在了外網，好了，廢話不多說，先說一下背景，去年我司做了一次比較大的改造，把單體專案拆開成了各個子系統，兼著Dubbo的使用，勉強的算是微服務架構了，其實說微服務架構，確實很牽強。作者第一次做微服務架構還是15年，不知不覺4年過了。現在再提微服務，就是炒冷飯了。微服務本身確實技術含量不高。今天的話主要不是來講微服務，還是和大家分享一下，我目前想在公司推行的元件-閘道器！閘道器的作用我就不嘰嘰歪歪了，大家自行google，其實作為架構師的而講，盲目的追風，一味的追求技術名詞是大忌。學技術不是學名詞，而是學架構哲學。好了，不嘰歪，直接上文章結構：
- 公司現有架構
- 現有架構存在的問題
- 閘道器作用
- 現有閘道器的幾大派
- 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的支援，大家都紛紛使用，我這裡就不畫圖了，直接畫重點:
- zuul1 目前都結合Spring Cloud大禮包使用，具有服務發現功能，由於整合了Eureka，所以節點的自動上下架支援的非常好！
- zuul1屬於執行緒池模型，不能支援高吞吐量，當後端服務有問題了，需要做斷路器 。
- 我司需求: 不需要具備服務發現功能，但節點的自動上下架必須有。如果用原生的zuul1確實可以達到節點路由，但需要自己做斷路器。只有與Spring Cloud結合時，才有支援好的斷路器使用。
zuul2 ：
- NIO模型，效能高(沒有官方資料，業界測試結果不理想)
- 接入APM監控系統困難
- 學習成本高
4.2 Spring Cloud GateWay
Spring Cloud GateWay :
- NIO模型，使用WebFlux,與Spring Cloud大禮包結合，自動服務發現。
- 業界測試結果不理想
- 元件較新
4.3 Nginx
Nginx派系的閘道器比較多，orange,kong還有一些基於openresty開發的就不一一列舉了，Nginx派系的是我比較推薦的。
5. Kong
Kong的官方資料比較全，因為這份部落格，主要還是對內的，所以這些知識準備口頭講。這裡給大家丟一張功能圖，基本上閘道器該有的功能都有了，沒有的功能可以通過plugin動態擴充套件:
總結
好了，算了大致寫完了，其實寫的很草率，前面主要講了想引入閘道器的原因，後面元件對比的話稍微寫了下自己的一些看法，我這裡給大家的建議是，大家如果使用的是Spring Cloud生態系，使用zuul1 和Spring Cloud GateWay是比較不錯的。鑑於我司不是微服務架構體系，所以我這裡還是選擇了一個比較純正的API閘道器Kong,Kong的官方資料非常詳細，使用起來非常瀟灑。是一個我非常喜歡的元件，大家感興趣可以自行學習。
TODO :
- 動態降級(需接入監控平臺)，人工降級。
- 動態限流規則
- etc ... 凡是能在閘道器裡做的事，全部可以做成平臺化配置的東西。當然了，一些高頻功能做。低頻的再考慮。