如何快速實現REST API集成以優化業務流程
回顧完歷史再面向未來，新一代網關的技術趨勢是什么呢？我們認為有以下三點。第一是以開發者為中心，像 K8s CRD 一樣，通過標準化、聲明式的配置來管理 API 和路由規則，并將它們和應用代碼的變更管理統一到一個 CI/CD 流程中，并提供多版本的灰度能力，提高整個業務迭代的效率。第二點是要順應當今 AI 時代的需求。一方面網關要作為 AI 應用穩定、高性能、高彈性的流量入口，另一方面要激活更多傳統應用的 API，讓他們可以便捷地被 AI 應用作為插件調用，實現 API 經濟。第三，當 AI 自動化席卷一切之后，安全問題會更加突出。網關在入口層面除了要做流量清洗以及認證鑒權之外，也需要針對 API 接口的漏洞、非法篡改、高頻訪問、暴力破解，進行更加有效地管理和防護。
Cloud Native對于企業來說，一套定義和管理規范的 API 能帶來哪些價值呢？
首先是提高效率，在應用開發初期，當 API 定義好之后，就可以進行前后端分離并行開發，來縮短迭代周期。另外，應用和系統之間可以通過 API 接口進行解耦，只要 API 的約定不變，各系統就可以進行獨立的升級和改造。
第二，企業內外部的能力通過 API 進行暴露，就可以實現快速集成，不需要再重復造輪子，降低組織的總體成本。
第三，各個組織之間通過 API 進行功能和數據互訪并做有效管控下，可以激發更多的業務創新。特別是在當下，大模型相當于我們人的大腦，讓應用有了認知和推理能力。而 API 就像我們的手腳，讓應用可以操作周邊的系統，使 AI 應用有了無限的想象空間。通過組合跨界應用產生化學反應，讓 AI 能夠被越來越多的場景使用。
最后，API 可以讓企業構建更廣泛的生態。很多大公司把 API 看作是核心資產，像 Twitter 和 SaaS 服務巨頭 Salesforce 都是通過 API 開放獲得了巨大的流量。而當下炙手可熱的 OpenAI，據分析他們的 API 服務年度經常收入達到了 5 億美元，有三百多萬開發者圍繞他們的 API 創建 AI 應用，這些都是 API 經濟的經典案例。
然而，我們也看到，很多企業和組織并沒有對 API 這一核心資產進行很好的管理，在放養式的開發模式下，如果API設計隨意而且沒有管理工具，會導致版本混亂，上下游對接摩擦不斷。我們有一個客戶的技術總監反饋，公司可能有上萬個API接口，但哪些在線上，哪些是測試，哪些廢棄不用根本說不清楚，管理成本太高。對技術人員來說，各參與方使用不同的API設計、測試工具，數據互通難，API定義容易不一致，會極大影響協同效率。
而對于運維同學來說，后端應用架構和業務需求是多樣的，就需要部署和維護多種網關組件，監控告警、問題診斷都是很大的工作負擔，也很難實現全鏈路的灰度發布。
最后是線上業務看重的性能和穩定性，多層網關會導致訪問鏈路過長，響應時間變慢，在大流量下，開源自建網關的穩定性和性能堪憂，配置或發布變更會造成業務抖動，最終影響業務發展。根據 CSDN 2023 年中國開發者調查報告，有 40% 多的開發者認為規范 API 接口是排在待改善問題的首位。而 Gartner 2023 年 API 管理中國市場分析報告也指出，隨著云原生化的深入，API 數量增加，標準化程度也需要增高。到了 2027 年，大概會有 50% 以上的企業會使用 API 管理工具。
Cloud Native為了解決這些問題，阿里云也演進出了不同的網關產品，2016 推出了 API 網關，它覆蓋了 API 從設計、測試、發布、運維、下線全生命周期的管理，也幫助用戶快速建設以 API 為核心，將后端服務或數據對外開放并進行鑒權流控，特別是和 FC、Dataworks 進行了深度集成。為了適應云原生時代下微服務架構和容器部署要求，
2021 年我們推出了 MSE 網關，它以路由為核心，兼容 K8s Ingress 標準，支持多種服務發現方式，提供豐富的認證鑒權、服務治理和插件能力。
今天，我們進一步將兩個產品融合為云原生 API 網關，它 MSE 網關的能力之上，疊加了 API 全生命周期管理功能，幫助用戶以統一規范進行 API 設計，并支持多版本迭代、多環境發布。近期我們也會提供 API 開放平臺，助力用戶進行 API 資產的創建、訂閱審批、鑒權及配額管理。另外，網關引擎使用的是阿里云基于 Envoy 開發的 Higress 開源項目，多云或混合云用戶在阿里云上用商業化網關，在其他環境可以使用 Higress 自建，我們也在規劃 API 的統一管理和發布能力，便于用戶保持技術棧和 API 管理過程的統一。
上圖是融合后云原生 API 網關的功能大圖，白框是已發布功能，黃框是開發中即將推出的功能，灰框是未來 3～6 個月內規劃中能力。在基本的服務發現、路由配置、域名環境設置、安全認證、監控告警之外，用戶可以進行 API 的設計和發布，并通過開放平臺與第三方和開發者進行協同。豐富的策略可以定義在 API 接口或路由不同層面，用戶也可以通過官方或自定義插件來進行二次擴展。對于有彈性需求的用戶，未來我們也會提供定時和基于指標自動伸縮的能力，不需要在日常預留很多機器資源，從而節省成本。最后，在使用原 API 網關或 MSE 網關的用戶可能會問，現有產品的實例怎么辦？對于這兩個存量產品我們依然會保證商業化的支持，并在未來幾個月提供遷移方案協助用戶平滑地轉移到新的網關實例。
那云原生 API 網關帶來的最大價值是什么呢？首先，就是幫助用戶進行網關架構的升級。下方左邊的圖是傳統模式下，用戶為了部署在容器上的微服務應用構建 Nginx Ingress 和 springcloud gateway 兩層網關，前者做流量入口，后者做南北向業務網關，也負責東西向流量。對安全有要求的用戶還要在前面加上 WAF。對于 C 端業務，一般通過路由將服務暴露出去，并在之上進行權限和流量管控即可，用戶是通過 URL 訪問就可以路由到后面的正確的服務上。而對于 B 端業務，需要經過 API 網關產品進行接口細粒度的認證和限流。然后根據服務部署情況，直連后端，或者經由? ingress 流量網關和微服務網關訪問后端，這就導致網關的架構和部署非常復雜，徒增性能損耗，出現故障時排查難度也大增。?
新網關將 API 管理、流量網關、微服務網關、安全網關合一，無論后端服務部署在哪個平臺，客戶業務是 toC 還是 toB，用一套網關技術棧就搞定了，同時它集成了阿里云 WAF 3.0 的數據面，流量直接在網關引擎內清洗，請求鏈路更短。通過這種高集成的產品，用戶不需要多層網關，只需根據業務特點創建對應的實例，并進行一站式地策略設置、觀測分析和問題診斷。即使有問題也不需要去搖好幾波人來解決。不僅將網關的整體資源成本下降 60% 以上，性能和運維效率還能提升一倍以上。另外，它基于開源項目 Higress 構建，用戶無須擔心廠商鎖定，還能將其他云的網關進行統一納管。
新網關帶來的價值之二就是提升研發效率。當前開發測試同學可能會根據自身工作需要使用各種工具，比如 APIDoc、YAPI、Mockjs 等等，多個系統及工具會造成 API 規范不統一、版本錯亂、文檔不一致的問題。新網關使不同角色圍繞在同一個平臺操作，使用同一份 API 定義。它遵循 openapi 規劃，支持控制臺編輯和 Swagger 文件導入導出，一次 API 定義，測試/預發/生產/災備 等多個環境可以重復使用。API 各個版本的信息、發布記錄也一目了然。我們還提供大語言模型輔助的 API 設計、Mock 數據生成、插件代碼開發、請求錯誤診斷，減輕開發測試同學的負擔。
在開發流程上，一般有 API 優先和代碼優先兩種模式，前者是先設計好 API，然后前后端分離，根據 API 約定獨立開發，這時后端服務還沒準備好，前端就用 Mock 方式進行驗證。然后后端開發完畢在測試環境部署，前后端開始聯調及測試，最后在生產環境進行發布。這種模式對于中大型的團隊或項目，能減少開發互相等待時間。而代碼優先的模式，就是先做后端開發，自動或手動生成 API 定義，然后開發前端，再進行聯調、測試最后發布線上。很多開發者習慣這種方式，對于小團隊項目，確實更加敏捷。那云原生 API 網關呢，也提供了不同的操作路徑對這兩種模式分別進行了支持，幫助用戶在各階段把 API 管控起來，促進其規范性。
下面我們來看下云原生 API 網關適用的場景。首先是服務暴露及流量管控。對于部署于容器上的微服務，可以一鍵導入 K8s service 或 Nacos 上注冊的服務。它兼容 K8s Ingress 標準，也支持 Nginx Ingress 核心注解擴展，提供精細化的路由或 API 管控。訪問請求直連容器 Pod IP，并提供限流、預熱、灰度等微服務治理能力。
對于 Serverless 應用，云原生 API 網關與函數計算結合，一個函數對應一個 API 快速對外提供服務，并提供強大易用的鑒權和流控能力，搭建完美的 Serverless 計算平臺。
另外，它支持 ACK、MSE Nacos，FC，DNS 域名，IP 固定地址等多種服務來源，可用于多種后端，多個集群的統一接入層，流量可以按比例或者按請求內容精準路由到不同集群，不同服務，輔以服務健康檢測，fallback 功能，可實現容災多活等功能。
場景二是通過 API 的生命周期管理，來提升研發效率。云原生 API 網關將 API 設計和運行解耦。設計階段，用戶在控制臺輸入 API 定義或者導入已有的 Swagger 文件，生成 API 文檔和 SDK，大家在同一個約定下進行開發、Mock、聯調。利用多環境管理能力，支持不同環境歸屬于不同的網關實例，從而實現一套 API 定義可以發布到不同的環境，對接不同環境中的后端服務。針對 API 及其接口，支持設置不同的認證和流控策略，實現接口級別的訪問控制。通過版本管理功能，可以支持 API 的升級迭代，并提供發布歷史列表以便查看和回滾。最后，如果有 API 廢棄不用，還可以進行下線的操作。
第三個場景是 AI 應用的流量入口和集成平臺。云原生 API 網關支持 AI 應用常見的 SSE 和 WebSocket 協議，配置更新毫秒級生效。如果使用 Ngnix Ingress，每次新增或更新一個路由，就要做 Reload，造成客戶端到后端服務的長鏈接流量受損，用戶正和大模型聊著天，出現中斷，非常影響體驗。使用云原生 API 網關就不會出現這種情況。此外，它支持流式傳輸，尤其像圖片、視頻這種多模態，數據量是非常大的。網關通過流式處理能力能減少帶寬消耗并降低響應延遲，其良好的內存回收機制可避免 OOM，通過 IP/Cookie 等多維度的 CC 防護能力也可防范黑客構造慢請求進行并發攻擊。
另外，我們上線了豐富的 AI 插件。
對于 AI Native 應用，除了調用大模型，還需要利用插件工具訪問企業內外部的傳統應用，并通過編排定義業務工作流，以呈現更豐富易用的產品形態。傳統應用通過云原生 API 網關注冊接口描述和提示，開放 API 能力，并屏蔽認證鑒權等復雜的細節，這樣就方便大模型進行推理識別，找到合適的 API 進行調用，完成 Reasoning and Action 整個流程。
接下來，我們將介紹云原生 API 網關的核心優勢。
性能更強勁
所以，使用云原生 API 網關以后，不僅架構更簡單、訪問鏈路變短，并且性能要比自建高出 1 到 5 倍，實現了總體擁有成本的下降。
穩定更可靠
在穩定性方面，我們在不同的階段，也對網關進行了高可用的保障。
云原生 API 網關從 2020 年就開始服務阿里集團的內部電商業務，歷經了多年雙十一的海量請求和考驗，每秒可以承接數 10 萬筆請求，日請求量可達到百萬級別。此外也支撐了阿里云多個 AI 業務，例如通義千問、百煉、PAI 等云產品的統一接入層，數年來無任何故障。
安全防護
除了穩定性，網關的安全防護能力也是用戶選型網關關心較多的因素。在入口層，我們支持雙向的 mTLS 認證，并集成了阿里云證書服務，對證書進行輪轉更新，防止證書過期沒及時更新的情況出現。默認集成并自動開啟硬件加速，即將 TLS 證書的驗證和卸載轉移到硬件中執行，大幅提高 HTTPS 請求的性能。在登錄認證上，云原生 API 網關支持 JWT/OIDC/ 自定義鑒權等多種認證登錄機制，也提供黑白名單功能。
另外，云原生 API 網關集成了阿里云的 Web 應用防火墻（簡稱 WAF），將 WAF 的數據面下沉到網關引擎中，由 WAF 來下發防護規則。這樣流量就不需要到 WAF 做一次清洗，而是直接在網關上處理，清洗粒度可以控制在路由級別，并且整個流量鏈路更短，減少性能損耗、降低故障排查難度。此外插件市場提供了多種鑒權和防護插件，用戶也可自行編程來擴展安全能力，比如請求/響應的加解密等。最后，云原生 API 網關采用數據面和控制面分離的架構，可以防止控制面的風險外溢到數據面，進一步提升安全能力。
多語言擴展
云原生 API 網關能力擴展方面，提供了以下能力：
API 管理中的 AI 智能化
大家定義或測試復雜 API 時肯定會有很多繁雜的人工操作，比如在填寫 API 響應 body 的 JSON Schema 時，一旦結構復雜非常耗時。在這里用戶只需要提供一個示例，我們網關的AI助手就可以自動生成這個 Json schema。而在 mock 的時候，AI 助手又會根據 Schema 自動生成各種各樣的數據幫助開發進行驗證。我們還在不斷探索新的 AI 助手能力，比如 API 接口自動生成，插件代碼生成，智能診斷近期都會與大家見面，持續地為開發和運維同學提高工作效率。
一個業務應用正式上線前，需要在開發/測試/預發/生產環境依次部署并完成驗證，如果用戶在每個環境的網關實例都去配置 API 接口，做版本管理，對接后端服務那就太復雜了。在云原生 API 網關上，可以通過 “環境”允許相同的 API 指向不同的后端服務。用戶創建網關后系統自動提供一個默認環境，用戶也可以添加新的環境，這里網關實例與環境是 1:N 的關系，比如下圖里，開發和測試共用一個實例，預發使用個實例，生產環境用一個實例。每個環境系統都會提供一個二級域名，用戶再將自定義的業務域名分別 cname 到二級域名，比如生產使用 mypet.com 這個對外域名，預發和測試分別加上 pre 和 test 的前綴，測試就直接使用開發環境的二級域名。這樣 API 設計是一份，發布的時候選擇環境和域名，請求流量就會根據 URL 自動通過對應的網關實例訪問到正確的后端服務。如果搭配函數計算 FC，它可通過別名屏蔽版本變更，各環境無需重復添加函數。比如開發環境總是指向 LATEST 版本，而測試、預發、生產環境的發布總是指向對應的別名，測試同學要驗證的版本從 v1.1.0 切到 v1.1.1，這時只需要更新別名到版本的映射，不需要重新發布 API 更改后端服務，簡化操作流程。
構建入口高可用防線
云原生 API 網關提供多種服務和流量治理能力，幫助用戶在入口層構建業務穩定性防線。
網關可以支持藍綠發布，并和 MSE 微服務治理結合實現全鏈路灰度，例如，后端服務發布新版本后，網關可以按照比例，或者請求的 Header 或 Cookie，將特定的流量引到灰度版本，以快速驗證。遇到問題再切回基線版本，以避免發版引起的故障。
在服務運行的時候，云原生 API 網關支持無損上下線。當服務提供者的部分節點正在下線時，網關能主動將下線的服務節點剔除掉，將所有的請求流量路由到了正常運行的節點中，實現流量無損。針對發布或擴容場景，Java 應用節點在啟動時會有類加載、連接池預熱的過程比較耗時間，一開始就承載很大的業務流量可能會被打掛。網關服務管理中的負載均衡策略中可設置預熱時間，將流量逐漸增大，給予新節點足夠的預熱時間保證其穩定性。此外，云原生 API 網關支持限流策略，包括路由、服務、甚至針對 API 接口顆粒度進行流量限制，用戶還可以通過插件實現自定義的限流策略。比如剛剛我們提到的針對大語言模型的 Token 限流能力。路由規則、插件的更新，均支持熱更新，以保證 AI 場景下長連接的不受損。
最后，我們再來簡單介紹云原生 API 網關的兩種創建過程。
通過路由對外提供服務
創建網關實例之后，用戶可以將自定義域名綁定到網關的訪問地址，然后根據后端服務是否通過 ACK 或 Nacos 來提供服務發現，決定是否要先創建服務來源。有了服務后，開始創建路由，配置限流、重啟、超時等策略，并根據業務需要配置認證方式，最后發布路由，并進行測試。
云原生 API 網關提供了兩種配置方式，一種是白屏化控制臺，一種是 K8s Yaml 來創建路由資源。如果使用后者，用戶在網關控制臺創建服務來源時選中監聽 K8s Ingress 資源，在容器服務側配置的 Ingress 規則會自動同步到 云原生 API 網關生效。云原生 API 網關兼容 K8s Ingress 規范，支持 Nginx Ingress 核心注解的無縫轉換。用戶可以像使用 Nginx Ingress 一樣在容器服務側進行路由管理。
設計 API 并通過接口對外提供服務
如果用戶需要進行 API 優先的開發流程，那么需要先設計 API，然后通過 API 接口對外提供服務。
用戶在 API 的管理頁面，創建 API 并添加接口，研發就能以 API 文檔為中心，進行前后端和測試的協同。開發完后，我們將服務添加到網關。如果是 ACK Service 或 Nacos 的服務來源，就先創建服務來源，再添加服務。如果不是，則可以在發布 API 的時候，直接指向后端的服務，然后去配置相應的認證和 API 限流策略，最后發布并測試。在 API 列表的頁面，我們可以看到各個接口的統一視圖，進行多版本的查看和編輯，并設置豐富的策略。以便以統一的視角去管理不同環境的 API，提高開發和發布效率。
文章轉自微信公眾號@阿里云云原生
