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