一、API 中介技術概述

背景，API 中介技術變得多樣化，應用與集成架構師需要借助決策框架，從企業級 API 網關、輕量級網關、入口網關以及服務網格中挑選出適合多粒度服務和 API 的中介技術。

隨著無服務器架構與容器管理系統的興起，API 管理、API 網關與服務網格在轉型、流量管理、安全以及可觀測性方面出現了功能特性重疊與互補的情況。例如，企業級 API 網關通常位于網絡邊緣，用于保障進出 API 流量的安全，適合那些具有商業化潛力、面向外部的、產品化且已發布的 API，同時也可用于管理支持跨域集成和共享服務的內部 API；輕量級 API 網關因體積小、配置聲明式且具備 DevOps 準備性，在云原生環境中成為內部 API 管理的熱門選擇；入口網關則應運而生，它結合 API 中介與入口控制器或網關 API 模式，在容器編排平臺上保障、路由和監控外部流量。

然而，面對眾多的 API 中介技術選擇，一方面增加了找到最優解決方案的難度，另一方面也存在過度購買或購買不足導致的各種問題，比如過度購買會使產品利用率低、部署延遲以及運營復雜性和開銷增加，而購買不足或利用不足則會使組織難以維持對安全性不足的影子 API 的可視性和控制。

二、決策要點問題

文章提出決策要點問題是 “我應該選擇哪些中介技術來保護和管理我的 API 和服務通信？”，并闡述了基于 API 網關的 API 中介仍然是保護、管理和監控 REST 端點以供外部、私有和內部使用的最常見解決方案。但隨著網狀應用和服務架構（MASA）以及多粒度服務（包括宏服務、微型服務和微服務）的廣泛應用，容器編排平臺（如 Kubernetes）和服務網格（如 Istio）領域出現了快速創新，這也促使 APIM 市場不斷演變，傳統 APIM 廠商開始支持事件驅動架構（EDA）、服務網格和 GraphQL，初創公司則推出了與服務網格和容器編排平臺集成的 API 網關功能，以保障和管理南北向流量到東西向流量的交接。

三、決策概覽

在選擇 API 中介技術時，需要平衡各種功能性與非功能性標準。該研究的評估標準未納入技能、成本、采購時間以及部署工作量等約束因素，因為首次實施新 API 中介技術的成本遠高于后續實施，若納入這些因素會導致選擇標準失真。

決策工具旨在幫助從企業級 API 網關、輕量級 API 網關、入口網關和服務網格中挑選出合適的 API 中介技術。以下是對這幾種技術的簡要介紹：

• 企業級 API 網關 ：通常位于網絡邊緣，保障進出 API 流量的安全，適合外部面向、產品化且已發布并具有商業化潛力的 API，也可用于管理支持跨域集成和共享服務的內部 API，一般由集成 / 中間件團隊或安全部門集中管理，且可能是包含 API 生命周期管理以及 API 開發人員門戶的更廣泛的 APIM 解決方案的一部分。

• 輕量級 API 網關 ：又被稱為 “微網關”，設計為分布式且部署在靠近單個服務的地方，與企業級 API 網關不同，輕量級網關可由開發團隊單獨部署、配置和管理，以滿足應用需求，例如 Axway Amplify Platform、Google 的 Apigee 和 Apigee Hybrid、IBM API Connect、Microsoft Azure API Management、Salesforce MuleSoft API Gateway 等。

• 入口網關 ：是組織容器環境的一部分，作為容器編排集群或服務網格的網絡通信守門員，所有進入集群內部服務的入站流量都必須先經過入口網關，因此成為保護已部署到集群或服務網格的服務所實現 API 的理想策略執行點（PEP），例如 Contour、Ambassador Labs Emissary-Ingress、Envoy Gateway、Istio Ingress Gateway、Solo.io Gloo Gateway、Trae?k Hub、HashiCorp/IBM Consult API 網關、Kubernetes Ingress、NGINX Ingress Controller、Amazon Web Services（AWS）App Mesh 等。

• 服務網格 ：在應用域內調解服務間（東西向）通信，將與安全和流量管理相關的橫向問題抽象化，同時為開發者實現可觀測性，以一致性和高可靠性實現這些功能，如 Google Cloud Service Mesh、Istio、Buoyant Linkerd、HashiCorp Consul 等。

四、決策工具

決策流程圖旨在幫助選擇合適的 API 中介技術，涵蓋了 Gartner 客戶中普遍存在的約束條件、變量和模式。該流程從假設擁有一個服務且需要控制其 API 訪問權限開始，若服務所公開的 “內部” API 不能被所有客戶端直接使用，則必須定義并發布針對特定用例的消費者中心版本的 API（外部 API），當涉及多個外部 API 時，需重新審視流程中的每個新外部 API 定義。

決策流程包含以下問題：

• 第一步：您的服務是否在容器管理平臺上運行？ ：若服務容器化且在容器管理平臺（如 Kubernetes）上運行，回答 “是”，則需繼續考慮入口網關和服務 / 消息網格，否則選擇企業級 API 網關或輕量級 API 網關進入第二步。

• 第二步：您的服務所公開 API 的范圍是什么？ ：API 的預期用途對于向新消費者發布 API 至關重要，它決定了所需的開發者支持（自動化或自助服務）、監控、安全 / 身份等能力，分為以下幾種情況：

  • 企業范圍 ：API 設計用于在企業內外供廣泛受眾共享和重用，需按照企業信息安全和網絡安全策略進行保護，并應發布到開發者門戶或目錄以支持 API 用戶的設計時發現、共享文檔、API 規范和運營信息。

  • 應用范圍 / 子應用范圍 ：API 專為特定用例設計，公開特定于應用的功能，通常不適用于其設計的應用 / 項目之外的重用，其和消費組件通常由同一項目或產品團隊設計和開發，并負責管理其生命周期，盡管通常不發布到開發者門戶供跨域消費，但仍應注冊到 API 目錄中進行管理和保護，現代開發者門戶允許使用細粒度的訪問控制將應用范圍的 API 發布給有限受眾（如開發團隊），或者可使用內部開發者門戶來對 API、服務和其他軟件資產進行目錄管理。

若 API 是企業范圍的，則進入第三步評估企業級 API 網關的適用性；若是應用范圍甚至子應用 / 組件范圍的，則進入第四步評估輕量級 API 網關。

• 第三步：API 是否符合企業級 API 網關標準？ ：若前幾步的回答表明企業級 API 網關可能是調解 API 的合適候選，則需要進一步審查一些額外標準來驗證這一選擇，關鍵標準包括 API 實現的是企業范圍的、旨在作為企業資產共享和重用的 API，通過 “失敗向上” 路徑在考慮輕量級網關標準后到達此處，API 在企業邊緣 / 邊界處受到保護，API 被發布到企業外部的消費者等。若對一個或多個標準回答 “是”，則應選擇企業級 API 網關作為服務外部 API 的中介技術，否則考慮輕量級 API 網關。

• 第四步：API 是否符合輕量級 API 網關標準？ ：若到此為止的回答表明輕量級 API 網關可能是最佳選擇，仍需審查額外標準，關鍵標準包括 API 在企業內廣泛共享和使用、作為產品進行管理、以業務價值為導向、在應用域內發布 API、將 API 流量限制在內部網絡 / 域邊界內等。若對一個或多個標準回答 “是”，則應選擇輕量級 API 網關作為服務 API 的中介技術，否則重新考慮企業級 API 網關。

五、原則、需求與約束

決策流程簡要展示了如何為特定用例到達有效的中介技術，這一部分則揭示了決策流程背后的邏輯所依據的要求和約束。

（一）要求

• 使用 JSON 網絡令牌（JWT）進行請求身份驗證和授權 ：在授予對服務的訪問權限之前，需要使用 JWT 對調用者進行身份驗證 / 授權。

• 可觀測性和依賴分析 ：對應用和基礎設施與運營（I&O）團隊而言，服務行為、拓撲和服務依賴關系的可觀測性至關重要。

• 服務流量管理 ：對于微服務架構而言，細粒度的流量管理能力至關重要。

（二）約束

• API 網格東西向流量不多。

• 運行服務網格的開銷超過了應用本身所需的資源。

• 應用的網絡拓撲相對靜態，無需調整以適應動態路由策略或支持頻繁的組件更新。

六、集成現有基礎架構

多數組織在本地和云環境中擁有多種現有基礎架構，如應用交付控制器（ADC）、網絡應用和 API 保護（WAAP）、API 網關、容器管理平臺、企業服務總線以及集成平臺即服務（iPaaS）等，可利用與要求相符的現有企業級 API 網關和應用及集成基礎架構進行 API 中介。

例如，在混合云或 multicloud 部署中，API 消費者與 API 提供者之間的接近程度可幫助確定 API 網關實例的放置位置以及整體 APIM 部署拓撲；服務運行時基礎架構（如虛擬機、無服務器 FaaS 和容器管理平臺）也可能影響或限制 API 網關形式因素的選擇；若需要跨異構運行時基礎架構（如虛擬機和容器化服務）支持服務間通信，那么具備這種能力的服務網格相對較新，應謹慎使用。

七、利用集成技術

中介技術旨在提供治理能力，如訪問控制、流量管理和協議調解等，不包含業務邏輯。表 1 描述了 API 中介的理想、可能或不合適的負載情況。

在 API 中介網關中添加復雜的調解、轉換或編排邏輯是一種反模式，會導致膨脹和緊密耦合，并模糊 API 策略執行與服務實現之間的界限。涉及業務邏輯的功能，如復雜的轉換、聚合或服務編排，應在單獨的服務中實現，而不是在調解層中。

八、結合同步與異步通信

并非所有服務間通信都采用同步請求 / 響應模式，事件驅動的通信模型可降低服務之間的耦合度和依賴性，從而提高適應性和靈活性。常見的設計模式（如事件溯源和命令查詢職責分離）基于同步 API 前端與 EDA 構建，使用事件代理促進命令和查詢模塊之間的事件流動。技術專業人員應將基于請求或響應的調解與異步事件驅動模型相結合，以實現現代化的應用交付。

直接連接到消息（或事件）代理的服務使用特定于代理的協議或基于標準的消息協議。當前 API 中介技術（如 API 網關和服務網格）通常對 EDA 和異步消息傳遞的支持有限，因此可能不足以調解服務與消息（或事件）代理之間的通信。

九、優化 API 和服務的企業治理模型

API 和服務的企業治理模型從集中控制到聯邦自治不等，組織通常采用介于集中治理模型和聯邦治理模型之間的混合模型。

• 集中治理模型 ：強調在整個企業范圍內對 API 生命周期的一致性和控制，通常圍繞集中式的 APIM 團隊實施，例如，API 卓越中心可能負責分享 API 最佳實踐，并確保在 API 設計和策略執行方面的一致性，使用企業網關和開發者門戶。

• 聯邦治理模型 ：將 API 治理權下放給多個分散的業務線團隊或地理位置，該模型更注重自主性、敏捷性和獨立性，采用此模型的組織通常擁有多樣化、自主的業務線團隊，這些團隊有權根據當地環境或產品需求優化其治理模型。

• 混合集中和聯邦治理模型 ：使組織能夠在集中一致性和控制與分布式團隊的分散自主性和敏捷性之間取得平衡，組織需要根據組織結構和文化定制合適的治理方法，結合企業級 API 網關、輕量級網關和入口網關以及服務網格可提供全面的控制，組織可以執行 API 和服務的混合治理模型。

治理模型決定了組織如何實施和管理 API 網關、入口網關和服務網格等中介技術，還決定了負責操作、配置和利用每個中介層的角色。分配給開發和產品團隊的控制和自主權的程度可以使其有效利用中介技術進行應用開發和交付。

十、與平臺工程協作

平臺工程團隊負責工程、交付、維護和改進自助服務應用平臺或 PaaS，包括 CI/CD 工具鏈，為多個敏捷應用團隊構建定制軟件。平臺工程團隊負責 API 網關、API 和服務目錄、容器管理平臺以及服務網格的持續運營，通常配置這些平臺的控制平面，并為生產團隊 / DevOps 團隊設置全球策略、“合理” 默認值和護欄。

在不影響跨團隊一致性和治理的前提下，某些應用、服務和 API 的特定策略和配置可委托給負責的 DevOps 團隊，以優化開發團隊的自主性和效率。平臺工程團隊通常擁有內部開發者門戶的實施和交付，這對于提供有效的開發者體驗至關重要。

十一、使用企業級 API 網關的標準

企業級 API 網關過去是最常見的 API 中介技術，傳統上用于作為 APIM 的一部分治理 API 的內部或外部發布，以支持集成、開發和生態系統。以下是使用企業級 API 網關的標準檢查清單：

• 在邊緣 / 邊界處受保護 ：API 保護和 API 訪問控制作為企業整體 API 安全策略中的第一道防線和控制措施至關重要，邊界保護是保障外部和合作伙伴 API 安全的必要措施，而組織采用分布式執行模型來保障企業范圍內的 API 安全。

• 在企業外部公開 ：該 API 是外部、私有或合作伙伴 API 嗎？企業外部公開的 API 包括公共 / 開放 API、支持移動和 Web 應用的 API，以及專用于合作伙伴和客戶的私有 API，所有情況下消費者都在企業邊界之外。

• 在企業內部廣泛共享 ：是否有在企業內部被廣泛共享和使用的 API？通過云連接（如 AWS Direct Connect、Google Cloud Dedicated Interconnect 或 Microsoft Azure ExpressRoute），企業網絡的邏輯邊界延伸至混合云和多云環境。

• 作為產品進行管理 ：該 API 是否將被產品化并在開發者門戶或 API 市場中發布？API 被打包并交付給客戶，作為產品或產品的一部分，并有產品經理和交付計劃作為支撐。

• 以業務價值為導向 ：該 API 是否旨在為業務直接和間接創收？直接貨幣化 API 通過收取 API 產品消費費用來產生收入，而間接貨幣化 API 則在不直接追蹤收入的情況下交付業務價值。

十二、使用輕量級 API 網關的標準

應用架構師有時會問：“如果企業網絡邊緣已經運行了企業級 API 網關，我是否還需要輕量級 API 網關？”答案是肯定的，因為如果不想讓內部用戶通過企業級 API 網關進行路由，那么也需要輕量級網關用于這些用例，以下是一些驗證輕量級 API 網關益處的標準問題：

• 在應用域內發布的 API ：該 API 是由產品團隊為應用或一組相關應用發布的內部 API 嗎？是否是特定應用的私有后端 for 前端 API？內部 API 可能封裝域功能，以支持應用上下文內的跨域交互，其消費者位于企業內部網絡邊界內。

• 將 API 流量限制在網絡 / 域邊界內 ：是否需要將內部 API 流量限制在受信任的網絡內，以滿足安全和合規要求？是否擔心在 API 消費者和提供者位于同一受信任網絡時，通過云端或非軍事化區的集中式 API 網關路由 API 流量所引入的延遲？戰略性地放置由開發團隊管理或專用于開發團隊的 API 網關，可以優化應用網絡拓撲，減少網絡延遲，并改善 API 流量在指定邊界內的隔離和分段。

• 特定于應用的細粒度策略 ：該 API 是否具有特定于應用的細粒度策略？應用需要在其微邊界內實施某些特定于域的細粒度 API 策略，這些策略可能包括基于應用內定義的角色或屬性的授權策略、支持藍綠或金絲雀部署的流量管理 / 路由規則、基于用戶角色的數據脫敏規則等。

• 以開發者為中心的 DevOps 自動化 ：是否要求 / 希望將 API 中介策略作為 DevOps 流程的一部分進行部署？應用范圍的 API 通常表現為迷你服務，公開域功能，它們是獨立可部署的，并且與應用發布 / 更新周期一致的定期發布節奏相關聯，因此應用開發團隊更愿意將 API 生命周期作為應用 CI/CD 流程的組成部分進行管理，外部對企業 API 團隊的依賴會阻礙開發團隊的敏捷性、自主性和對其應用 CI/CD 流程的控制。

十三、使用入口網關的標準

入口網關是容器管理平臺（如 Kubernetes）或服務網格（如 AWS App Mesh）的入口點，應用架構師常會問是否應使用入口網關保護和路由進入 Kubernetes 集群或服務網格的外部 API 流量。

小結：

該研究主要聚焦于 API 中介技術的選擇框架，旨在幫助應用與集成架構師在多樣化的企業級 API 網關、輕量級網關、入口網關以及服務網格中挑選出合適的解決方案，以應對多粒度服務和 API 的需求。文章闡述了 API 中介技術的多樣化現狀及發展趨勢，強調了 API 管理、網關與服務網格在滿足無服務器架構和容器系統需求過程中出現的功能重疊與互補，并指出了企業在購買 APIM 產品時存在的過度購買或購買不足的問題。同時，介紹了決策工具的使用方法，該工具通過一系列問題引導用戶根據服務運行環境、API 范圍等關鍵因素選擇恰當的 API 中介技術。此外，文章還探討了與平臺工程協作、優化 API 和服務治理模型等方面的內容，并對 API 中介技術的未來發展趨勢進行了展望，如 API 治理與服務治理的融合、服務網格控制平面的創新等，為技術專業人員提供了全面的指導，以應對在分布式企業應用環境中實現 API 和服務一致治理的挑戰。