上海羊羽卓進出口貿易有限公司一文帶你搞懂API網關
作者：aCoder2013
地址:github.com/aCoder2013/blog/issues/35前言
假設你正在開發(fā)一個電商網站，那么這里會涉及到很多后端的微服務，比如會員、商品、推薦服務等等。
那么這里就會遇到一個問題，APP/Browser怎么去訪問這些后端的服務? 如果業(yè)務比較簡單的話，可以給每個業(yè)務都分配一個獨立的域名(https://service.api.company.com)，但這種方式會有幾個問題:
每個業(yè)務都會需要鑒權、限流、權限校驗等邏輯，如果每個業(yè)務都各自為戰(zhàn)，自己造輪子實現一遍，會很蛋疼，完全可以抽出來，放到一個統(tǒng)一的地方去做。如果業(yè)務量比較簡單的話，這種方式前期不會有什么問題，但隨著業(yè)務越來越復雜，比如淘寶、亞馬遜打開一個頁面可能會涉及到數百個微服務協同工作，如果每一個微服務都分配一個域名的話，一方面客戶端代碼會很難維護，涉及到數百個域名，另一方面是連接數的瓶頸，想象一下你打開一個APP，通過抓包發(fā)現涉及到了數百個遠程調用，這在移動端下會顯得非常低效。每上線一個新的服務，都需要運維參與，申請域名、配置Nginx等，當上線、下線服務器時，同樣也需要運維參與，另外采用域名這種方式，對于環(huán)境的隔離也不太友好，調用者需要自己根據域名自己進行判斷。另外還有一個問題，后端每個微服務可能是由不同語言編寫的、采用了不同的協議，比如HTTP、Dubbo、GRPC等，但是你不可能要求客戶端去適配這么多種協議，這是一項非常有挑戰(zhàn)的工作，項目會變的非常復雜且很難維護。后期如果需要對微服務進行重構的話，也會變的非常麻煩，需要客戶端配合你一起進行改造，比如商品服務，隨著業(yè)務變的越來越復雜，后期需要進行拆分成多個微服務，這個時候對外提供的服務也需要拆分成多個，同時需要客戶端配合你進行改造，非常蛋疼。API Gateway
更好的方式是采用API網關，實現一個API網關接管所有的入口流量，類似Nginx的作用，將所有用戶的請求轉發(fā)給后端的服務器，但網關做的不僅僅只是簡單的轉發(fā)，也會針對流量做一些擴展，比如鑒權、限流、權限、熔斷、協議轉換、錯誤碼統(tǒng)一、緩存、日志、監(jiān)控、告警等，這樣將通用的邏輯抽出來，由網關統(tǒng)一去做，業(yè)務方也能夠更專注于業(yè)務邏輯，提升迭代的效率。
通過引入API網關，客戶端只需要與API網關交互，而不用與各個業(yè)務方的接口分別通訊，但多引入一個組件就多引入了一個潛在的故障點，因此要實現一個高性能、穩(wěn)定的網關，也會涉及到很多點。
API注冊
業(yè)務方如何接入網關?一般來說有幾種方式。
第一種采用插件掃描業(yè)務方的API，比如Spring MVC的注解，并結合Swagger的注解，從而實現參數校驗、文檔&&SDK生成等功能，掃描完成之后，需要上報到網關的存儲服務。手動錄入。比如接口的路徑、請求參數、響應參數、調用方式等信息，但這種方式相對來說會麻煩一些，如果參數過多的話，前期錄入會很費時費力。協議轉換
內部的API可能是由很多種不同的協議實現的，比如HTTP、Dubbo、GRPC等，但對于用戶來說其中很多都不是很友好，或者根本沒法對外暴露，比如Dubbo服務，因此需要在網關層做一次協議轉換，將用戶的HTTP協議請求，在網關層轉換成底層對應的協議，比如HTTP -> Dubbo, 但這里需要注意很多問題，比如參數類型，如果類型搞錯了，導致轉換出問題，而日志又不夠詳細的話，問題會很難定位。
服務發(fā)現
網關作為流量的入口，負責請求的轉發(fā)，但首先需要知道轉發(fā)給誰，如何尋址，這里有幾種方式:
寫死在代碼/配置文件里，這種方式雖然比較挫，但也能使用，比如線上仍然使用的是物理機，IP變動不會很頻繁，但擴縮容、包括應用上下線都會很麻煩，網關自身甚至需要實現一套健康監(jiān)測機制。域名。采用域名也是一種不錯的方案，對于所有的語言都適用，但對于內部的服務，走域名會很低效，另外環(huán)境隔離也不太友好，比如預發(fā)、線上通常是同一個數據庫，因此網關讀取到的可能是同一個域名，這時候預發(fā)的網關調用的就是線上的服務。注冊中心。采用注冊中心就不會有上述的這些問題，即使是在容器環(huán)境下，節(jié)點的IP變更比較頻繁，但節(jié)點列表的實時維護會由注冊中心搞定，對網關是透明的，另外應用的正常上下線、包括異常宕機等情況，也會由注冊中心的健康檢查機制檢測到，并實時反饋給網關。并且采用注冊中心性能也沒有額外的性能損耗，采用域名的方式，額外需要走一次DNS解析、Nginx轉發(fā)等，中間多了很多跳，性能會有很大的下降，但采用注冊中心，網關是和業(yè)務方直接點對點的通訊，不會有額外的損耗。服務調用
網關由于對接很多種不同的協議，因此可能需要實現很多種調用方式，比如HTTP、Dubbo等，基于性能原因，最好都采用異步的方式，而Http、Dubbo都是支持異步的，比如apache就提供了基于NIO實現的異步HTTP客戶端。
因為網關會涉及到很多異步調用，比如攔截器、HTTP客戶端、dubbo、redis等，因此需要考慮下異步調用的方式，如果基于回調或者future的話，代碼嵌套會很深，可讀性很差，可以參考zuul和spring cloud gateway的方案，基于響應式進行改造。
優(yōu)雅下線
優(yōu)雅下線也是網關需要關注的一個問題，網關底層會涉及到很多種協議，比如HTTP、Dubbo，而HTTP又可以繼續(xù)細分，比如域名、注冊中心等，有些自身就支持優(yōu)雅下線，比如Nginx自身是支持健康監(jiān)測機制的，如果檢測到某一個節(jié)點已經掛掉了，就會把這個節(jié)點摘掉，對于應用正常下線，需要結合發(fā)布系統(tǒng)，首先進行邏輯下線，然后對后續(xù)Nginx的健康監(jiān)測請求直接返回失敗(比如直接返回500),然后等待一段時間(根據Nginx配置決定)，然后再將應用實際下線掉。另外對于注冊中心的其實也類似，一般注冊中心是只支持手動下線的，可以在邏輯下線階段調用注冊中心的接口將節(jié)點下線掉，而有些不支持主動下線的，需要結合緩存的配置，讓應用延遲下線。另外對于其他比如Dubbo等原理也是類似。
性能
網關作為所有流量的入口，性能是重中之重，早期大部分網關都是基于同步阻塞模型構建的，比如Zuul 1.x。但這種同步的模型我們都知道，每個請求/連接都會占用一個線程，而線程在JVM中是一個很重的資源，比如Tomcat默認就是200個線程，如果網關隔離沒有做好的話，當發(fā)生網絡延遲、FullGC、第三方服務慢等情況造成上游服務延遲時，線程池很容易會被打滿，造成新的請求被拒絕，但這個時候其實線程都阻塞在IO上，系統(tǒng)的資源被沒有得到充分的利用。另外一點，容易受網絡、磁盤IO等延遲影響。需要謹慎設置超時時間，如果設置不當，且服務隔離做的不是很完善的話，網關很容易被一個慢接口拖垮。
而異步化的方式則完全不同，通常情況下一個CPU核啟動一個線程即可處理所有的請求、響應。一個請求的生命周期不再固定于一個線程，而是會分成不同的階段交由不同的線程池處理，系統(tǒng)的資源能夠得到更充分的利用。而且因為線程不再被某一個連接獨占，一個連接所占用的系統(tǒng)資源也會低得多，只是一個文件描述符加上幾個監(jiān)聽器等，而在阻塞模型中，每條連接都會獨占一個線程，而線程是一個非常重的資源。對于上游服務的延遲情況，也能夠得到很大的緩解，因為在阻塞模型中，慢請求會獨占一個線程資源，而異步化之后，因為單條連接所占用的資源變的非常低，系統(tǒng)可以同時處理大量的請求。
如果是JVM平臺，Zuul 2、Spring Cloud gateway等都是不錯的異步網關選型，另外也可以基于Netty、Spring Boot2.x的webflux、vert.x或者servlet3.1的異步支持進行自研。
緩存
對于一些冪等的get請求，可以在網關層面根據業(yè)務方指定的緩存頭做一層緩存，存儲到Redis等二級緩存中，這樣一些重復的請求，可以在網關層直接處理，而不用打到業(yè)務線，降低業(yè)務方的壓力，另外如果業(yè)務方節(jié)點掛掉，網關也能夠返回自身的緩存。
限流
限流對于每個業(yè)務組件來說，可以說都是一個必須的組件，如果限流做不好的話，當請求量突增時，很容易導致業(yè)務方的服務掛掉，比如雙11、雙12等大促時，接口的請求量是平時的數倍，如果沒有評估好容量，又沒有做限流的話，很容易服務整個不可用，因此需要根據業(yè)務方接口的處理能力，做好限流策略，相信大家都見過淘寶、百度搶紅包時的降級頁面。
因此一定要在接入層做好限流策略，對于非核心接口可以直接將降級掉，保障核心服務的可用性，對于核心接口，需要根據壓測時得到的接口容量，制定對應的限流策略。限流又分為幾種:
單機。單機性能比較高，不涉及遠程調用，只是本地計數，對接口RT影響最小。但需要考慮下限流數的設置，比如是針對單臺網關、還是整個網關集群，如果是整個集群的話，需要考慮到網關縮容、擴容時修改對應的限流數。分布式。分布式的就需要一個存儲節(jié)點維護當前接口的調用數，比如redis、sentinel等，這種方式由于涉及到遠程調用，會有些性能損耗，另外也需要考慮到存儲掛掉的問題，比如redis如果掛掉，網關需要考慮降級方案，是降級到本地限流，還是直接將限流功能本身降級掉。另外還有不同的策略:簡單計數、令牌桶等，大部分場景下其實簡單計數已經夠用了，但如果需要支持突發(fā)流量等場景時，可以采用令牌桶等方案。還需要考慮根據什么限流，比如是IP、接口、用戶維度、還是請求參數中的某些值，這里可以采用表達式，相對比較靈活。
穩(wěn)定性
穩(wěn)定性是網關非常重要的一環(huán)，監(jiān)控、告警需要做的很完善才可以，比如接口調用量、響應時間、異常、錯誤碼、成功率等相關的監(jiān)控告警，還有線程池相關的一些，比如活躍線程數、隊列積壓等，還有些系統(tǒng)層面的，比如CPU、內存、FullGC這些基本的。
網關是所有服務的入口，對于網關的穩(wěn)定性的要求相對于其他服務會更高，最好能夠一直穩(wěn)定的運行，盡量少重啟，但當新增功能、或者加日志排查問題時，不可避免的需要重新發(fā)布，因此可以參考zuul的方式，將所有的核心功能都基于不同的攔截器實現，攔截器的代碼采用Groovy編寫，存儲到數據庫中，支持動態(tài)加載、編譯、運行，這樣在出了問題的時候能夠第一時間定位并解決，并且如果網關需要開發(fā)新功能，只需要增加新的攔截器，并動態(tài)添加到網關即可，不需要重新發(fā)布。
熔斷降級
熔斷機制也是非常重要的一項。若某一個服務掛掉、接口響應嚴重超時等發(fā)生，則可能整個網關都被一個接口拖垮，因此需要增加熔斷降級，當發(fā)生特定異常的時候，對接口降級由網關直接返回，可以基于Hystrix或者Resilience4j實現。
日志
由于所有的請求都是由網關處理的，因此日志也需要相對比較完善，比如接口的耗時、請求方式、請求IP、請求參數、響應參數(注意脫敏)等，另外由于可能涉及到很多微服務，因此需要提供一個統(tǒng)一的traceId方便關聯所有的日志，可以將這個traceId置于響應頭中，方便排查問題。
隔離
比如線程池、http連接池、redis等應用層面的隔離，另外也可以根據業(yè)務場景，將核心業(yè)務部署帶單獨的網關集群，與其他非核心業(yè)務隔離開。
網關管控平臺
這塊也是非常重要的一環(huán)，需要考慮好整個流程的用戶體驗，比如接入到網關的這個流程，能不能盡量簡化、智能，比如如果是dubbo接口，我們可以通過到git倉庫中獲取源碼、解析對應的類、方法，從而實現自動填充，盡量幫用戶減少操作；另外接口一般是從測試->預發(fā)->線上，如果每次都要填寫一遍表單會非常麻煩，我們能不能自動把這個事情做掉，另外如果網關部署到了多個可用區(qū)、甚至不同的國家，那這個時候，我們還需要接口數據同步功能，不然用戶需要到每個后臺都操作一遍，非常麻煩。
這塊個人的建議是直接參考阿里云、aws等提供的網關服務即可，功能非常全面。
其他
其他還有些需要考慮到的點，比如接口mock，文檔生成、sdk代碼生成、錯誤碼統(tǒng)一、服務治理相關的等，這里就不累述了。
總結
目前的網關還是中心化的架構，所有的請求都需要走一次網關，因此當大促或者流量突增時，網關可能會成為性能的瓶頸，而且當網關接入的大量接口的時候，做好流量評估也不是一項容易的工作，每次大促前都需要跟業(yè)務方一起針對接口做壓測，評估出大致的容量，并對網關進行擴容，而且網關是所有流量的入口，所有的請求都是由網關處理，要想準確的評估出容量很復雜。可以參考目前比較流行的ServiceMesh，采用去中心化的方案，將網關的邏輯下沉到sidecar中，sidecar和應用部署到同一個節(jié)點，并接管應用流入、流出的流量，這樣大促時，只需要對相關的業(yè)務壓測，并針對性擴容即可，另外升級也會更平滑，中心化的網關，即使灰度發(fā)布，但是理論上所有業(yè)務方的流量都會流入到新版本的網關，如果出了問題，會影響到所有的業(yè)務，但這種去中心化的方式，可以先針對非核心業(yè)務升級，觀察一段時間沒問題后，再全量推上線。另外ServiceMesh的方案，對于多語言支持也更友好。
面試官：說說什么是 API 網關？它有什么作用？
## 引言
在現代軟件開發(fā)中，特別是在微服務架構和分布式系統(tǒng)環(huán)境下，API網關（API Gateway）扮演著至關重要的角色。它不僅是系統(tǒng)內外通信的橋梁，還承擔著管理、路由、保護和優(yōu)化API訪問的重任。本文將深入探討API網關的定義、作用及其在現代軟件架構中的重要性。
## 什么是API網關？
API網關是一個核心的服務架構組件，位于客戶端和服務器端之間，作為系統(tǒng)的唯一入口點。它負責接收來自客戶端的請求，將這些請求路由到相應的后端服務，然后將服務的響應返回給客戶端。API網關不僅是一個簡單的請求轉發(fā)器，還集成了多種高級功能，如認證、授權、流量控制、負載均衡、緩存、協議轉換和數據轉換等。
從技術角度看，API網關可以看作是一個服務器，它封裝了系統(tǒng)內部架構的細節(jié)，為客戶端提供了一個統(tǒng)一的接口。通過API網關，客戶端無需直接訪問后端服務，從而實現了客戶端與后端服務的解耦，提高了系統(tǒng)的靈活性和可維護性。
## API網關的作用
### 1. 安全防護
API網關負責保護后端服務免受惡意攻擊和未經授權的訪問。它可以通過實施認證、授權、數據加密等安全策略，確保只有授權的用戶或應用程序才能訪問服務。例如，API網關可以驗證用戶的憑據（如用戶名和密碼），或者使用令牌（如OAuth2.0）進行身份驗證和授權。此外，API網關還可以防止常見的網絡攻擊，如SQL注入、跨站腳本（XSS）和跨站請求偽造（CSRF）等。
### 2. 請求路由與轉發(fā)
API網關根據請求的路徑、方法、頭部等條件進行路由決策，將請求轉發(fā)到正確的后端服務。這種路由機制允許系統(tǒng)靈活地調整服務部署，而無需修改客戶端代碼。例如，在微服務架構中，API網關可以將用戶的請求動態(tài)路由到不同的微服務實例上，實現服務的負載均衡和高可用性。
### 3. 協議轉換與數據轉換
API網關通常需要處理不同的通信協議和數據格式。它可以將來自客戶端的請求轉換成后端服務所需的格式，反之亦然。這種轉換功能使得不同系統(tǒng)之間能夠實現互操作性，降低了集成難度和成本。例如，API網關可以將HTTP請求轉換為SOAP請求，或者將JSON格式的數據轉換為XML格式的數據。
### 4. 負載均衡與緩存
API網關可以分發(fā)請求到多個后端服務實例上，實現負載均衡，提高系統(tǒng)的性能和可擴展性。同時，API網關還可以對請求進行緩存，減少對后端服務的訪問次數，進一步減輕后端服務的負載。緩存機制特別適用于讀取頻繁且數據變化不大的場景，如用戶信息、配置信息等。
### 5. 監(jiān)控與分析
API網關能夠記錄和監(jiān)控所有傳入和傳出的請求，提供關于服務性能和使用情況的詳細指標。這些監(jiān)控數據對于系統(tǒng)的性能優(yōu)化和故障排查非常重要。通過分析監(jiān)控數據，開發(fā)人員可以及時發(fā)現并解決潛在的性能瓶頸和安全問題。
### 6. 服務治理
API網關內置了多種服務治理策略，如服務的熔斷、降級、流量控制等。這些策略有助于確保系統(tǒng)的穩(wěn)定性和可靠性。例如，當后端服務出現故障時，API網關可以啟動熔斷機制，暫時斷開與服務之間的連接，避免請求堆積和系統(tǒng)崩潰。
## 結論
API關是現代軟件架構中不可或缺的一部分，它通過集中管理和保護對后端服務的訪問，提高了系統(tǒng)的安全性、可靠性和性能。理解API網關的定義和作用，對于開發(fā)人員和架構師來說至關重要。在未來的軟件開發(fā)中，隨著微服務架構和分布式系統(tǒng)的廣泛應用，API網關的作用將變得更加重要。
相關問答
微服務網關和 api網關 區(qū)別?答:api網關和微服務網關的區(qū)別如下。1.部署位置不同微服務網關主要是部署在內網,作為微服務內部API的通訊。企業(yè)級應用網關一般部署在DMZ區(qū)域或者在藏在負...
api網關 有哪些?API網關是微服務架構(MicroservicesArchitecture)標準化服務的模式。API網關定位為應用系統(tǒng)服務接口的網關,區(qū)別于網絡技術的網關,但是原理則是一樣。API網...
網關api 是啥?API網關是微服務架構(MicroservicesArchitecture)標準化服務的模式。API網關定位為應用系統(tǒng)服務接口的網關,區(qū)別于網絡技術的網關,但是原理則是一樣。API網...
api網關 和微服務網關的區(qū)別?答:api網關和微服務網關的區(qū)別如下。1.部署位置不同微服務網關主要是部署在內網,作為微服務內部API的通訊。企業(yè)級應用網關一般部署在DMZ區(qū)域或者在藏在負...
為什么微服務需要 API網關 ?1.防止內部關注暴露給外部客戶端API網關將外部公共API與內部微服務API分開,允許添加微服務和更改邊界。其結果是能夠在不對外部綁定客戶端產生負面影響的情況...
HTTP API 接口的智能硬件數據交換格式 - OSCHINA - 中文開源...客戶要求帶有HTTPAPI接口的智能網關因為不是專業(yè)人員,不太懂其到底是什么意思,和普通的TCP/IP協議有什么區(qū)別,在網上找到一款智能網關其網關與服務器連接方式...
