透過 OpenAPI 克服微服務與 Kubernetes 的挑戰。API 為現代組織提供動力
透過 OpenAPI 克服微服務與 Kubernetes 的挑戰
API 為現代組織提供動力。
為了滿足當今科技消費者的數位需求，API 優先的開發策略正在增加。為什麼？因為組織必須快速應對市場變化。為了變得更敏捷，許多組織已轉向更易於使用的架構方法。
微服務架構是一種開發軟體的方法，專注於具有明確定義介面的單一功能模組，支援敏捷和分散的工作流程，以交付較小的可用功能。
同時，基於容器的技術正在被廣泛採用來部署和託管微服務。Kubernetes，這個容器編排系統，是處理微服務管理、擴展和部署的熱門選擇。
但採用這些模式和技術並不能保證 API 策略成功。要在交付一致品質的同時實現足夠的規模並不容易。甚至投資可能需要時間才能見效 – 請參考 SoundCloud 使用 絞殺者模式從單體架構 遷移的八年旅程。
話雖如此，讓我們來看看一些讓您處於最佳位置來掌控命運的方面。
API、微服務、Kubernetes 的挑戰
API 交付的零散方法會導致 API 混亂並癱瘓數位發展。
許多組織的常見問題是充斥著未記錄的 API 來支援系統整合。這會導致 API 品質不一致、開發人員體驗不佳以及潛在的安全問題。
Kubernetes 控制 API 的蔓延，但帶來了自身的挑戰。Kubernetes Ingress 的宣告性質意味著它是配置驅動的。Ingress 規格描述了這些配置，但該規格缺乏在生產環境中自信地公開 API 所需的許多功能。為了克服限制，Kubernetes 環境中的許多控制器都有自己指定功能配置選項的方法。
由於這些挑戰，組織難以提供最佳的開發人員體驗、維持 API 品質以及控制 Kubernetes 配置的一致性。某些挑戰是由於交付流程中的工作流程競爭以及團隊結構造成的。例如，Ingress 控制器的操作配置通常由維運人員執行，而 API 的功能演進則由開發人員完成。協調開銷可能會導致瓶頸或生產問題。
使用 OpenAPI 進行設計優先的功能與操作一致性
採用 設計優先的方法可以改善您的 API 程式。透過包含服務的功能和操作層面，並利用 OpenAPI 規格，團隊可以在以品質為中心的協作 API 工作流程中從設計到部署取得進展。
在深入探討此方法的好處之前，讓我們先探討其術語。
什麼是 OpenAPI？
OpenAPI 規格 (OAS)，以前稱為 Swagger 規格，定義了基於 HTTP 的 API 的標準、與語言無關的介面。OAS 允許人類和電腦在無需存取原始程式碼、文件或網路流量檢查的情況下了解服務的功能。
像 OpenAPI 這樣的 API 規格不僅僅是記錄 API 的外觀。消費者可以用最少的實作邏輯來理解和與遠端服務互動。API 提供者方面也是如此，因為利害關係人可以更有效地溝通任何服務提供的價值主張。
圖 1 – OpenAPI 驅動 API 生命周期
使用 API 定義可以幫助自動化 API 生命週期的許多環節，包括客戶端和伺服器程式碼產生、模擬 API 的實作、測試自動化以及講述 API 的故事。這種自動化潛力減少了 API 生產者和消費者雙方 DevOps 週期中的浪費。
API 和微服務 – 有什麼不同？
這些術語經常交替使用，但它們並不相同。
API 代表應用程式介面。API 是服務、功能或資料的介面。可程式化介面促進軟體應用程式和組件之間的連接和通訊，同時隱藏實作細節。API 是軟體的語言。
微服務是關於實作的。微服務架構是一種實作模式，可促進交付獨立的組件。這些組件可以獨立更新和演進。API 可以存在而無需微服務！大多數組織沒有從頭開始的奢侈，因此他們的 API 策略包括從單體到微服務的 API 交付方法演進。
圖 2 – 從單體到微服務的典型演進方法
微服務是 API 數量增加的主要催化劑。
什麼是 Kubernetes？
Kubernetes，也稱為 K8s，是一個可移植、可擴展且開源的平台，用於管理容器化工作流程和服務。它使用「Pod」和「標籤」的概念，將組成應用程式的容器分組為邏輯單元，以便於管理和探索。
圖 3 – Kubernetes 架構（灰色為容器，彩色為 Pod），© Google Inc
Kubernetes 由 Google 開發，並將其捐贈給雲原生運算基金會 (CNCF)。
什麼是 API 閘道？
API 閘道是作為 API 管理策略一部分使用的組件。它充當 API 資產的前門。閘道攔截客戶端和 API 之間的請求和回應流量，並執行許多常見活動。確切的功能各不相同，但路由、映射、速率限制、身份驗證、轉換、驗證、分析和計費都是可能的。
什麼是 Ingress 和 Ingress 控制器？
通常，服務和 Pod 具有只能由內部叢集網路路由的 IP。最終到達邊緣路由器的所有流量都會被丟棄或轉發到其他地方。
Kubernetes Ingress 是一個 API 物件，描述了傳入流量（通常是 HTTP 或 HTTPS）進入在 Kubernetes 叢集中執行的服務的外部存取路由規則。建立 Ingress 的目的是為了讓外部客戶端（駐留在叢集外部）可以透過穩定且可外部定址的 URL 輕鬆存取叢集中的應用程式。
圖 4 – 簡單 Ingress – ©Kubernetes.io
Ingress 控制器提供實際的 Ingress 實作，並且需要一個正在運行的控制器才能使 Ingress 資源正常運作。Ingress 控制器是 Pod，就像叢集中的任何其他應用程式一樣，並且可以看到其他 Pod。控制器可以檢查傳入的請求，並執行 Ingress 清單中指定的某些規則履行，例如路由。Ingress 控制器類似於 API 閘道。
雲端使 API 標準變得必要 – 且棘手
產業研究顯示，標準化、治理和安全性是重要的挑戰。隨著雲原生環境的採用，在保證整體開發者體驗的同時，維持分散式組織架構的監督，對於API產品的運作層面實施標準化與功能要素同等重要。它可以帶來卓越的開發者體驗，同時維持分散式組織架構的監督。
SmartBear 最近與我們在 Kubeshop 的朋友們合作，展示如何結合 SwaggerHub 和 Kusk 來推廣 API 的單一事實來源。
SwaggerHub 最擅長實現快速、協作和標準化的 API 設計。它使得符合 OpenAPI 和您組織的自訂規則（或風格指南）變得簡單直觀。結合 SwaggerHub 和來自 Kubeshop 的 x-kusk 擴展，團隊可以針對在 Kubernetes 中運行的 API 的操作和管理存取，擁有單一的事實來源。
x-kusk 擴展支援直接使用 OpenAPI 定義宣告 API 的各種運行時規格，以與所選叢集技術無關的統一方式進行。
可以使用定義直接指定以下內容
- 逾時/重試
- CORS
- 停用路徑/操作（例如，在外部公開之前隱藏管理路徑）
- 模擬
- 驗證
- 叢集特定的屬性
圖 5 – OpenAPI 的 kusk 擴展範例
透過使用相同的 SwaggerHub API 編輯器，團隊可以在熟悉的工具內設定 Ingress 路由和其他操作細節。此外，SwaggerHub 允許您在設計期間對操作設定應用標準化，並為驗證、模擬和路由級別設定等功能奠定基礎。
當 API 準備好發佈到 Kusk 閘道時，團隊知道運行時設定將與早期階段驗證的設定一致。
典型的 SwaggerHub 和 Kusk 閘道工作流程是
- 與所有相關的利害關係人協作在 SwaggerHub 中設計您的 API
- 使用 SwaggerHub 標準強制執行，以確保 x-kusk 擴展已正確就位
- 使用 SwaggerHub GitHub 整合來同步/推送您已驗證的定義（至 GitHub）
- 使用 CI/CD 自動化將 API 定義部署至 Kusk 閘道，並確保實作到位
- 從行動/網路/第三方應用程式發佈和使用您的 API
採用 API 標準以確保整個組織的一致性
隨著 API 在軟體世界中被廣泛使用，以及微服務征服了單體式應用程式，保持對您的 API 和微服務資產的功能和運作方面的控制從未如此重要。
免費親身體驗：試用 SwaggerHub，讓您的標準到位，並啟動敏捷策略。
為何需要 API 標準？組織效益
- 功能和運作方面的集中表示 (事實來源)
- 整個團隊（業務、開發、測試人員、安全性、營運）的協同設計
- 微服務的由外而內方法 – 關注消費者體驗和一致性
- 標準化和治理 – 確保整個組織的可探索性和一致性；在週期早期驗證/斷言運作方面的能力
- 採用迭代開發 – 支援從設計到部署的自動化工作流程；減少瓶頸
瞭解更多
- 隨選網路研討會 – Kubeshop 技術長暨前 OpenAPI 主席 Ole Lensmar，以及 SmartBear API 技術推廣專員 Frank Kilcommins，探討使用微服務和 Kubernetes 擴展 API 程式的挑戰，以及 OpenAPI 在平息混亂方面可以發揮的作用。
- 逐步說明 Kubeshop 團隊的部落格 – 使用您選擇的 Kubernetes 叢集，從設計優先到使用 SwaggerHub、Kusk 和 OpenAPI 自動化部署 API。