雲原生下的機遇和挑戰
時至今日，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】公衆号，與衆多開源愛好者共同成長～