為什么我們說云原生時代，企業數字化轉型更需要做好 API 全生命周期管理？

云原生下的機遇和挑戰

時至今日，Kubernetes 已至成熟期，云原生時代則剛剛開始。雖說云原生不只是圍繞著 Kubernetes 生態，但無可質疑，Kubernetes 已是云原生生態的基石。通過規范 API 和 CRD 標準，Kubernetes 已經建立起了一個云原生 PaaS 生態帝國，成為了 PaaS 領域的事實標準。

這一層事實標準，對企業交付有著巨大的意義。在 Kubernetes 生態出現之前，類比于土木工程，連螺絲、螺帽這樣的東西都缺少統一的標準，而甲方企業如果只關注上層業務功能，很容易把萬丈高臺架構于浮沙之上，導致業務的傾覆。不夸張的說，在企業交付領域，真是“天不生 Kubernetes，萬古如長夜”。

以 API 管理中的 API 路由功能為例，如果不使用 Kubernetes，企業可能會選擇 F5/Nginx/HAProxy/Zuul 等各式網關軟件，做對應的路由配置。有的軟件提供了控制臺 UI，有的可能是人肉腳本運維，缺乏標準，運維技能也無法沉淀，關鍵人員離職可能會帶來災難。Kubernetes 把 API 路由的能力抽象為了 Ingress 資源，定義了標準，屏蔽了底層軟件細節，通過 CNCF CKA 認證的人員都會具備 API 路由運維的能力。在 API 管理的領域，除了 API 路由，還有 API 流量治理策略，API 開放鑒權，以及調用量觀測審計等環節，Kubernetes 以及 Istio 等生態都給出了一些標準定義，雖然其中很多尚未成熟，但標準和生態的未來已經愈發清晰。

API 全生命周期管理是什么

API 全生命周期管理（Full Life Cycle API Management）是指對 API 從規劃、設計到實施、測試、發布、運行、調用直至版本變更與退出的整個周期的管理。

一般來說，API 全生命周期可以分為三個層面和六個階段。

三個方面是指：設計，實施，管理，如下圖所示：

Mulesoft 對 API 管理三個層面的圖示

六個階段是指：規劃與設計階段、開發階段、測試階段、部署與運行時階段、運維監控階段、版本管理與棄用階段。

用以支持 API 全生命周期管理的工具應當具備以下能力：

API 集市，用于 API 提供者發布文檔展示應用程序的服務能力，API 的使用者查閱服務接口進而開發客戶端。

API 網關和訪問管理工具，用于 runtime 管理、訪問管理、安全管理、數據收集等。

監控管理工具，用于監控 API 相關指標。

接口測試工具，用于測試接口。

API 設計工具，用于設計和編寫 API 文檔。

近年來谷歌收購 Apigee、Red Hat 收購 3scale 等事件無一不在證明 API 生命周期管理越來越被業界所重視。

從2020 Ganter API 全生命周期管理“魔力象限”可以看到Google、Mulesoft、Microsoft、IBM、Kong 等眾多熟悉的身影出現在了領導者第一象限；Amazon Web Services、TIBCO Software、Broadcom 等也緊隨其后。

Magic Quadrant for Full Life Cycle API Management by gartner.com

API 生命周期不同階段解讀

API 管理的核心是需要服務 API 的整個生命周期并啟用關聯的生態系統。API-First 方法將 API 視為產品并對其進行管理，強調整個生命周期的重要性。通過精心設計、管理和維護的 API 可為開發人員提供良好體驗，為組織帶來價值。

API 全生命周期管理設計的產物是 API 文檔，實施的產物是 API 的服務實例，它們都是被管理對象。下面我們將針對 API 生命周期管理的不同階段進行詳細解讀。

規劃與設計階段

規劃與設計階段要規劃應用程序功能，設計 API，編寫、評審以及發布 API 文檔。

當開始規劃應用程序新的功能點時，就要著手構思應用程序要呈現怎樣的 API。API 涉及哪些資源、哪些操作、什么樣的權限、什么樣的場景等等，都是這個階段的思考重點。設計 API 時需要充分考慮，如接口易用性、實現難度、價值等。如果不在此階段思慮充分，就會設計出不可靠的 API，以至于開發出“腐爛”的代碼和不可靠的功能，為組織帶來風險。

設計階段共有四個主要任務：

設計：確定業務流程和需求，對資源合行為進行抽象。

建模：API 資源建模，API 操作與方法建模，請求/響應有效負載/代碼建模等。

反饋：開發人員間互相反饋，完善設計稿。

驗證：根據開發人員的反饋適當修改 API 設計，繼續驗證。

API 設計的目標是產生一份 API 協議，一般是一份具有可讀性的 API 文檔。這種先行設計 API 的方法被稱為“API-First”。

API-First 是 DevOps 實踐中發展出來的，在項目開發中致力于開發出一致可重用的 API 方法論。顧名思義，API-First 就是 API 先行，在計劃開發應用程序時，先設計應用程序接口，然后實現接口功能。與之相對的是 Code-First，即先實現應用程序功能，然后在此基礎上根據外部需求抽象出接口。

相較于 Code-First，API-First 更加敏捷。API-First 的思路使得功能易于解耦，更加適合微服務拆分；API-First 通過接口發布功能，小巧輕快，能提高迭代速率；通過文檔協調開發者間協作，可以提升開發效率；通過版本化的 API 持續集成，符合 DevOps 的精神內核。

開發階段

開發階段要實現規劃與設計的全部接口，實現應用程序全部新功能。

開發階段是產品功能從無到有的核心階段，應用程序開發人員根據完善的 API 設計文檔進行并行開發，以節約開發時間，提高開發效率。設計合理、表述清晰、風格統一、高一致性的 API 能令開發人員如沐春風，縮短學習時間，降低學習成本。

利用 API 管理工具，可以根據 API 文檔生成服務端和客戶端代碼，多語言甚至框架級別的代碼生成能力，能節約開發人員的編碼成本；還可以生成接口測試代碼和腳本，使得開發人員不必專門編寫接口測試代碼或者只需花少量的時間修改即可完成接口測試編寫工作。

基于 API 文檔的 mocking service 能很好地協調服務端和客戶端開發人員的協作，當服務端 API 功能還未實現時，客戶端開發人員可以利用 mocking service 調試開發，待服務端開發人員將階段性成果部署到開發環境時，只需修改下客戶端軟件服務域名就可以聯調。API 文檔支持可編程 mocking，只需在文檔中配置不同參數，就可以模擬不同場景下的接口響應，比如通過配置響應碼模擬是否登錄，通過配置 User-Agent 模擬不同來源的客戶端等。

測試階段

測試階段要對已實現的接口進行充分測試，驗證接口功能是否按預期實現，它要求接口可用、準確、穩定、可靠（也有人將開發和測試作為一個階段，因為開發測試總是交織在一起的）。

API 開發完成之后，要經過幾輪 API 測試以確保其正常運行。如果測試順利完成，則可以繼續進行下一個生命周期階段，但大多數情況下，API 會經歷幾輪測試和調整，然后再進行部署。API 全生命周期管理要求 API 測試自動化，因此不能僅僅依賴接口測試腳本、桌面接口測試工具來做接口測試，集成到持續交付和部署的 DevOps 流程中的自動化測試工具在這里至關重要。

以往的許多 API 管理工具，將 API 生命周期各個階段割裂開來。就開發階段與測試階段而言，接口測試往往面臨許多痛點，比如：

重復定義的問題：在 API 設計階段，就已經設計過 API 接口，在測試階段，又將接口要素重新編寫一遍，從 URI 到各種參數，全要重新填寫一遍。

編排接口能力不足的問題，一些傳統的接口測試工具雖然能測試單個接口，但卻將接口孤立的看待，沒有將接口有機編排起來，難以串聯成一個個完整的場景。

所以，必須將 API 生命周期的各個階段有機地聯系起來。用戶在編寫測試用例時，直接引用文檔里的接口，就避免了重復定義的問題；在設計 API 時充分周全地建模，會讓編排就變得十分自然。

部署與運行時階段

運行時階段要將實現了特定 API 的應用部署到相應的環境，使 API 作為服務實例正式向外提供服務。

運行時階段，可以從 API 角度對實例進行訪問管理，授權客戶端對實例進行訪問，并限制它們的訪問流量。還可以決定哪些接口可以被訪問、哪些接口不可以被訪問。每一個 API 的價值都值得單獨考量，從商業運營角度看：

流量：可以給初級用戶開放少量流量，給重要用戶開放大量流量。

接口：給初級開放初級接口，給重要用戶開放高級接口。

運維監控階段

運維監控階段要維護和監控實例的運行狀態，對 API 的調用量、錯誤分布、響應時間、流量大小等維度進行監控。通過對接口的運維監控，可以調整實例的服務質量，如流量大小、訪問限制等，還可以分析接口壓力，調整服務資源。

版本管理與棄用階段

版本管理是指添加新版 API、刪除舊的 API、為版本標記語義化版本號等工作。棄用是指將某版本的 API 標記為棄用。由于服務的迭代更新，原來的 API 不再適應需求時，須需要進行版本管理或棄用。API 的訂閱者收到版本變化的消息后，可以重新決定如何使用該系列接口。

API 全生命周期管理最佳實踐

Erda 作為新一代企業級云原生 PaaS 平臺，一直堅定地走在這條道路上，為企業提供符合標準并且值得信賴的 API 管理產品。Erda API 管理產品形態如圖所示，是一個以 API 集市為中心的，包含 API 設計、API 訪問管理等貫穿 API 全生命周期的產品矩陣。

API 管理產品構成

API 設計中心

Erda Cloud API 設計中心基于可視化的編輯方式，通過直觀而友好的交互界面，用戶無需了解任何 REST API 規范標準，也無需具備任何關于 API 描述語言的知識，就可以輕松編寫出一份具有專業水平的 API 文檔。同時采用 OpenAPI 3.0 協議標準，任何時候都可以交付、遷出文檔，一次設計，隨處使用；在其他平臺托管的 API 文檔、代碼中生成的 Swagger 文件等，也都能輕松遷移上來。

Erda API 設計中心將 API 文檔托管到代碼倉庫中，這一設計使得接口描述和接口實現代碼關聯在一起。開發人員進入代碼倉庫，選擇對應的代碼分支，維護接口文檔，可以很好地保持文檔和新開發功能的同步。這樣的理念遵循了 GitOps 配置即代碼的思想。

文檔托管到倉庫中，還意味著可以基于分支進行文檔協作。不同用戶編寫同一篇文檔時，只要從源分支切出新的分支，在新的分支上編輯文檔，然后再進行分支的合并。同一服務不同接口的負責人，隨時可以設計自己負責的接口，又隨時合并回去，不會相互影響和阻塞。

API 集市

API 集市使用了語義化版本機制來實現 API 文檔的版本管理。版本號格式形如 major.minor.patch ，其中：

major 為主版本號，主版本號的變化通常表示發生了重大變更或不向下兼容的變更。

minor 是次版本號，次版本號的變化通常表示增加了新特性，仍向下兼容。

patch 是修訂號，修訂號的變化通常表示對現有版本作較小的、局部的修正。

除了語義化版本號外，還有一個稱為“版本名稱”的版本標記，它一般是有自解釋性的單詞或短語，表示當前文檔版本的命名。版本名稱與語義化版本號中的 major 是唯一對應的，版本名稱可以視作是主版本號 major 的別名。這樣版本化管理的好處是，將 API 文檔的增長與應用程序的增長一視同仁，可以從 API 的角度審視應用程序的功能。版本號解釋了服務更迭間的兼容性和依賴關系，不管是所有者還是使用者，都能根據版本號語義清晰地了解服務的變更情況。

API 資源可以關聯到 Erda Cloud 上具體的服務實例地址。通過這樣的關聯，API 提供方可以進一步實現 API 的訪問管理，調用方也就可以在 API 集市中申請調用并測試接口。

訪問管理

API 提供者在集市中將 API 資源與 Erda Cloud 上具體的服務實例地址關聯之后，再為 API 資源創建訪問管理，調用者就可以在 API 集市中申請調用該 API；提供者收到調用申請后進行審批，為客戶端設置 SLA 配額；獲批的客戶端獲得訪問資質，就可以從外部訪問接口了。此后，調用方還可以在訪問管理中切換 API 版本，將請求轉發到不同版本對應的服務實例上，從而在客戶不感知的情況下進行 API 版本的升級或回滾。

API 訪問管理的功能都是基于 Erda 云原生網關產品的能力實現的，相比直接使用網關的配置能力，使用 API 訪問管理簡化了很多 —— 用戶僅僅跟 API 打交道。

基于 Erda Cloud 的 API 管理產品，企業可以實現 API 全生命周期管理的最佳實踐。如下圖所示，可以分別從 API 的提供者和調用方兩個視角來看待API 管理這件事：

API 所有者（左）和使用者（右）的視角看 API 管理

從 API 提供者的視角來看：首先需要跟隨服務功能變更，及時更新 API 設計中心的文檔，因為文檔也基于代碼倉庫管理，可以通過 Code Review 的方式確保 API 文檔的及時同步。在開發聯調階段，API 提供者可以將 API 文檔發布到集市，依賴此接口的其他模塊功能就可以并行開發。如果有 API 對外開放的需求，API 提供者就為對應的 API 資源設置訪問管理功能，在訪問管理控制臺可以實時觀測外部的調用流量。

從 API 調用方的視角來看：如果是測試工程師，應該基于開發人員提供的 API 文檔，進行自動化接口測試用例的設計，而不是維護一份測試專用的接口文檔。如果是外部集成方，通過 API 集市去發現所需的功能接口，申請調用成功后，應該在 API 集市進行簡單的接口訪問測試，確認功能符合預期；然后根據 API 文檔進行集成模塊的代碼編寫、部署；最后可以在 “我的訪問” 中查看調用流量。

軟件在自己的生命周期里不斷迭代變化，API 也是一樣。無論 API 提供者還是調用方，都要重視 API 迭代的影響。提供方要嚴格遵循 API 集市的語義化版本機制，當出現 Breaking Change 時，應該為新的 Major 版本創建獨立的訪問管理入口，并將舊版本標記棄用，引導調用方使用新的版本；調用方應該及時關注訂閱通知，了解所使用 API 文檔的最新版本情況。

Erda Cloud 的 DevOps 功能提供了云原生場景下 CI/CD 能力，應該把 API 管理也視作 CI/CD 的一部分。可以使用 Erda Cloud 的自動化測試平臺，對接 API 集市，在 CI 流程中加入自動化接口測試；可以使用 Erda 的流水線擴展，在 CD 流程后自動發布 API 版本，并自動關聯上服務的 Kubernetes Service 地址。

Erda Cloud 基于云原生為企業系統架構提供了一站式 PaaS 服務，Erda Cloud 的 API 管理亦是在云原生的土壤上自然生長出的產品。API 全生命周期管理作為企業數字化的關鍵一環，企業如果采用云原生的架構，一定要選擇與之契合的 API 管理產品，否則可能導致適配成本的增加和管理效率的低下。

更多技術干貨請關注 【爾達 Erda】公眾號，與眾多開源愛好者共同成長～

API Kubernetes 云原生 企業數字化

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。