轉載本文需註明出處：微信公衆號EAWorld，違者必究。
本文目錄：
一、網關簡介
二、網關的作用和價值
三、企業級API網關需要具備的條件
四、業界常用的API網關方案
五、如何設計一個好的企業級API網關產品
六、小結
一、網關簡介
1.1 API網關背景介紹
API Gateway（APIGW / API 網關），顧名思義，是出現在系統邊界上的一個面向API的、串行集中式的強管控服務，這裏的邊界是企業IT系統的邊界，主要起到隔離外部訪問與內部系統的作用。在微服務概念的流行之前，API網關的實體就已經誕生了，例如銀行、證券等領域常見的前置機系統，它也是解決訪問認證、報文轉換、訪問統計等問題的。
API網關的流行，源於近幾年來，移動應用與企業間互聯需求的興起。移動應用、企業互聯，使得後臺服務支持的對象，從以前單一的Web應用，擴展到多種使用場景，且每種使用場景對後臺服務的要求都不盡相同。這不僅增加了後臺服務的響應量，還增加了後臺服務的複雜性。隨着微服務架構概念的提出，API網關成爲了微服務架構的一個標配組件。
1.2 網關的幾種使用場景
我司王延炯博士的文章《談API網關的背景、架構以及落地方案》中，提到了網關的幾種使用場景：
1、面向Web App的網關
這類場景，在物理形態上類似前後端分離，此時的Web App已經不是全功能的Web App，而是根據場景定製、場景化的App。
2、面向MobileApp的網關
這類場景，移動App是後端Service的使用者，此時的APIGW還需要承擔一部分MDM（此處是指移動設備管理，不是主數據管理）的職能。
3、面向PartnerOpenAPI的網關
這類場景，主要爲了滿足業務形態對外開放，與企業外部合作伙伴建立生態圈，此時的API GW需要增加配額、流控、令牌等一系列安全管控功能。
4、面向PartnerExternalAPI的網關
這類場景，主要是爲了滿足企業自身業務的需要，實現對企業自有業務的映射。一個典型的例子就是使用「合作方賬號登錄」、「使用第三方支付平臺支付」等等。此時的APIGW就需要在邊界上，爲企業內部Service 統一調用外部的API做統一的認證、授權、以及訪問控制。
5、面向IoTSmartDevice的網關
這類場景主要在傳統企業，尤其是工業企業，傳感器、物理設備從工業控制協議向IP轉換，導致物理鏈路上會存在一部分公網鏈路。此時的API GW所需要滿足的「內外兼修」的雙向數據流，設備一般通過一個「客戶側」的集中網關在和企業的接入網關進行通信。
在我們講的微服務架構下的API網關，一般指的是前兩種使用場景。即，主要是把企業內部的API能力，暴露給其他應用或合作伙伴使用。
二、網關的作用和價值
網關層作爲客戶端與服務端的一層擋板，主要起到了三大類作用：
第一類作用是隔離作用，作爲企業系統邊界，隔離外網系統與內網系統。
第二類作用是解耦作用，通過解耦，使得微服務系統的各方能夠獨立、自由、高效、靈活地調整，而不用擔心給其他方面帶來影響。
第三類作用是腳手架作用，提供了一個地點，方便通過擴展機制對請求進行一系列加工和處理。
2.1 內外的隔離
企業爲了保護內部系統的安全性，內網與外網都是隔離的，企業的服務應用都是運行在內網環境中，爲了安全的考量，一般都不允許外部直接訪問。API網關部署在防火牆外面，起到一層擋板作用，內部系統只接受API網關轉發過來的請求。網關通過白名單或校驗規則，對訪問進行了初步的過濾。相比防火牆，這種軟件實現的過濾規則，更加動態靈活。
2.2 多方的解耦
在微服務架構下，整個環境包括服務的提供者、服務的消費者、服務運維人員、安全管理人員等，每個角色的職責和述求都不同。例如：服務消費者已經需要提出一些新的服務需求，以快速應對業務變化；服務提供者，作爲業務服務的沉澱方，希望保持服務的通用性與穩定性，很難應對快速的變化。有了API網關這一層，可以很好的解耦各方的相互依賴關係，讓各方更加專注自己的目標。
1、解耦功能與非功能
企業在把服務提供給外部訪問時，除了實現業務邏輯功能外，還面臨許多非功能性的要求。例如：需要防範黑客攻擊，需要應對突發的訪問量、需要確認用戶的權限，需要對訪問進行監控等。這些非功能邏輯，不能與業務邏輯的開發混在一起，需要有專業的人員甚至專業的團隊來處理。
2、解耦客戶端與服務提供者
客戶端與服務提供者分屬於不同的團隊，工作性質要求也不相同。對於服務提供者來說，他主要的職責是對業務進行抽象，提供可複用的業務功能，他們需要對業務模型進行深入的思考和沉澱，不能輕易爲了響應外部的需求而破壞業務模型的穩定性。而業務的快速變化，又要求企業快速提供接口來滿足客戶端需求。這就需要一箇中間層，來對服務層的接口進行封裝，以及時響應客戶端的需求。
通過解耦，服務層可以使用統一的接口、協議和報文格式來暴露服務，而不必考慮客戶端的多種形態。
3、網關層是否需要實現服務的編排？
在介紹API網關的一些文章中，提到了網關層的服務編排能力。從解耦的角度出發，服務的編排不適合在網關層進行。對服務的編排，其實是提供了一種業務能力，如果把服務的編排放在了網關層，實際上是把一部分業務能力放在了網關層，這樣一來，服務層、網關層都有一些業務能力，造成團隊職責的不清，也不利於業務能力的沉澱。
2.3 插件的腳手架
網關層除了請求的路由、轉發外，還需要負責安全、鑑權、限流、監控等。這些功能的實現方式，往往隨着業務的變化不斷調整。例如權限控制方面，早期可能只需要簡單的用戶+密碼方式，後續用戶量大了後，可能會使用高性能的第三方解決方案。又例如，針對不同的監控方案，需要記錄不同的日誌文件。
所以，這些能力不能一開始就固化在網關平臺上，而應該是一種可配置的方式，便於修改和替換。這就要求網關層提供一套機制，可以很好地支持這種動態擴展。
2.4 帶來的好處
這裏總結下網關的價值：
-
網關層對外部和內部進行了隔離，保障了後臺服務的安全性。
-
對外訪問控制由網絡層面轉換成了運維層面，減少變更的流程和錯誤成本
-
減少客戶端與服務的耦合，服務可以獨立發展。通過網關層來做映射。
-
通過網關層聚合，減少外部訪問的頻次，提升訪問效率。
-
節約後端服務開發成本，減少上線風險。
-
爲服務熔斷，灰度發佈，線上測試提供簡單方案。
-
便於擴展。
三、企業級API網關需要具備的條件
3.1 微服務架構下，企業API網關的定位
API網關作爲對外提供服務的入口，就像企業服務的大門。一方面，要有足夠的能力，應對大量的對外訪問，另一方面，還要給對內的服務提供一定的安全保障。
除此之外，企業提供的API服務多種多樣，API網關要能夠對這些API的全生命週期進行便捷的管理，例如服務發佈、調整、下架、計費、監控等。
3.2 企業環境下，API網關需要考慮哪些要素
1、安全性問題
企業在把服務暴露給外部使用時，首先要確保服務使用的安全，防止外部的惡意訪問對公司業務的影響，特別是涉及交易方面的服務，更是要全面考慮安全性。爲確保安全，需要考慮在通訊鏈路的建立、通訊數據的加密、數據的完整性、不可抵賴性等方面。
2、性能問題
作爲企業API的入口，所有的請求都會經過API網關進行轉發，可想而知，對API網關的訪問壓力是巨大的，有的網站甚至達到每分鐘上千萬的訪問量。特別是在一些互聯網企業，海量的移動終端每時每刻都需要與後端的服務進行交互，如果不能保證網關的高性能，企業在網關層需要投入大量的設備和成本。曾在一家互聯網公司發生過，由於網關性能問題，網關的機器數量，需要與後臺服務器的數量保持同步增長。這種情況顯然是企業服務忍受的。
3、高可用問題
API網關作爲邏輯上的單點，一旦發生問題，將造成企業服務的不可用，對企業來說可能造成的致命的影響。計算短時間的不可用，也會給企業帶來直接的經濟損失。所以，如何保證API網關的7*24小時的穩定運行，網關的自動伸縮、API的熱更新等問題，都是企業級的網關需要考慮的。
4、擴展性問題
前面說到，企業網關提供了一個腳手架，一些非功能性的問題，例如日誌、安全、負載均衡策略、鑑權等。這些插件會隨着企業業務規模等的變化進行不斷的強化與調整。這就需要網關層提供這樣一種機制，使得可以靈活地進行這些調整和變化，而不用頻繁對網關層進行改動，確保網關層的穩定性。
5、API高效運維的問題
API在上線、發佈過程中，都需要涉及到網關層的配合，例如，需要網關層知道API發佈的地址，API的接口形式、報文格式，也需要網關層對後臺API進行封裝。在API調整後，需要作出相應的修改。所以，API網關設計時，需要明確網關層與服務層的職責切分與協作模式，使得API的管理、發佈更加高效。
6、API全生命週期管理的問題
API服務的全生命週期，包括服務的開發、測試、上線發佈；服務使用的申請、開通；服務分類分級別的管理、服務使用情況的監控、計費等等。
一個企業可能會暴露成百上千個API，日常也會經常進行API的發佈、升級、改造、下架等操作。對不同的服務，不同的訪問者，需要提供不同的服務訪問策略。有的商業API公司，還需要對API的使用進行付費。所以，與API網關配套的，需要一套完善的自助系統，提供給服務的提供者、管理者、使用者，來對服務的發佈、使用、和運營。
四、業界常用的API網關方案
業界API網關解決方案有很多，包括商業的、開源的。例如Tyk、Kong、api-umbrella、apiaxle、Netflix zuul、WSO2 API Manager、clydeio等。下面介紹三種常見的 API 網關方案。
4.1 Nginx+ Lua
Nginx是由IgorSysoev爲俄羅斯訪問量第二的Rambler.ru站點開發的，一個高性能的HTTP和反向代理服務器。2012年，Nginx榮獲年度雲計算開發獎，併成長爲世界第二大Web服務器。全世界流量最高的前1000名網站中，超過25%都使用Nginx來處理海量的互聯網請求。
Nginx基本功能：
-
靜態web資源服務器，能夠緩存打開的文件描述符
-
支持http/imap/pop3/smtp的反向代理；支持緩存、負載均衡
-
支持fastcgi(fpm)
-
模塊化，非DSO機制，支持過濾器zip壓縮，SSI以及圖像大小調整
-
支持SSL
Nginx通過插件的擴展功能：
-
基於名稱和IP的虛擬主機
-
支持keepalive的保持機制
-
支持平滑升級
-
定製訪問日誌，支持使用日誌緩存區提高日誌存儲性能
-
支持url rewrite
-
支持路徑別名（root或alias指定）
-
支持基於IP以及用戶的訪問控制
-
支持傳輸速率限制，併發限制
Nginx在性能和高可用性上的表現：
Nginx性能極高，Nginx先天的事件驅動型設計、全異步的網絡I/O處理機制、極少的進程間切換以及許多優化設計，都使得Nginx天生善於處理高併發壓力下的互聯網請求。Nginx的穩定性也在各大網站得到驗證。官方提供的常用模塊都非常穩定，每個worker進程相對獨立，master進程在1個worker進程出錯時可以快速“拉起”新的worker子進程提供服務。支持熱部署，可以不停機更新配置文件、更新日誌文件、更新服務器程序版本。
Nginx的擴展性：
Nginx的設計極具擴展性，它完全是由多個不同功能、不同層次、不同類型且耦合度極低的模塊組成。因此，當對某一個模塊修復Bug或進行升級時，可以專注於模塊自身，無須在意其他。
Nginx的易用性：
Nginx使用最自由的BSD許可協議，允許用戶在自己的項目中直接使用或修改Nginx源碼，有大量的插件可以利用。但是，Nginx模塊需要用C開發，而且必須符合一系列複雜的規則。雖然通過第三方模塊，可以支持Nginx與Perl、Lua等腳本語言集成工作，但對使用者的要求還是很高。
Nginx可以說是一款能夠工業化API網關，在國內的很多互聯網公司，例如阿里、新浪等都得到很好的應用。
4.2 SpringCloud Zuul
Zuul Netflix公司開源的一個API網關組件。提供了認證&鑑權、限流、動態路由，監控，彈性，安全、負載均衡、協助單點壓測、靜態響應等邊緣服務的框架。
Zuul的基本功能：
-
驗證與安全保障: 識別面向各類資源的驗證要求並拒絕那些與要求不符的請求。
-
審查與監控: 在邊緣位置追蹤有意義數據及統計結果，從而爲我們帶來準確的生產狀態結論。
-
動態路由: 以動態方式根據需要將請求路由至不同後端集羣處。
-
壓力測試: 逐漸增加指向集羣的負載流量，從而計算性能水平。
-
負載分配: 爲每一種負載類型分配對應容量，並棄用超出限定值的請求。
-
靜態響應處理: 在邊緣位置直接建立部分響應，從而避免其流入內部集羣。
-
Netflix公司還利用Zuul的功能通過金絲雀版本實現精確路由與壓力測試。
-
雖然提供的功能還算豐富，但都比較弱，很難滿足高要求的場景。
Zuul在性能和高可用性上的表現：
Zuul處理每個請求的方式是針對每個請求是用一個線程來處理。通常情況下，爲了提高性能，所有請求會被放到處理隊列中，從線程池中選取空閒線程來處理該請求。2016年底，Netflix將它們的網關服務Zuul進行了升級，全新的Zuul 2將HTTP請求的處理方式從同步變成了異步，以提升其處理性能。除了Netflix公司，目前Zuul在企業中用的還比較少，性能和穩定性方面還有待進一步觀察。
Zuul的擴展性：
從Zuul的架構圖上可以看出，Zuul更像是一個過濾器框架，其自身的路由、日誌、反向代理、ddos預防等功能都是通過過濾器實現的。提供了PRE、ROUTING、POST和ERROR四個擴展點，可以很容易的添加自定義的過濾器。
Zuul的易用性：
Zuul的搭建非常簡便，使用和配置也很簡單。Zuul的開源社區比較活躍，一直在更新狀態，但版本不算太穩定，在使用的過程中，還有一些坑要踩。例如重定向問題、異常處理問題，還沒有解決的很好，需要自己重寫一些filter。
如果從通盤考慮， 這種方案不是最佳方案。但如果自己的團隊對整體技術設施把控有限，且團隊規模不大，沒有專門的網關開發人員的情況下，Zuul是一款快速上手的最佳方案。
4.3 MashapeKong
Kong是Mashape提供的一款API管理軟件，它本身是基於Ngnix+lua的，但比nginx提供了更簡單的配置方式，數據採用了 ApacheCassandra/PostgreSQL存儲，並且提供了一些優秀的插件，比如驗證，日誌，調用頻次限制等。
Kong的一個非常誘人的地方就是提供了大量的插件來擴展應用，通過設置不同的插件可以爲服務提供各種增強的功能。Kong默認插件插件包括：
-
身份認證：Kong提供了Basic Authentication、Key authentication、OAuth2.0authentication、HMAC authentication、JWT、LDAP authentication認證實現。
-
安全：ACL（訪問控制）、CORS（跨域資源共享）、動態SSL、IP限制、爬蟲檢測實現。
-
流量控制：請求限流（基於請求計數限流）、上游響應限流（根據upstream響應計數限流）、請求大小限制。限流支持本地、Redis和集羣限流模式。
-
分析監控：Galileo（記錄請求和響應數據，實現API分析）、Datadog（記錄API Metric如請求次數、請求大小、響應狀態和延遲，可視化API Metric）、Runscope（記錄請求和響應數據，實現API性能測試和監控）。
-
轉換：請求轉換、響應轉換
Kong本身也是基於Nginx的，所以在性能和穩定性上都沒有問題。Kong作爲一款商業軟件，在Nginx上做了很擴展工作，而且還有很多付費的商業插件。Kong本身也有付費的企業版，其中包括技術支持、使用培訓服務以及API 分析插件。
從對上面三種方案的比較中可以看到，Spring Cloud Zuul非常適合創業初期的團隊，快速搭建一個“基本可用”的API網關。Nginx適合有較強研發團隊，自主開發企業自己的API網關。Kong適合於沒有自身研發團隊，但需要擁有企業級API網關能力的公司。
五、如何設計一個
好的企業級API網關產品
5.1 功能上的考量
API 生命週期管理功能：
-
覆蓋 API 的定義、測試、發佈的整個生命週期管理，便捷的日常管理、版本管理，支持熱升級和快速回滾。
開發和使用支持功能：
-
提供頁面調試工具，自動生成 API 文檔和 SDK，大大降低人力成本。
安全防護功能：
-
API 請求到達網關需要經過嚴格的身份認證、權限認證，才能到達後端服務。支持算法簽名，支持 SSL 加密。
流量控制功能：
-
可控制單位時間內 API 允許被調用次數。用來保護企業的後端服務，實現業務分級和用戶分級。
-
支持對 API 流控，您可以根據 API 的重要程度來配置不同流控，從而保障重要業務的穩定運行；
-
支持用戶、應用和例外流控，您可以根據用戶的重要性來配置不同流控，從而可以保證大用戶的權益；
-
流控粒度：分鐘、小時、天。
請求管理功能：
-
可根據配置進行參數類型、參數值（範圍、枚舉、正則、Json Schema）的校驗，減少後端對非法請求、無效請求的資源消耗和處理成本。
-
可以在 API 網關定義參數映射規則，網關通過映射規則將後端服務通過映射翻譯成任何形式，以滿足不同用戶的不同需求，從而避免功能重複開發。
監控告警功能：
-
提供實時、可視化的 API 監控，包括：調用量、調用方式、響應時間、錯誤率，讓您能夠清楚的瞭解API 的運行狀況和用戶的行爲習慣。
-
支持自定義報警規則，來針對異常情況進行報警，降低故障處理時間。
-
提供可訂閱的數據分析報表和智能分析。
API交易功能：
-
提供API交易市場，計量計費、Quota 控制、運營售賣等需求。
5.2 網關的高性能設計
傳統的基於線程的併發模型（Thread-based concurrency），爲每一個請求分配一個線程或進程。這種模型編程簡單，可以將處理一個完整請求的代碼編寫在一個代碼路徑中。這種模型的弊端是，隨着線程(進程)數的上升，操作系統在這些線程(進程)之間的頻繁切換，將急劇降低系統的性能。
另一種更高效的併發模型是事件驅動的併發模型（Event-driven concurrency）。在這種模型中，每一個請求在系統被表示成一個有限狀態機（FSM）。每一個FSM的狀態表示請求的一系列的操作。服務器由一組線程/進程（一般是 one per CPU）循環處理各種來自隊列的事件(Event)。
這種模型要求每一個狀態的操作是短暫的並且是非阻塞的，所以 Event-driven concurrency模型一般都用了非阻塞的I/O接口（NIO）。
普元的產品中，爲增加系統的吞吐量，是採用了基於事件的併發模型的SEDA的架構。SEDA架構的核心思想是：把一個請求處理過程分成幾個Stage，每個Stage可由不同的handle進行處理，不同資源消耗的Stage使用不同數量的線程來處理，handle之間採用異步通訊的模式。
詳細的SEDA架構介紹可以參見普元同事的一篇文章《選擇SEDA作爲雲平臺的基礎消息處理架構》。
5.3 網關的高可用設計
保證高可用一般做法是解決單點故障給系統整體帶來的影響。普元在產品設計時，爲確保高可用，考慮瞭如下幾點要素：
1、無狀態設計原則：網關層爲保證高可以，易於伸縮，快速啓動，需要設計成無狀態的。用戶的狀態數據我們通常使用session對象來封裝，網關層要設計成無狀態的，也就是說，不能由網關來負責session的維護。那由誰來維護session相關的信息呢？我們是採用cookie+session服務器的方式；
-
用戶在登錄頁完成登錄操作後，服務器會生成一個登錄session信息，保存起來，設置個失效時間，並設置到用戶的cookie裏
-
用戶後續的每次請求裏會帶着這個cookie信息，服務端會對這個cookie信息進行校驗，通過了就認爲是合法用戶，執行請求操作
2、優雅下線原則：當網關發現某一個節點不可用時（例如請求響應時間超過閥值），不是直接斷開與此節點的連接，而是先把此節點標記爲不可用（後續不在發送請求到此節點），但還會留出一段時間讓之前的請求都響應完畢。
3、Slow start特性：當網關監聽到有一臺新的服務註冊上來時，考慮到有些服務啓動後，剛開始會有許多初始化的工作，此時服務對請求的響應速度是比較慢的。如果一開始就給這臺服務分配太多的壓力，有可能導致服務瞬間被壓垮。爲了避免這種情況，網關層需要考慮支持SlowStart特性。即，經過一段時間，逐漸把壓力增加到預設的值。
5.4 網關的擴展性設計
網關的擴展性設計時，需要考慮下面幾點：
-
在哪些地點進行攔截處理
-
攔截器的處理順序
-
如何在攔截器間傳遞數據
-
支持在線關閉或啓動一個攔截器
在哪些地點進行攔截處理
我們知道，網關對請求的處理，可以分爲三個階段：接受請求、路由並轉發請求、接受服務的返回數據並返回給請求者，除此之外，還有一種情況是處理錯誤。所以我們也可以在這四個地方添加擴展點。
-
接受到請求後
-
定位到一個服務，並準備轉發之前
-
接受到服務的返回數據，返回給客戶端之前
-
當服務調用失敗後
攔截器的處理順序
攔截器的處理順序，可以分爲兩大類：一類爲網關平臺自帶的攔截器，例如安全校驗、日誌記錄等；一類爲網關層邏輯開發的，例如格式轉換等。一般來說，網關先執行網關平臺自帶的攔截器，再執行爲了業務邏輯編寫的攔截器。當然，網關也需要提供一種機制，可以較容易地調整攔截器的執行順序。最簡單的一種方法，就是給每個攔截器定義一個優先級，網關按優先級順序依次調用各攔截器。
如何在攔截器間傳遞數據
對網關層來說，它接收和處理的數據都是Request對象，網關層在接收到請求後，把請求封裝爲Request對象，爲了讓後續的filter能夠獲得這個對象，可以考慮把Request對象保存在線程變量中。
支持在線關閉或啓用一個攔截器
有些攔截器，例如一些調試日誌的攔截器，通常情況下都是關閉的，只有在出現問題的時候才需要打開。爲了保證網關的高可用，網關層必須具備在線啓用或關閉攔截器的能力。一般，網關需要提供restful接口方式，來關閉和啓用一個攔截器。類似這樣的命令：PUT/apigateway/v1/filters/filterName?enable=value
5.5 API管理與動態發佈設計
對服務管理來說，分爲前端服務管理與後端服務管理。前端服務指的是網關層暴露給客戶端使用的服務API，後端服務指的是服務層提供的業務服務API。一個服務暴露給客戶端使用，除了網關層和服務層提供服務的代碼外，還需要配置前端服務與後端服務的映射關係。
API的描述
要對API進行管理，首先要對API進行描述。我們常見的接口描述語言有yaml、json、xml、PB等，這幾種語言各有優劣。普元選擇的對API契約的描述方式，是參考swagger spec規範，使用yaml語言來描述。當然，swagger的描述是針對restful接口的，我們可以針對自己接口定義的需要，自定義自己的描述屬性。例如，普元在對微服務描述的時候，擴展了x-primeton-service、x-primeton-operation等屬性來對服務進行描述。例如：
有了API接口契約，除了用來描述服務接口外，還可以：
-
使用契約，自動生成服務的API文檔。
-
使用契約，自動生成客戶端的調用代碼。
-
使用契約，生成服務接口的測試框架代碼。
前後端服務映射
網關層API調用服務層API，有多種方式。例如，可以由按照服務層API的服務契約，生成一段客戶端代碼，發佈給網關層使用。這種方式的弊端是，網關層代碼依賴於服務層代碼，服務層頻繁修改和調整接口時，導致網關層的代碼很難維護。
可以通過配置前後端服務映射的方式，解耦網關層對服務層的依賴。當服務層的API（例如服務名、參數名等）發生變化時，只需調整映射關係，無需對網關層的代碼進行調整。網關層按照映射，自動裝配服務層API所需要的數據格式。這樣，網關層團隊與服務層團隊可以相互不受干擾地開發各自的服務。
映射的設置，包括服務URL的映射與參數的映射。有了前面提供的服務契約描述，可以可視化的配置這種映射關係。
API上架
前後端的服務發佈後，並配置了映射關係後，就可以把服務暴露給外部使用了。在上架過程中，還需要設置訪問權限、流量控制等信息。這一塊，每個企業的業務要求都不一樣，就不做過多介紹了。
六、總結
API網關作爲企業能力開放的一個門戶，除了具備基本的請求轉發、協議轉換、路由等功能，以及高性能和高穩定性外，還需具備良好的擴展性，已便於網關能力的不斷增強。在網關實施過程中，要規劃好網關層與服務層的交互方式，儘量使得網關層與服務層解耦，便於各個團隊工作的獨立性。另外，在API的管理上，需要提供API全生命週期的發佈、配置、鑑權、流控、監控等配套的管理功能。這樣，才能讓API網關真正在企業中運轉起來。