《F5：API 持續蔓延白皮書（26頁）.pdf》由會員分享，可在線閱讀，更多相關《F5：API 持續蔓延白皮書（26頁）.pdf（26頁珍藏版）》請在三個皮匠報告上搜索。

1、Continuous API SprawlChallenges and Opportunities in an API-Driven Economy.By Rajesh Narayanan,Mike WileyOFFICE OF THE CTO REPORT$300ORDER NOW$20.8首席技術官辦公室報告API 持續蔓延API 驅動型經濟的挑戰與機遇作者：Rajesh Narayanan，Mike Wiley2API 持續蔓延目錄3 前言4 簡介 4 經濟影響5 API 蔓延將持續存在并擴大 5 API 具有多種類型和大小7 API 增長量建模 7 參數8 結果10 造成 API 蔓延

2、的因素10 缺乏標準10 微服務架構10 持續軟件開發11 集成挑戰11 業務部門孤島12 混合基礎架構13 邊緣計算 13 一切即服務14 為什么這在當下是個問題？14 大規模運營15 大規模安全防護18 信任衰減18 機密蔓延19 我們的應對之策19 集群內 20 API 蔓延是一個集群間問題 24 總結25 參考資料3API 持續蔓延前言應用程序編程接口（API）經濟是無處不在、無時不有的所有公共和私有 API 經濟活動的總和。API 持續擴張，不久將成為全球經濟發展的重要推動力。就像主宰我們生活各個方面一個多世紀的石油行業一樣，API 也將成為推動經濟發展的主要力量。在成為推進數字化轉

3、型的重要引擎之前，API 主要用于集成和進入更大的生態系統。如今，近一半（43%）的企業除了較為傳統的技術用例之外，還利用 API 作為創收來源1。盡管 Twilio 和 Stripe 等公司展示了未來 API 將是一個強大的企業工具，但很少有企業能夠充分認識到 API 在促進經濟活動方面的強大作用。隨著我們轉向 API 驅動的經濟，我們需要解決的問題變成了 API 端點的激增（又稱為“API 蔓延”）。了解 API 蔓延原因并構建強大基礎架構（包括人員、流程和工具，以優化 API 的使用）的企業將在這個新的 API 驅動經濟中取得長足發展。API?API?API?API?如果將數據比作新石油

4、，那么 API 就相當于新塑料。負責任地創建、使用和管理 API 至關重要，否則 API 蔓延將污染和破壞生態系統。構建強健 API 基礎架構的第一步是處理 API 蔓延的問題。雖然我們直覺上認為這個問題當下不會嚴重影響業務，但未來一定是個燙手山芋。API 蔓延是指 API 數量呈指數級大量增長，以及 API 所在的分布式基礎架構廣泛分布在各個物理位置。圖 1：API 驅動的經濟圖 2：蔓延與 API 的規模和分布有關?API?4API 持續蔓延簡介 API 是服務提供者和服務消費者之間的一個協議。任何應用在使用 API 時都需要遵循共同議定的協議標準。由于消費者一般不關心背后的故事，服務提供

5、者會使用一切必要手段來交付價值，可能會選擇任何技術來交付服務，而這些技術不一定會優化交付服務所需的資源。經濟影響API 已經從一個支持兩個獨立系統通信的簡單軟件構造，發展成為允許任何聯網實體通過明確定義的協議進行價值交易的一種手段。API 最初主要是用作兩個應用相互通信和交換數據的標準途徑，而今已升級為服務提供者向 API 消費者交付價值的媒介。API 支持廠商在數字市場中提供商品和服務。API 的使用促成了拼車（優步、Lyft 等）、房屋租賃（愛彼迎等）和外賣服務（Doordash 等）等應用，顛覆了運輸、酒店和餐飲業。YouTube、抖音、Instagram 等應用讓有創意的人們吸引了大量

6、粉絲，并得到了贊賞和獎勵。API 讓我們無需面對面即可安全地與世界各地的任何人進行交易。舉例來說，物聯網（IoT）設備通過 API 交換其當前狀態來證明其價值。從娛樂應用到盈利的企業應用，API 驅動的應用滲透到了我們生活的方方面面，但我們挖掘到的經濟價值不過是九牛一毛而已。為了充分釋放 API 的經濟和技術優勢，我們必須首先掃清 API 蔓延這個重大障礙。5API 持續蔓延API 蔓延將持續存在并擴大 API 蔓延的原因在于它的分布很廣，但卻缺乏整體性的策略（包括治理和最佳實踐）。更糟糕的是，開發團隊對應用生命周期過程的持續不斷開發和部署，這讓 API 蔓延根本停不下來。應用和 API 隨時

7、間不斷變化，不同的版本也有著不同的分布特征。圖 3 顯示了單一 API 就會演變出多個用途的多個版本，并且每個版本都擁有自己的版本歷史記錄。我們必須要清醒地認識到，API 蔓延是一個持續的問題，原因有二。其一，有關 API 數量的任何市場數據都是保守估計，因為 API 會隨時間增長；其二，任何解決方案建議都必須考慮這一持續性。API 具有多種類型和大小2API 可分為不同的種類。網上關于 API 的定義和分類五花八門，其中 ProgrammableW 上的詳細列表與我們的想法最為貼近。?API?圖 3：即使是一個 API 也會隨時間變化和蔓延6API 持續蔓延API（不論類型如何）從廣義上可分

8、為：公共 API 可供任何人使用的 API（例如 Google Maps API）。私有 API 僅供內部團隊或僅在應用集群內使用的 API。合作伙伴 API 與第三方廠商集成的 API，可創造更多價值（例如允許將 Netflix 應用安裝在 Roku 設備上的 API）。API 可分為不同的類型：Web API 可通過 Web 訪問的 API。產品 API 集成到產品中的 API。購買并部署產品后即可啟用該產品的 API 版本。瀏覽器 API 瀏覽器中的 API，開發人員可以訪問并能夠以不同方式重新組合。標準 API 企業或標準機構發布的要求所有人遵循的 API。例如，瀏覽器可以通過一組標準

9、 API 訪問底層系統的功能。嵌入式 API 將設備與物聯網傳感器等專有數據連接起來的 API。API 還可以根據范圍劃分：單用途 API 具有單個功能的 API（例如使用 Dropbox 進行存儲）。聚合 API 聚合同類公司的服務并將這些服務作為單個 API 提供服務（例如存儲聚合商可通過編排多個存儲提供商的專有 API，提供經過存儲聚合的單個 API）。微服務 API 通常在微服務架構范圍內的 API。這些 API 使用一定的業務邏輯對企業內的不同微服務進行組合和打包，然后通過單個 API 暴露。圖 4 形象地展示了由于微服務架構的激增，API 數量從最初的單體系統中的幾個，變成現在的指

10、數級增長狀態的過程。圖 4：API 蔓延圖2010201520217API 持續蔓延API 增長量建模 據我們估計，全球（公共或私有）API 的數量已接近 2 億。參數API 的增長量化并不簡單，因為它依賴于幾個參數。全球開發者數量 編寫 API 的開發者數量 每個開發者每年編寫的 API 數量 開發者總數的平均增長量 編寫 API 的開發者數量的平均增長量 每個開發者每年編寫的 API 數量的平均增長量 每個 API 的平均有效期我們可以根據上述參數合理推導出一個模型，估算 API 十年的增長量。下表（圖 5）顯示了數據模型中的假設，用以建立基準。下圖中的藍線代表基準。12018 年全球開發

11、者數量23.92編寫 API 的開發者的比例30%3每個開發者每年平均編寫的 API 數量9.44全球開發者的平均增長率不適用5全球 API 開發者平均增長率15%6每個開發者每年編寫的 API 數量的平均增長量15%7多年 API 平均有效期1API 增長模型假設 2018 年開發者起始數量為 2,390 萬。我們從不同來源找到了開發者數量的參考資料（從 2018 年開始）。公平地說，不同來源的數據可能相差很大；例如，據 SlashData 估計，截至 2021 年 4 月，開發者數量約為 2,400 萬。3年份開發者數量（百萬）201823.9201926.4202026.7202127.

12、1202227.5202327.7圖 5：API 蔓延基準模型參數圖 6：開發者增長數據續。8API 持續蔓延年份開發者數量（百萬）202428.7202531.9202633.7202736.9202840.3202942.3203045我們的模型使用的是 2018 年的 2,390 萬。不過稍后您就會明白，這個起始數字并不重要。上表（圖 6）顯示了全球開發者的數量。黑字行數據摘自外部參考資料，紅字行數據根據我們對 2030 年的預期估算得出。結果圖 7 為 API 十年的預計增長量。該模型包括非常保守（紫色）和激進（淺藍色）的增長量。無論具體的數字如何，API 增長量都非常驚人，到 203

13、1 年，API 數量可能會超過 10 億。API 十年增長量根據以下模型分析得出。API 增長量與 API 有效期有關：十年預計增長量圖表假設 API 有效期為一年。圖 8 顯示了 API 增長量與 API 有效期有關。在該圖中，我們估算了任何給定年份的有效 API 數量。該圖基于兩年或三年 API 有效期，累加了過去兩年和三年的數據，以估計任何給定時間點的有效 API 數量。根據該模型，到 2030 年，有效 API 的數量將接近 17 億。圖 7：API 10 年預計增長量?API?201820040060080010001200202020222024202620282030API?AP

14、I?API?9API 持續蔓延API 增長量與 API 開發者數量有關：影響 API 增長的另一個參數是開發者數量。我們看到，開發者數量在不斷增長，2018 年開發者基數為 2,390 萬。我們根據開發 API 的開發者數量（分別占全球開發者總數的 30%、60%和 90%）計算 API 增長量。圖 9 顯示了 API 增長量與不斷增長的開發者數量有關。根據該模型，到 2030 年，僅有效期為一年的 API 數量就將達到 20 億。綜上所述，起始值是多少真的無關緊要。無論我們假設開發者數量在 2018 年還是 2021 年為 2,400 萬，到 2030 年 API 都將達到上億個，為我們的客

15、戶以及整個行業帶來嚴峻的可擴展性、可管理性及安全性挑戰。我們調整模型的那些參數并不重要，重要的是，API 蔓延將成為一個全球性問題。發現、網絡連接、集成和安全防護勢必將會成為整個開發運營生態系統的重大挑戰。圖 8：API 增長量與 API 有效期有關?API?API?API?API?201820060040080010001200140016001800202020222024202620282030API?API?1?API?API?2?API?API?3?API?API?=?20%/60%/90%?2018500100015002000250020202022202420262028203

16、0?“30%”?“60%”?“90%”圖 9：API 增長量與全球開發者數量有關10API 持續蔓延造成 API 蔓延的因素4所有業務部門都通過某個應用平臺（無論是單體應用還是微服務應用）部署服務，API 正逐漸成為與這些服務交互的標準途徑。缺乏標準雖然我們擁有數據格式標準，例如使用 JSON 和 XML 封裝 API 交換的數據，但 API 本身的全球標準寥寥無幾。有趣的是，幾個新興的 API 標準更側重于業務領域。舉例來說，FDX 是一家“致力于圍繞通用、互操作且免版稅的技術標準（稱為FDX 應用程序編程接口（FDX API)）統一金融服務生態系統”的組織。5 FDX 的成員幾乎涵蓋了所有

17、金融企業，在制定標準方面具有強大的優勢。但在技術領域，API 與它們的前身命令行界面（CLI）一脈相承。沒有兩個 API 是相同的。例如，基礎架構即服務（IaaS）提供商可以將一組服務器資源表示為服務器池（Server Pool)，也可以表示為服務器場（Server Farm)。這兩種 API 可能具有一樣的功能，在業內存在明顯的重疊。API 可能反映了應用的內部數據模型，沒有既定或正式的標準。缺乏通用共享模型是 API 蔓延的一個重要原因。微服務架構隨著數字化轉型的開展，越來越多的企業開始采用基于云的微服務架構。這種微服務化導致應用內出現大量的 API。此外，企業往往通過 API 創建對傳統

18、系統的訪問層。微服務不斷增長，API 通常用于將“傳統”應用擴展到隱藏界面。實際上，這是導致 API 蔓延的一個重要因素，因為 API 既通過微服務連接北向接口，又在微服務之間進行橫向連接。持續軟件開發API 蔓延的另一個因素是現代軟件開發的現狀，現代軟件開發過程本身是持續的，經常會導致前面提到的同一個 API 擁有多個版本的問題。隨著企業越來越多地采用持續迭代的軟件生命周期，開發人員可以在短時間內開發出許多 API 以及 API 的許多版本。這會使 API 版本變得難以跟蹤。此外，如果開發人員在實際開發過程中不夠仔細，文檔記錄也會受到影響。因此，持續修改、更新和變更 API 會加劇蔓延問題（

19、例如企業可能會在不同地區采用同一個 API 的不同版本）。11API 持續蔓延敏捷開發過程使得團隊能夠在較短周期內開發新的 API 并快速增強現有的 API。跟蹤已棄用、部署或刪除的 API 的不同版本可能會成為一項艱巨的管理任務。由于現有客戶支持問題，企業可能需要在很長一段時間內維護已經棄用的 API。如果開發團隊或運營團隊發生變化，這些 API 可能會變成無主的僵尸 API，散養在基礎架構的某個地方。由于持續開發和缺乏標準，API 最終將會出現多個版本，從而對集成工作構成重大挑戰。集成挑戰集成是當今開發人員的主要關注點，因此也是推動 API 增長的重要因素。應用現代化促使 58%的企業添加

20、了 API，以通過現有傳統應用打造現代用戶體驗。6 根據 Postman 博客，7 約 70%的企業表示內部應用、程序或系統之間的集成是創建新 API 的主要原因。許多公司都制定了無縫集成軟件資產的內部計劃。這種集成在技術上有難度，在組織上也有挑戰。任何企業的大部分軟件資產要么是有機發展而來，要么是通過并購獲得。而現在，API 不僅是應用“粘合劑”，還是“業務粘合劑”，因為它們能夠讓經濟和服務生態系統的參與者們加強戰略合作伙伴關系。當今，83%的企業認為 API 集成是其業務戰略的重要組成部分。8API 在兩個應用之間創建了一個明確定義的接口，讓企業在集成應用的同時，保留服務內部和外部客戶的不

21、同產品團隊的自主權。值得注意的是，這些通過 API 集成的自主運營的不同業務和產品部門必須不能產生重復和混淆。業務部門孤島業務部門在組織設計上呈孤島式。不同的產品和開發團隊也會因為其所采用的最佳實踐而變成孤島。集成這些業務部門開發的服務挑戰重重。在成熟的業務部門中，企業可能會為一個超大項目中的不同微服務和產品配備不同的產品開發團隊。此外，并購也會帶來新的孤島、架構和 API。最終，這些團隊可能會為同一個服務重復創建 API，從而帶來集成挑戰。各個團隊可能會對“哪個團隊的哪個 API 更好？”之類的問題爭論不休。這種討論很快就會引發“企業政治”和 NIH（非我所創）9 綜合癥。12API 持續蔓

22、延混合基礎架構業務部門孤島的一個后果就是，每個團隊都根據自己的熟悉程度和技能組合采用基礎架構策略（圖 10）。在本地時，各個團隊對 OpenStack、VMware 及其他自主開發技術爭論不休，而到了云端，又會為 GCP、亞馬遜云科技、Azure 及自己熟悉的任何技術據理力爭。因此，API 分散在多個位置，難以追蹤。隨著多云定義擴大（圖 11）到新興的邊緣計算平臺和環境，API 蔓延問題也將繼續擴大。?11%7%?21%11%?28%13%?23%20%?18%48%?圖 10：采用多種架構的企業1013API 持續蔓延邊緣計算 隨著云擴展到資產可用的地方，并且更接近數據生成的地方，邊緣計算成

23、為分布式云的一部分。API 移動性：API 已成為與不同數據源交互的主要途徑。API 也越來越在靠近數據的地方收集、整理和預處理數據。如果數據源移動（例如在移動設備或物聯網設備中），相關 API 也會隨之移動。API 可能會移動到地理圍欄之外的新目的地，但受到限制。企業可能還需要不同版本的 API，具體取決于訪問 API 的企業類型、物理位置、安全需求或監管環境合規性。數據蔓延：數據蔓延帶來了 API 蔓延，因為數據本質上是分散的。隨著 API 成為訪問數據的網關，邊緣計算的興起讓 API 分散在數據所在的各個位置，進一步加劇了蔓延。應用開發人員使用 API 收集數據并創造更多價值，但同時也帶

24、來了更多復雜性。一切即服務軟件即服務的下一個飛躍是一切即服務（XaaS)，任何有形的東西現在都可以在即服務模式下使用。任何有形的事物都可以通過軟件建立“數字孿生”模型11，并通過 API 進行調度和交付。愛彼迎、優步、DoorDash 等公司都使用了 XaaS。隨著 XaaS 產品數量的增加，我們又產生了對標準或常見 API 呈現方法的需求。但在更大范圍內統一這些 API 是無法實現的。我們面臨著巨大挑戰，同時也面臨著重大機遇。圖 11：云部署及其他部署?72%68%28%27%15%14API 持續蔓延為什么這在當下是個問題？在以 API 經濟為基礎的數字世界中，這些 API 必須 100%

25、可靠。人們必須能夠隨時隨地從任何設備或實體訪問它們。在 Postman 博客中，12 企業列出了選擇 API 的四大理由，分別為可靠性、安全性、性能和文檔。API Academy13 概述了影響可靠性的幾個因素：一致性、可用性、低延遲、安全性和狀態報告。問題是“當 API 遍布異構和分布式云時，我們如何可靠地跟蹤可靠性？”以下幾個因素將影響 API 的可靠性，同時 API 蔓延的規模之大、分布之廣又會進一步加劇這些因素。大規模運營在受限環境中（例如在集群內），我們更容易通過集中管理和控制發現、連接、保護及建立信任。蔓延問題讓我們不得不調整思考方式，將純粹的分層模型調整為分布式自主擴展模型。無真

26、實來源隨著企業的發展，API 的數量和應用的復雜性也在不斷增長，追蹤這些應用的位置變得非常困難。API 可能隱藏在不同的基礎架構之后，我們無法記錄或發現所有 API。無論實際數量是多少，這個問題都很嚴峻。如果開發人員忽略了 API 的有效期，那么過期的 API 就會不受支持。我們需要一份已棄用或不受支持的 API 清單，類似于“API 垃圾回收站”。未來十年里，服務將如雨后春筍般涌現，驗證公共或私有 API 的最新版本、可支持性、安全性等，并將其作為 SaaS 平臺提供，也就是真實的 API 來源。API 發現挑戰企業目前面臨的另一個重大挑戰是發現企業內外部的 API?，F有的方法往往只覆蓋一個

27、應用集群內的 API（例如服務網格中的 API 網關）。但即使是一個企業也可能擁有數百個使用不同服務網格技術的集群。15API 持續蔓延API 不僅位于集群內，而且位于集群間（圖 12）。版本控制和文檔因 API 更新、棄用或不支持某些協議而引起的 API 快速變更是版本控制的主要問題。人們希望調用此 API 的遠程服務也進行變更。如果微服務由同一團隊為同一應用設計，這可能行得通，但如果 API 作為第三方發布或由第三方使用，復雜性會迅速增加。API 也擁有生命周期，到期后可能會不受支持或無法使用。API 到期后，開發者必須實施備份，而且還必須變更應用以處理響應。連接挑戰使用服務網格等方法的前

28、提是擁有強大可靠的網絡連接。在企業內部，這在某種程度上可能是正確的。對于少數幾個高優先級項目，網絡基礎架構和安全團隊可能會緊密合作，實施網絡規劃、配置及安全防護，從而確保提供可靠的端到端連接。在大多數情況下，API（公共或私有）跨集群分布，傳統的網絡連接方法可能無法簡單輕松地連接這些 API。大規模安全防護2020 年，90%以上的企業都經歷了 API 安全事件。14 每個 API 都是安全邊界上的一個點，如果沒有適當架構或保護，可能就會遭到黑客入侵。重申一下，“蔓延”一詞既表示規模之大，又表示物理分散之廣。在這種規模下，安全性不能作為附加功能實施。它必須貫穿從代碼到部署再到使用周期結束的整個

29、 API 生命周期。uService?A?uService?B?圖 12：集群內與集群間16API 持續蔓延圖 13 顯示了 API 和 Webhook 之間的區別（討論見下）。API 容易引發欺詐和惡意行為企業在使用 API 時稍有不慎，黑客就會趁機發起欺詐和惡意行為。產品和開發團隊可能會為了趕工期，匆匆考慮集成外部 API 提供的某個功能。如果他們不對 API 提供商進行盡職調查，可能會引發基本安全問題和復雜攻擊，例如利用受污染數據破壞業務。假設有兩家競爭企業：RED 和 BLUE。它們都是零售店或實體店?，F在 BLUE 部署了一個應用，顯示其各個商店的最近位置。BLUE 使用的地圖服務由

30、 PURPLE 通過 API 提供。?API?Webhook?圖 13：API 和 Webhook?Purple?圖 14：API 欺詐示例17API 持續蔓延圖 14 說明了惡意攻擊者無需劫持客戶端（BLUE）即可對其進行長期騷擾。RED 收購或投資 PURPLE，并僅在 BLUE 訪問它時賦予 API 隨機性或不準確性。還有一種可能更為復雜并且影響更長遠：政府黑客或黑客組織劫持 PURPLE 的 API，影響 BLUE 的性能，并最終影響 BLUE 的股票；這種問題的檢測用時很長甚至根本檢測不到。Webhook 可被黑客利用Webhook15 基本上是用戶定義的 HTTP 回調或鏈接到 W

31、eb 應用的小段代碼。這些回調由使用這些回調的遠程站點中的特定事件觸發。舉例來說，如果 BLUE 服務通過 PURPLE 服務注冊了一個 webhook，那么它是在指示 PURPLE 服務在出現特定觸發事件時調用它。與 API 不同，webhook 是異步的。任何需要其他軟件程序發送事件通知的應用都可以注冊一個 URL。大多數安全團隊似乎都依賴 webhook URL 的匿名性來保持安全性。Webhooks 可能風險更高（圖 15），因為如果惡意攻擊者可以入侵 PURPLE，他們便可以直接調用 BLUE，而無需等待 BLUE 發起請求。Webhook URL 一旦暴露，其數據模型就會公開，任何

32、黑客都可以侵入服務，并異步發送一個格式錯誤的數據對象。Dark Reading 的一篇文章16 揭露了攻擊者利用暴露的 webhook 在 Slack 頻道（因 webhook 暴露而遭到入侵）上實施網絡釣魚攻擊的過程?！癎raves 稱，快速掃描 GitHub 發現了 130,000 多個包含 Slack webhook URL 的公共代碼，其中大多數包含完整的唯一值?！焙诳涂梢暂p松地掃描所有 GitHub 倉庫，查找公共 Slack webhook URL，并自動發送帶有網絡釣魚鏈接的錯誤格式消息。?Purple?BLUEPURPLE?WH圖 15：Webhook 欺詐示例18API 持續

33、蔓延信任衰減API 安全是一個復雜的話題，“信任”是其中的一個重要組成部分。當企業內部的服務訪問知名外部 API 時，該平臺必須實施一種讓調用服務保證從外部 API 接收到的響應的準確性的機制。僅僅因為 API 響應看起來有效，并且來自先前驗證過的端點，并不意味著我們可以信任它（圖 16）。響應結果可能會因質量問題而不準確，或者如前所述，競爭對手可以明確地在 API 中插入不準確性，以降低企業的競爭力。與敏捷過程一樣，信任是持續的，必須不斷進行驗證。機密蔓延機密17 代表著允許使用特權訪問系統的任何東西。計算機系統中有多種類型的機密：用戶名/密碼組合、客戶端 ID/機密、證書、令牌、密鑰和數據

34、庫憑證。最常見的 API 身份驗證方法是通過 API 密鑰?？蛻艨梢栽诓话踩奈恢秒S機分發 API 令牌。API 密鑰可以以明文形式存儲在數據庫或源代碼（git 倉庫）中，可以放到辦公室電子郵件或個人電子郵件中，也可以在備份驅動器或 Google 驅動器中找到。這也是 API 蔓延會加大安全風險的原因。當機密散布在分布式基礎架構中時，許多攻擊向量都會暴露出來。硬編碼的密鑰或憑證（例如在 git 倉庫中）可能會無意中暴露應用服務。攻擊者只需破解一個 API 密鑰就可以訪問關鍵基礎架構。在2021 年 IBM 安全 X-Force 云威脅態勢報告中，有兩個關鍵要點佐證了上述結論：一，三分之二的云事

35、件都與允許不當訪問的配置錯誤的 API 密鑰有關；二，通過公共代碼庫公開 API 證書往往會給攻擊者訪問云環境提供可乘之機。非托管 API 蔓延是一種即將出現的安全漏洞。?+?圖 16：信任證明很復雜19API 持續蔓延我們的應對之策API 蔓延是現代軟件架構面臨的一個痛點。我們可以合理地得出這樣的結論：API 蔓延將繼續存在，我們必須以一種實際且可擴展的方式來解決這個問題。最終的解決方案要同時解決集群內和集群間的運營復雜性問題。我們姑且使用“集群”一詞表示通過任何軟件架構（從單體到微服務）交付的應用。這些集群可能位于企業內部，也可能橫跨需要連接應用的多個企業。集群內 眾所周知，集群內 API

36、 架構是受限環境。企業有數百甚至數千個獨立、自治的集群（從傳統架構和 Web 2.0 到微服務架構）同時運行。產品和開發團隊會根據當前需求采用某些框架。企業可能會收購或使用采用不同軟件架構的第三方軟件。無論如何，每個團隊都擁有一套自認為不錯的軟件堆棧，并且任何企業都沒有統一的實現標準（參見圖 10：采用多種架構的企業）。但大多數企業正在朝著微服務架構邁進。所以我們來了解一下微服務環境中的集群內架構（圖 17）。PodPodPodPod?PodNGINX Plus Ingress ControllerAPI?API?POD?POD?圖 17：使用 API 和 Ingress Controller

37、 的微服務部署1820API 持續蔓延API 網關19：API 網關用于應用路由、速率限制、安全防護、請求和響應處理及其他應用相關任務。假設您有一個應用，它需要收集多個服務的請求信息。API 網關將用戶請求分發給不同的服務，收集來自所有微服務的響應，并準備發送給用戶的最終響應。雖然 API 網關的作用在微服務環境中的認可度越來越高，但并不是說不能獨立存在于網絡中。Ingress Controller：Ingress Controller 僅僅是一個 API 網關。它原本的主要功能是執行 L7 路由，但到了當今的部署架構中變成了 API 路由，因此我們最終將它稱為 API 網關。API 網關承擔

38、了擴展、安全防護及其他連接相關任務，包括負載均衡、SSL 終止、防火墻、卸載等。二者的不同之處在于 Ingress Controller 是 Kubernetes（K8s）的一個組件，而 API 網關更像是一個獨立的架構解決方案。Sidecar 代理：Service Mesh 已成為最流行的微服務實現方式。通過添加 Service Mesh sidecar 代理，Lyft 的架構師確定了微服務架構的關鍵問題領域20：簡化集群內的連接性、可發現性和安全性。雖然 Service Mesh 經過發展，現已能夠解決 API 發現、連接和安全防護方面的許多挑戰，但 API 蔓延問題實在是太龐大、太分散了

39、。即使對中型企業來說，API 蔓延也是一個嚴峻的問題，無法通過 API 網關、Ingress Controller、sidecar 代理等集群內技術解決。這些為集群內開發的解決方案本身并沒有問題。它們已針對特定目的進行了優化，并得到了廣泛采用。發現、連接和保護集群內 API 的方法不止一種。各個團隊可能也會使用自己選擇的微服務技術，并有充分的理由相信自己選擇的技術能夠更好地實現 API 發現、連接和安全防護。即使企業強制要求，指望他們采用不同的實現方式也是不合理和不切實際的。API 蔓延是一個集群間問題 無論是公共還是私有 API，它們都是在集群間的，所以最好也將 API 蔓延問題的范圍鎖定在

40、集群間。21API 持續蔓延解決方案范圍我們認為解決方案應包含一個專注于解決集群間連接、安全防護和集成挑戰的中間（代理）設備。確定范圍具有幾個優勢。首先，它會在最大程度上減小對架構的破壞，因為它不需要開發人員更改或修改開發環境。其次，簡化了安全防護流程，因為現有的 API 網關可以繼續以當前方式運行。這種方法可以擴展到任意數量的集群，并且不在乎 API 是在本地、云端還是由第三方提供。解決方案要求我們根據 API 蔓延所帶來的問題設定這些要求。提供單一事實來源：解決方案提供一種統一的方法來發現和訪問企業批準使用的所有 API。支持無縫 API 發現：解決方案提供一種發現新 API 的方法。確保

41、正確的版本控制和文檔：解決方案可保持 API 文檔的最新狀態。支持 API 到 API 連接：解決方案可確保即使 API 之間沒有可用的直接路由，也可實現連接。提供大規模安全防護：解決方案可確保 API 安全防護的復雜性不會隨著 API 數量的增長而線性增長。監控 API 可靠性：解決方案可通過在整個部署過程中實施一致、統一的監控來確保 API 可靠性。提供信任即衡量標準：由于 API 和 Webhook 可能遭到濫用，其影響可能遠遠超出了安全性范疇，并有可能撼動使用它的企業的根基。企業應能夠信任其所使用的 API，而不僅僅是身份。uService?A?uService?B?圖 18：集群內與

42、集群間22API 持續蔓延解決方案方法：API 網關 2.0我們需要為解決方案采用全新的方法才能有效解決 API 蔓延問題，并且可能還需要一種新的中間設備。為方便討論，我們將其稱為 API 網關 2.0（AGW 2.0）。這個新的 API 網關需要不斷演變才能應對 API 蔓延帶來的挑戰?！按怼钡难葑儯夯仡櫨W絡中中間設備的發展史，我們會發現兩種基本設備：正向代理和反向代理。正向代理：正向代理（圖 19）充當中介，代表客戶端與移除服務器進行事務處理，從而保護內部應用。VPN 服務器便利用了正向代理的概念，并將加密用作附加功能。如果您想在企業網絡上瀏覽 Netflix，但卻遭到攔截，那么您可以連

43、接到 VPN 服務器，然后將流量轉發到 Netflix。反向代理：反向代理充當來自外部不可信網絡的中介，該網絡不需要知道內部網絡上數據包的確切位置（圖 20）。負載均衡器、防火墻和 API 網關等都是反向代理。在過去的三十年里，我們觀察到，反向代理增加了許多功能層。在過去的十年里，系統設計方法都依賴于通過向反向代理添加會話管理功能來擴展應用。為何需要使用不同的方法：無論是正向代理還是反向代理，都不是為了解決大規模 API 蔓延問題而生的。舉一個簡單的例子，在兩個單獨的網絡中有兩個應用，每個應用前面都有四層防火墻。?/?/?/?圖 19：正向代理圖 20：反向代理23API 持續蔓延如上文所述，

44、這可能適用于某種情況。不同的基礎架構團隊可以通過合作來實現連接。然而，我們有數十億個 API 端點對話等待以安全、可靠的方式連接，因此使用現有解決方案行不通。即使確保簡單的低帶寬和高延遲的可靠連接也幾乎是不可能的。我們需要動態、即時且安全地建立這些連接，同時采用不同的方法來解決這種大規模的復雜性。雙向（又叫 meet-me）代理：我們認為，我們需要一種不同類型的代理。雙向代理并不是一個新的概念，此前就已應用過，但主要用于提供多媒體通信的解決方案（例如，許多會議應用都有一個客戶端，可以向企業外撥號并連接到一個 meet-me 的點）。然而，雙向代理用作企業級應用級別連接和安全防護工具的例子目前還

45、很少見。我們重新引入了雙向或 meet-me 代理。使用 meet-me 的主要前提是所有端點（設備、應用、人員等）都能夠以某種方式將流量路由到該代理。雙向代理具有幾個優勢?；揪W橋：如果所有需要相互通信的設備和應用都可以連接到 meet-me 代理，那么它就可以充當基本網橋。非破壞性：無需安裝在本地網絡，因此網絡團隊無需再學習使用另一種設備來管理雙向代理。?A?B?AA1?2?3?DMZ?BB1?2?3?DMZ?SASE?BeyondCorp?SASE?BeyondCorp圖 21：基本應用間通信的挑戰圖 22：雙向代理24API 持續蔓延可以在任何層上構建：圖 22 只是一個概念。根據需求

46、，系統可以是輕量級或重型裸機設備，而代理可以是連接幾個 API 端點的輕量級容器，也可以是托管設施中的托管網絡連接設備。利用現有技術：對社區來說，最重要的優勢或許是不必發明新技術。這些構建塊是當前就有的，企業可以根據需要構建此類系統。我們認為，meet-me 代理為 API 蔓延問題提供了最優雅、最簡單的解決方案?？偨Y我們正在邁向 API 經濟時代，相信您遲早都會參與到這個時代的發展大潮中來。無論您正處于數字化轉型的哪個階段，API 都是必經之路?；蛟S您現在還不想解決 API 蔓延的問題，但是不能無視它。所有企業都必須認識并了解管理 API 策略的復雜性。企業在試圖解決這個問題并創建洞察戰略時

47、，了解當前如何使用 API 至關重要。產品和工程團隊現在必須要意識到 API 策略即將發生轉變，變得具有足夠的靈活性，能夠幫助消除業務壓力、開展有效競爭及獲得先發優勢。F5 致力于為客戶提供優質服務，是您業務轉型旅途中的重要合作伙伴。我們還致力于與合作伙伴、廠商、標準機構和開源社區組成的生態系統合作，提供強大、可靠及安全的基礎架構支持，賦能全球 API 驅動的新經濟。25API 持續蔓延參考資料1 https:/offers.cloud- 本部分內容參考 https:/ 及其 YouTube 頻道。點擊此處，獲取具體的 API 定義視頻。3 https:/ https:/ https:/fin

48、ancialdataexchange.org/6 https:/ https:/ https:/offers.cloud- https:/ https:/ https:/en.wikipedia.org/wiki/Digital_twin12 https:/ https:/apiacademy.co/2021/06/continuous-monitoring-for-api-reliability/14 https:/ https:/ https:/ https:/ https:/ https:/ 市場銷售熱線：400 991 8366F5 售后支持電話：400 815 5595，010-56

49、43 8123F5 在線聯系：F5 公司北京辦公室地址：北京市朝陽區建國路 81 號華貿中心 1 號寫字樓 21 層 05-09 室郵編：100025電話：（+86）10 5643 8000傳真：（+86）10 5643 8100https:/F5 公司上海辦公室地址：上海市黃浦區湖濱路 222 號企業天地 1 號樓 1119 室郵編：200021電話：（+86）21 6113 2588傳真：（+86）21 6113 2599https:/F5 公司廣州辦公室地址：廣州市天河區珠江新城華夏路 10 號富力中心寫字樓 1108 室郵編：510623電話：（+86）20 3892 7557傳真：（+86）20 3892 7547https:/ 2021 F5,Inc.保留所有權利。F5 和 F5 標識是 F5 公司在美國和其他國家（地區）的商標。其他 F5 商標可在 上予以確認。本文提及的所有其他產品、服務或公司名稱可能是其各自所有者的商標，與 F5 公司并無隸屬關系，F5 公司不做任何明示或暗示的擔保。DC1021|WP-X-PILLAR-737943292F5 社區官方微信活動中心（錄像回放、PPT 下載）、安全報告下載NGINX 開源社區微信F5 社區技術群NGINX 社區微信群