Supergraph：API編排和組合的解決方案
在本系列的上一篇文章中，我們討論了在企業數據環境中構建和使用 API 的復雜性。這些環境涉及由不同團隊管理的多個數據域和眾多應用程序，由于資源受限和目標沖突，導致挑戰。
譯自Supergraph: A Solution for API Orchestration and Composition，作者 Sandip Devarkonda。
Supergraph 架構框架 (SAF)，源于我們在聯邦數據訪問和 GraphQL 聯邦方面的經驗，通過提出構建域 API（子圖）和數據訪問 API 平臺（ SUPERGRAPH ）的策略來解決這些挑戰。
該框架提供了一個團隊協作的操作模型，充當具有 API 生產者和消費者的 API 市場。它簡化了 API 生產者的加入，為消費者提供高質量的 SUPERGRAPH API，并強調具有過濾、排序和分頁等功能的高質量域 API。
SAF 為聯邦域所有權的操作模型和系統設計奠定了基礎。在企業數據和 API 環境中，這有助于解決聯邦數據訪問的挑戰，并使 API 編排和 API 組合等用例更容易解決。
API 編排
API 編排涉及管理多個 API 調用，并對請求和結果進行排序以執行復雜的任務或工作流。在我們的參考上下文中，API 編排的示例可能涉及以下順序：
- 餐廳 API: 檢查菜單和可用性。
- 支付 API: 處理付款。
- 配送 API: 安排配送。
編排層按順序處理這些步驟，確保每個步驟在移至下一步之前成功完成，并將它們的響應組合成一個單一的、連貫的用戶結果。
圖片
API 編排的挑戰
編排主要由 API 消費者根據最終用戶需求驅動。它具有挑戰性，因為它通常跨越多個域。使用傳統方法進行編排需要與聚合相同的“粘合”代碼/端點——只是在這種情況下，這種粘合更復雜，正如我們從示例中看到的那樣。編排通常還涉及多個變異，這進一步加劇了挑戰。
我們再次遇到了所有權的挑戰：消費者團隊是否應該擁有編排代碼？該團隊是否具備構建高性能編排端點所需的技能？這些都是需要解決的操作挑戰，以便在域 API/數據之上構建強大的編排層。
解決 API 編排挑戰
一個好的 API 平臺必須提供語義來定義可能與業務邏輯函數交織在一起的復雜工作流。類似于 SUPERGRAPH 架構允許域 CRUD API 和業務邏輯之間建立關系的方式，API 調用的響應可以鏈接到可以獨立運行的函數（甚至可以從 SUPERGRAPH 調用其他 CRUD API）或反之亦然。
這種能力的基礎是，來自任何來源（數據庫、API 等）的每條數據和業務邏輯代碼中的類型都在 SUPERGRAPH 的語義層上標準化。這使 SUPERGRAPH 能夠為開發人員（包括 API 消費者）提供語義，以便他們僅使用聲明性配置來表達工作流。
與 Camunda、Orkus、Temporal 等第三方編排軟件的集成使開發人員的體驗更加無縫。閱讀有關API 編排的更多信息。
問題 | 解決方案 |
新的工作流需要新的編排端點。 | SUPERGRAPH 要求 API 消費者能夠使用聲明性配置自助服務對新工作流的需求。 |
編寫工作流需要后端系統工程知識。 | SUPERGRAPH 配置是聲明性的，這使構建可擴展工作流的能力民主化。 |
API 組合
API 組合可以被認為是 API 集成和編排的特殊情況（或演變），它指的是將多個 API 響應組合成單個統一響應的技術，該響應包含來自不同調用的分層信息。換句話說，組合以一種連貫的方式從不同的來源獲取相關數據——因此，對于讀取操作來說，它是聚合和編排。API 組合的一個例子是以下關于我們食品配送應用程序用戶的示例數據：
- 用戶的過去訂單。
- 對于每個訂單，獲取有關放置訂單的餐廳的一些信息。
- 對于每個訂單，獲取支付信息。
獲取這些信息涉及按順序向三個不同的域發出請求，在每一步使用上一步的響應，最后將整個結果集組合成一個單一的層次化響應，該響應表示三個實體（訂單、餐廳和支付）之間的關系。
API 組合面臨的挑戰以及如何解決
Supergraph(QL) 架構主張了解底層來源或域，并在異構來源集中進行標準化。這使得 supergraph 可以提供 API 組合自助服務模型，而無需任何自定義開發，方法是提供以下兩種功能：
- 連接: 從 A 獲取數據，并從 B 獲取相關數據。
- 嵌套過濾器: 從 A 獲取數據，并根據其相關數據 B 的屬性值進行過濾。
問題 | 解決方案 |
每個數據組合排列都需要一個組合端點。 | supergraph 通過跨來源數據的聲明式關系定義來自動執行組合。如果可以從程序上推斷出來自同一來源的關系，則 supergraph 可以自動執行此操作。 |
創作工作流需要了解后端系統工程。 | supergraph 配置是聲明式的，這使得工程師能夠輕松地構建可擴展的工作流。 |
閱讀更多關于API 組合的內容。
結論：實踐者的 API 平臺設計清單
基于之前關于 Supergraph 架構框架的帖子，我們可以為任何尋求解決 API 集成、聚合、組合和編排挑戰的 API 平臺（稱為 supergraph）設計編制以下綜合清單。
指南 | 描述 |
1. 集成 | 使 API 消費者能夠輕松地將 API 集成到其服務中 |
1.1 多種 API 格式 | supergraph 平臺是否可以自動提供除 GraphQL 之外的輸出格式，例如 REST/OpenAPI？這是為了滿足多個消費者的集成需求。 |
1.2 文檔 | supergraph 平臺是否可以幫助域或平臺所有者維護 API 文檔？如果底層域（數據庫、代碼或 API）已經過文檔化，那么這些文檔是否會自動被 supergraph 平臺獲取？ |
1.3 標準化 | supergraph 平臺是否提供或強制執行標準化的域 API 設計（分頁、過濾、排序等）？ |
2. 聚合 | 使 API 消費者能夠輕松地將多個 API 調用聚合/批處理到一個調用中 |
2.1 關系 | supergraph 是否提供了一種在任何兩個實體或端點之間創建關系的方法，而無需域所有者進行更改？ |
2.2 可組合性 | 鑒于 supergraph 中兩個實體之間的關系，supergraph 提供了多少個“連接”功能？ |
3. 編排 | 使 supergraph 利益相關者能夠輕松地創作自定義 API 編排 |
3.1 聯合變異/解耦編排業務邏輯 | supergraph 是否提供了一種在底層域內或跨底層域創作編排流程的方法？ |
衡量平臺設計滿足這些標準的有效性以及構建這些功能所需的時間和精力投入，將為任何架構師提供一個明確的指標，表明其平臺計劃的成功可能性。
