在日常工作中，不同的場合下，我們可能都會聽說網關的概念，當然通常是指業務網關（API網關），負責API的輸入和輸出。有了業務網關之后，各個API服務提供者可以專注于自己的業務邏輯處理，而API網關更專注于安全、流量、路由等問題。從功能層次我們又會聯想到一個概念——代理。網關與代理的區別：代理本質是數據的透傳，協議不會發生變化；網關在數據透傳的背景下，還會涉及協議的轉換，比如從HTTP到Dubbo。

那么作為一名架構師，我們該如何選型“業務網關”呢？我們自己先要學會做技術選型，自己預期有一個技術成本的預判，比如我推薦使用Spring Cloud Alibaba+Spring Gateway，就是我自己作為一個架構師的技術預判。

Zuul

Zuul是Netflix開源的微服務網關，可以和Eureka、Ribbon、Hystrix等組件配合使用，Spring Cloud對Zuul進行了整合與增強，Zuul總共有兩個大的版本：Zuul1.0和Zuul2.0，目前最新的版本為v2.2.0，Zuul1.0和Zuul2.0版本之間功能差異性非常大。

Netflix的Zuul包含如下功能：

• 身份認證與安全： 識別每個資源的驗證要求，并拒絕那些與要求不符的請求；
• 審查與監控：在邊緣位置追蹤有意義的數據和統計結果；
• 動態路由： 動態地將請求路由到不同的后端集群；
• 壓力測試 ： 逐漸增加指向集群的流量，以了解性能；
• 負載分配： 為每一種負載類型分配對應容量 ，并棄用超出限定值的請求 ；
• 靜態響應處理：在邊緣位置直接建立部分響應，從而避免其轉發到內部集群；
• 多區域彈性： 跨越AWS Region進行請求路由，旨在實現ELB（Elastic Load Balancing）使用的多樣化和 以及讓系統的邊緣更貼近系統的使用者。

以上介紹來自Zuul官方文檔，但其實開源版本的Zuul以上功能一個都沒有——開源的Zuul只是幾個Jar包而已，以上能力指的應該是Netflix官方自用的Zuul的能力；Netflix自用的Zuul能力是比較強大的，可使用Groovy編寫過濾器，并且可動態加載/卸載、修改規則，而且使用Cassandra作為數據庫，然而開源版本這些一個都沒有；Spring Cloud中，Zuul絕大部分功能都是Spring Cloud團隊為Zuul開發的；所以Zuul 2.x的開源進度延后一年，Spring Cloud團隊開發了自己的SCG，并宣布Spring Cloud不打算支持Zuul 2.x，你還覺得意外嗎？看到這里，很多人可能沒有動力學習Zuul了，個人認為還是可以了解一下的，后面講到SCG時，你會發現很多設計理念是相通的。

既然說到了Spring Cloud對Zuul的封裝，那么我們來簡單的分析下Spring Cloud與Zuul的關系。Spring Cloud通過Spring Cloud Netflix 1.X來封裝Zuul1.0，1.X的最后一個版本是v1.4.7.RELEASE，對應的Zuul版本是1.3.1。Spring Cloud Netflix從3.X開始就沒有封裝Zuul網關，包括Zuul1.0和Zuul2.0，也就是說開發者想要通過Spring Cloud來復用Zuul，只能使用Zuul1.0，暫時不能復用Zuul2.0。

Zuul目前在github上的star數為10.2k，fork數為2k，也就是說還是有很多開源愛好者會基于Zuul來定制化業務網關。

除了開源的Spring Cloud定制化Zuul，開源微服務框架jhipster也參與了定制，并集成到它的生態中。Jhipster主要包含generator-jhipster和jhipster-registry，前者star數微17.7k，fork數為3.5k，后者star數為604，fork為607。

Zuul1.0整體架構設計如圖所示。

Zuul2.0整體架構設計如圖所示。

Spring Cloud Gateway

SCG是基于Spring Framework 5.0和Spring Boot 2.0構建的API網關，提供路由等功能。其旨在提供一種簡單而有效的方法路由到API，并為它們提供跨領域的關注點，例如：安全性、監視/指標和彈性。

主要特性：

• J ava8
• Spring Framework5
• Spring Boot2
• 動態路由
• Spring Handler Mapping 內置的路由匹配
• HTTP 請求的路由匹配（路徑、方法、 Hea der 、主機等）
• 過濾器限定范圍以匹配路由
• 過濾器可以修改下游 HTTP 請求和 HTTP 響應（添加、刪除 Header 、添加 / 刪除參數、重寫路徑、設置路徑等）
• API或配置驅動
• 支持Spring Cloud Discovery Client配置路由

SCG的專業術語包括：

• 路由：它是基本構建模塊，主要包含ID、URI、斷言集合以及過濾器集合，如果能夠匹配斷言就會執行路由。
• 斷言： 主要是指Java8的函數式斷言，輸入類型是Spring Framework的ServerWebExchange，基于斷言可以匹配基于headers或者parameters的http請求。
• 過濾器： 它是通過特殊的工廠方法構造的基于Spring Framework GatewayFilter的實現，通過過濾器開發者可以在http請求下行之前修改請求響應參數，在請求響應返回之后可以修改響應的結果。

SCG整體架構設計如圖所示。

自研網關

一個API網關的基本功能包括統一接入、協議適配、流量管控與容錯，以及安全防護，這個四大基本功能構成了網關的核心能力。網關首要的功能是負責統一接入，然后將請求的協議轉換成內部的接口協議，在調用的過程中還要限流、降級和熔斷等容錯的方式來保護網關的整體穩定，同時網關還要做到基本的安全防護（防刷控制），以及黑白名單（比如IP地址白名單）等基本的安全措施，主要包括：統一標準接入，具備高性能、高并發和高可靠性，具備負載均衡的能力；

除了基本的四個功能，網關運行良好的環境還包括注冊中心（比如通過Nacos讀取已經發布的API接口的動態配置）。為了實現高性能，將數據全部異構到緩存（比如Redis）中，同時還可以配合本機緩存來進一步的提高網關系統的性能。為了提高網關的吞吐率，可以使用NIO+Servlet3異步的方式，還可以利用Servlet3的異步特性將請求線程與業務處理線程分開，為后續的線程池隔離做好基本的支撐。訪問日志的存儲我們可以放到Hbase或者ES中，如果要作為開放網關使用，那么需要一個支持OAuth2.0協議的授權中心，同時還可以引入Nginx+Lua的方式，將一些基本的校驗判斷前置到應用系統之上，這樣可以更加輕量級的處理網關接入的問題。

主要包括接入層，開發者可以通過Nginx和Lua腳本，解決限流、黑白名單、路由、負載均衡、長短連接以及容災切換的問題。網關需要保證服務的穩定性，需要接入注冊中心，因為本書是Spring Cloud Alibaba的布道書籍，所以強烈推薦使用Nacos作為注冊中心和配置中心。統一的鑒權中心，主要是統一解決網關為各個API服務的鑒權問題，當然可以按照服務維度做隔離，自定義鑒權規則。統一用戶中心主要是解決用戶登錄問題，確保微服務調用的安全性。

自研網關還需要有泛化功能，使用者在調用提供者的接口的時候，不再需要API提供者的客戶端JAR包，因此也就沒有了POJO，通過泛化的方式進行遠程調用。一般情況下我們要通過RPC調用接口提供方的服務，首先在系統中嵌入接口提供者的JAR包，然后使用JAR包里面的類和方法。對于一個網關系統來說，如果要調用N個接口，就需要N個JAR包，這樣的網關是很難維護的，當然Dubbo RPC是支持泛化的。

網關要具備時間校驗、方法校驗、版本校驗和簽名校驗等功能，當然網關還需要具備服務降級、日志記錄以及監控與告警功能。

對比以上三種網關

總結

推薦使用Spring Cloud Alibaba+Spring Cloud Gateway，可以更加高效的利用Spring Cloud ALibaba的服務治理能力去融合網關API的治理，從而提升業務服務API的系統穩定性。