請求響應模型/同步/異步/事件驅動

我有要求我將不得不作爲中間件系統，上游系統打電話給他，我會打電話給第三方系統與一些額外的插件。一旦我向第三方系統提交請求，他們會給我一個id作爲響應。我將不得不使用此ID再次調用以獲取我的請求的狀態，一旦我的請求狀態更改爲完成，我將不得不調用一個更多的服務來獲取我的請求的詳細信息。一旦我得到響應只有然後我將不得不添加一些額外的信息，併發送到上游系統的細節。請求響應模型/同步/異步/事件驅動

對於這個場景哪種模式會更好請求/響應（同步）異步調用事件驅動機理

我的系統和第三方系統之間的流量是固定的那部分不能改變。上游系統將通過ESB調用我的服務。我打算使用RestFul，請讓我知道你的inpusts在這個。

來源

2016-04-05 sumedha

您可以簡單地使用相同的方案，爲您的中間件系統使用第三方系統：

一旦我請求提交到第三方系統，他們給我一個ID爲效應初探。我將不得不使用這個號碼，撥打另一個電話，讓我的請求的狀態，一旦我的請求狀態更改爲狀態說做

所以，你的中間件應在每個上游返回中間件的requestId請求。
上游可以檢查此中間件請求的請求狀態Id
當請求狀態更改爲done上游可以得到響應。

我創建這個序列圖來證明這個簡單的Upstream，MiddleWare和Thirdparty系統的相互作用：

來源

2016-04-08 13:02:57

哪種模式，我應該遵循rquest /響應或異步調用 – sumedha

你應該同時使用:) 'upstream'會向你的'middleware'發送請求，但'middleware'不能同步處理這個請求（由於'thirdparty'系統行爲），所以它會返回request_id到'upstream'和'upstream'，稍後會問你的'中間件'關於請求狀態以及何時完成得到適當的響應。這是異步請求/響應模式 –

請求響應模型/同步/異步/事件驅動

回答

相關問題