本文首發於個人微信公眾號：coder小黑

服務拆分的痛

服務拆分之後，前後端同學之間關於 API 粒度的爭吵越來越常見：

「前端同學請求兩個介面，聚合一下資料不就行了？」後端同學想只提供業務領域基礎 API 服務能力，資料組裝處理則希望由前端同學完成。

「後端聚合一下，前端可以少一次請求，只負責頁面渲染！」前端同學希望只負責頁面渲染，而 H5、APP、小程式同一個聚合邏輯可能會出現在三端，後端聚合則只需要一次。

介面聚合服務就是我們的一個解決思路。

介面聚合服務是什麼？

介面聚合服務就是一個搬運工，只是幫助前端同學聚合多個介面的返回資料，聚合之後一次性返回相應請求的結果給客戶端。我們希望通過介面聚合服務這個中間層，做到可以讓前端直接獲取資料，而後端也能繼續專心於提供基礎業務領域 API 服務能力。

場景分析

• 場景一：序列獲取資料。多個請求，有關聯關係。
  • 例如：通過商品 ID 獲取評論資訊，通過評論中的 uid 獲取使用者資訊
• 場景二：並行獲取資料。多個請求，無關聯關係。
  • 例如：通過商品 ID 獲取商品資訊、獲取商品活動資訊、獲取當前使用者已購資訊

方案調研

	方案 A	方案 B
呼叫者	客戶端	客戶端
API-Server	自研	GraphQL
Payload	約定	GraphQL
Response	約定	GraphQL
容錯	約定	約定
動態選取欄位	是	是

最終我們選擇了方案 A，通過自研一套簡單的介面聚合中間層來解決這個問題。

於是，就有了介面聚合服務：api-aggregator。該框架有如下幾個特點:

• 核心程式碼在千行左右，輕量級實現。

• 對現有程式碼無侵入性，無需對現有服務和程式碼做改造適配，現有介面可直接使用。
• 提供了 ApiAggregatePostProcessor 拓展點來干預介面聚合的各個階段，可拓展性強。
• 對前端友好，前端同學可以自定義返回資料結構，支援欄位動態選取。

• 介面聚合邏輯直接通過配置檔案和 api-aggregator 交流，新增聚合介面，無需釋出。

api-aggregator：介面聚合服務

api-aggregator 認為一個聚合介面應該是由若干個介面的返回結果聚合而成的，因此在設計時，我們將其被劃分為兩個部分：介面元資訊和介面之間的聚合邏輯。

ApiDefinition：介面元資訊

ApiDefinition 不僅定義了介面的元資訊，同時也描述了介面所需引數的來源。

api-aggregator 認為在一次介面聚合中，元資訊介面的引數可能有以下一些來源：

1. 直接由客戶端傳遞過來，即直接從 HttpRequest 中獲取引數。
2. 從上個介面的返回值中獲取。例如：通過商品 ID 獲取評論資訊，通過評論中的 uid 獲取使用者資訊。此時 uid 引數就需要從上個介面的返回值中獲取。

ResponseDefinition：介面間聚合邏輯

ResponseDefinition 描述了介面間的聚合邏輯，通過 ResponseDefinition 前端同學可以自定義介面返回的資料結構，也可以動態選取所需欄位。

如果沒有 ResponseDefinition，則 api-aggregator 只能簡單的將兩個介面的資料平級的聚合在一起（如上左圖所示）。而現在，可以通過 ResponseDefinition 來定義返回結構體，給前端同學更好的開發體驗（如上右圖所示）。

簡單聊聊設計

配置檔案預載入

介面聚合配置資訊是由前端開發同學在管理後臺配置的。

前端同學在提交配置檔案之後，api-aggregator 就會對配置檔案做一些靜態分析：分析介面的依賴情況，是否存在迴圈依賴等問題。

為了提高效能，api-aggregator 將相關的配置資訊解析好之後，會直接快取在記憶體中，以減少對同一份配置檔案的反覆解析，同時，再通過定時重新整理和 MQ 的 pub/sub 來保證資料的一致性。

簡化 http 請求模型

api-aggregator 抽象了 HttpMethodInvoker 來發起 HTTP 請求。通過 Supplier 來獲取返回結果，遮蔽了不同 Http Client 之間的 API 差異。

還記得前文提到的場景嗎？

場景一：序列獲取資料。多個請求，有關聯關係。

場景二：並行獲取資料。多個請求，無關聯關係。

在 api-aggregator 中，將這兩個場景進行了簡化合一。

首先， api-aggregator 在解析配置檔案分析介面依賴時，會根據介面的依賴情況給出一個 api-aggregator 認為是最優的 HTTP 請求流程，而不是根據配置檔案定義的介面順序依次請求。

舉個例子：

假設在一次介面聚合中，需要請求介面 A、B、C，而介面 B 的資料依賴於介面 A，介面 A 和介面 C 的請求引數均可直接從 HttpRequest 中獲取引數。

那麼，在實際的介面聚合過程中，api-aggregator 會先請求介面 A 和介面 C，然後阻塞獲取介面 A 的返回結果，最後請求介面 B。

提供擴充套件點

api-aggregator 提供了 ApiAggregatePostProcessor 來方便後續擴充套件。

通過 ApiAggregatePostProcessor，api-aggregator 可以干預一個介面聚合的整個流程，例如：快取介面資訊、增加監控日誌等等。

雖然通過 ApiAggregatePostProcessor 可以來干預介面的聚合流程，但是想要新增新的 Processor 時還是需要重啟api-aggregator。而 api-aggregator 作為介面聚合點，和閘道器相似，也是流量的集中點，在後續的版本中，可能會考慮引入 Groovy 指令碼，來支援動態的開啟和停用 Processor。

最後，歡迎大家在評論區一起留言討論，感謝你的閱讀~~

---

歡迎關注個人公眾號：

相關推薦