高效開發 你的專案有介面聚合服務嗎?

2022-07-04 00:12:10 字數 2297 閱讀 5766

服務拆分之後,前後端同學之間關於 api 粒度的爭吵越來越常見:

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

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

介面聚合服務是什麼?

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

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

方案 a

方案 b

呼叫者客戶端

客戶端api-server

自研graphql

payload

約定graphql

response

約定graphql

容錯約定

約定動態選取欄位是是

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

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

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

apidefinition 不僅定義了介面的元資訊,同時也描述了介面所需引數的**。

直接由客戶端傳遞過來,即直接從 httprequest 中獲取引數。

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

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

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

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

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

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。

Spring聚合多個服務的介面資料

有時我們在專案中需要聚合多個介面成乙個介面給前端提供資料.使用並行會提公升效能.在spring 中提供的 async 可以非同步執行.getmachinetodayinfo licenseid gettodaysummarytimeperiod licenseid completablefuture...

專案開發 介面開發API文件 常用的註解

data 類註解,作用於實體類的setter和getter的生成,屬於lombok外掛程式中的註解,如果該字段被final修飾,則不會生成setter方法 apimodel 類註解,作用於介面文件的實體類的描述 apimodelproperty 屬性註解,用於方法,字段 表示對model屬性的說明或...

教你開發乙個高效的伺服器

cpp typedef struct server st server t typedef struct task queue st task queue t typedef struct conn st conn t 伺服器結構 struct server st 任務佇列結構 struct tas...