一. API網關是怎么演化出來的?
我們最開始的服務是單題服務, 所有的功能業務都是在一台服務器上. 可以通過過濾器來實現安全的校驗, 如權限校驗等.
單體時代,整個微服務的架構也比較簡單. 后來隨着業務的復雜度越來越高, 我們切換到了微服務時代
進入微服務時代, 有如下特點:
1. 原來單體服務被拆分為n個小的微服務
2. 這些微服務有一些公共的跨橫切面的功能邏輯， 比如：安全，路由，日志等等。 如果每個微服務都來處理這些功能， 微服務就會很復雜， 微服務不但要處理業務邏輯，還要處理安全，路由，日志等邏輯， 開發的負擔就會比較重。 所以 ，我們把這些公共的服務抽取出來， 放在網關這樣的一個服務上， 這就是在微服務上為什么會產生網關這樣的概念。
總結: 把微服務公共的功能抽取出來， 形成一個獨立的組件，獨立的服務，處理跨橫切面的邏輯
3. 另一方面， 在單體時代， 我們的客戶端主要是瀏覽器， 在微服務時代， 客戶端可能是瀏覽器，可能是手機， 可能是我們對外提供的API。
如果讓這些客戶端單獨對接微服務， 也是很復雜的。 如果讓他們都對接網關服務，外面的各種平台只需要對接一個入口， 通過網關接入就可以了，不需要知道很多內部細節。
總結：網關是怎么誕生的？
1. 是將各個微服務跨橫切面的東西抽取出來， 做成獨立的網關服務
2. 作為單點的入口， 讓外面各種形態可以方便的接入企業內部的微服務。
二. 網關的基本功能
如上圖所示, 網關的主要功能有: 單點入口, 路由轉發, 熔斷限流, 日志監控, 安全認證等等
1. 單點入口: 有了網關以后, 客戶端只需要看到一個入口, 不需要看到內部復雜的細節
2. 路由轉發: 客戶端請求來了, 對應到網關只有一個入口, 那么具體請求的是哪一個服務呢?網關要做一個路由轉發
3. 限流熔斷: 在微服務時代, 微服務有很多, 每一個微服務都可能會出錯或者產生延遲, 如果沒有好的限流熔斷機制, 很容器造成客戶端被阻塞, 或者產生嚴重的后果,如雪崩效應. 網關要做一個限流熔斷,保護后台服務的這樣的一個功能.
4. 日志監控: 所有的請求經過網關, 我們都可以寫日志,對他進行監控. 整個服務的健康狀態, 有沒有人利用網關做壞事情等. 我們還要時刻掌握網關的性能狀況. 可以在網關上增加監控來做到
5. 安全認證: 所有的請求都通過網關進入到微服務, 網關就像是一道門, 一個請求進來, 我們要在門口檢查一下, 他是不是安全的. 是否是經過認證的.
三. Netflix Zuul網關
在Nexflix官網上, 描述: zuul是一個邊界服務, 提供動態路由, 監控, 彈性, 安全等功能.
亮點: 可動態發布的過濾器機制.
網關是整個服務的門口, 我們不能經常性的重啟發布網關服務. 他有一些跨橫切面的功能, 我們最好是能夠動態的去插拔, 不需要重新部署的情況下, 動態的修改網關跨橫切面的邏輯. 這是zuul提供的可動態發布的過濾器,大大提高了靈活性
- Zuul在英文中是怪獸的意思, 寓意看門神獸
- 2014年被納入spring cloud體系
四.Zuul網關高級應用場景
4.1 紅綠部署
綠色集群是老系統, 紅色集群是新系統. 當新功能上線以后, 通過網關切流量, 先切部分流量到紅色集群,也就是新系統. 做金絲雀測試. 測試沒問題, 在逐漸切換到紅色集群,直至所有的流量全部切換到紅色集群. 期間, 有任何錯誤, 可以直接切換回老系統
4.2 開發者測試分支
有些功能比較關鍵, 需要開發人員去線上做測試. 這叫開發者測試分支. 測試分支不是直接調用生成得了流量, 而是開發人員用自己的流量的方式, 去調用測試集群. 這種能力也是通過zuul網關來支持的.
zuul網關,可以把內部開發請求的流量, 達到測試集群, 去做測試. 這樣既可以測試生成環境的功能, 又不會影響生產的實際流量. 網關會做流量的判斷
4.3 埋點測試
還可以使用網關實現埋點測試. 應用發到生產上以后, 可以分為埋點的和不埋點的. 埋點就是你要對應用的一些邏輯進行埋點. 比如instruments埋點或者調用鏈埋點. 有時候,埋點是有性能開銷的. 我們把代碼全部發不到生產上去, 可能會有性能問題. 埋點需要知道系統的性能情況, 要做買點測試. 我就可以將埋點的應用發到生產上, 測試人員就可以測埋點的集群. 通過買點測試可以詳細了解應用的情況. 等到埋點測試完成, 發現性能是ok的, 我們就可以吧埋點去掉. 發到生產上.
4.4 壓力測試
應用咋上線之前, 會先部署到Squeeze壓力測試的集群中. 這時其實是要用生產流量的. 但這個生產流量是鏡像的或者拷貝復制的. 真實的生成流量, 還是到真實的應用當中. 因為這個請求是鏡像的或這個拷貝的,所以流量處理完以后不會返回給客戶端, 他會被丟棄掉. 這個請求主要是用來測試應用上線前壓力測試的.
4.5 調試路由
有的時候生成環境除了一些問題, 我們需要用到調試路由. 比如, 測試人員在header中增加一些參數. 或者特殊的信息放在里面. 請求過來以后, 網關會把這部分流量分配到調試集群. 這樣就可以做線上的調試, 來發現一些問題.
4.6 金色雀測試
我們也可以利用網關實現金絲雀測試. 新的應用上線之前, 分為baseLine集群和canary集群.通過網關, 調撥少量的流量到canary金絲雀, 如果流量沒有問題,說明整個應用是健康的. 再全量的切換到新的版本. 如有問題,隨時切換回去.
4.7 粘性金絲雀
粘性金絲雀測試也是金絲雀測試. 如果不帶粘性, 那么流量過來到網關, 網關是會隨機分配給baseLine和金絲雀集群的. 如果是粘性, 網關有黏住你的能力, 如果某一次你走的是金絲雀, 那么網關會記住你的信息,如ip, 下次你來了, 還讓你走金絲雀集群. 他就不會隨便跳了. 這在有些情況下是必須的, 不能讓ip跳來跳去, 不然可能導致功能或結果不一致, 黏住就是一致的了.
4.8 跨區域高可用
Neffilx的網關是分區部署的, 分部部署在AWS的三個區域, 三個區域的zuul都是高可用的. 一個掛掉, 可以切換到另一個區域的服務器
4.9 防爬蟲共計
netflix在網關上面對所有的流量進行監控, 發現異常流量, 爬蟲或者是攻擊性的, 他有能力拒絕請求, 保護后面的服務
4.10 健康檢查和屏蔽壞節點
Netflix會對請求進行度量分析, 監控. 如果某一個后台的微服務節點出錯了, 或者不響應了.netflix有自動摘除無用服務器, 屏蔽壞的節點. 這樣用戶的體驗就更好.