微服務間如何選擇推送和拉取資料

2022-01-26 04:35:18 字數 1099 閱讀 6046

在現在的系統架構中,服務間會大量採用訊息來進行通訊。在訊息系統中,一般有兩種消費模式:生產端推送和消費端拉取。那麼在什麼情況下,我們採用生產端推送,什麼情況下換為消費端拉取呢?今天本篇文章就針對這個話題談談我個人的想法,希望對大家有用。

簡單來說,是由實際業務決定、包括通訊間的雙方系統的技術實現、雙方系統的架構和效能,看日後是否此業務會經常修改等多方面決定的。

資料是動態的且實時性強,宜採用生產端推送

訂單系統有一些訂單資料,**鏈系統需要訂單系統的訂單資料,並做後續處理。例如, 訂單系統的訂單支付完成之後會轉到**鏈系統中做出庫,配送等處理。

我相信絕大多數做**鏈系統的時候,都會決定在訂單系統的訂單付完款之後,把訂單資料推送到**鏈系統中。如果要讓**鏈系統去輪循地查詢訂單系統的訂單資料是否被付款,不僅不能保證發貨的實時性和準確性,而且系統效能上也會有不必要的消耗,**鏈系統還要被迫處理重複訂單的問題。但注意一點的是,如果將推送設計成實時推送也是不合適的,推送成功與否不應是判斷訂單是否成功的條件,**鏈系統與訂單系統並不是強關聯的,正確的做法是訂單付完款的動作後,做推送的動作設計成非同步,通過訊息機制,推送到**鏈系統,**鏈系統在接收到訂單後也會反饋乙個接收成功的訊息給訂單系統,進入發貨流程。

資料有多樣性需求且實時性不強,宜採用消費端拉取

crm系統需要拉取訂單資料展示,crm系統要做乙個報表展示或實時性不強的操作。這種情況就可以設計成系統主動去拉訂單系統的訂單資料,然後根據crm系統的業務維度,分析訂單資料,展示訂單資料。這樣做可減輕訂單系統的壓力。為了提公升效能,可以採取分頁形式來拉取資料,通過佇列分組處理訂單資料,對於重複資料,可以記錄時間戳的形式來解決,時間戳要持久化在crm系統中。

最後我們來總結一下推送和拉取的優缺點。

推送的優點

1. 實時性高。消費者服務能第一時間拿到更新資料。

2. 服務壓力小。相比於拉取模式,每次推送都有資料,避免空輪詢消耗資源。

3. 互動簡單。推送模式中,消費者只需要提供接受資料介面即可,不需要額外的開銷。

推送的缺點

不能確保傳送成功,如果生產端推送失敗,需要生產端維護失敗的推送。

缺乏資料的多樣性,推送的資料的內容格式一致,可能會有比較大的資料冗餘存在,不能根據消費端的不同需求進行變化。

總結

微服務間如何選擇推送和拉取資料

在現在的系統架構中,服務間會大量採用訊息來進行通訊。在訊息系統中,一般有兩種消費模式 生產端推送和消費端拉取。那麼在什麼情況下,我們採用生產端推送,什麼情況下換為消費端拉取呢?今天本篇文章就針對這個話題談談我個人的想法,希望對大家有用。簡單來說,是由實際業務決定 包括通訊間的雙方系統的技術實現 雙方...

微服務間如何選擇推送和拉取資料

在現在的系統架構中,服務間會大量採用訊息來進行通訊。在訊息系統中,一般有兩種消費模式 生產端推送和消費端拉取。那麼在什麼情況下,我們採用生產端推送,什麼情況下換為消費端拉取呢?今天本篇文章就針對這個話題談談我個人的想法,希望對大家有用。簡單來說,是由實際業務決定 包括通訊間的雙方系統的技術實現 雙方...

如何使用REDIS進行微服務間通訊

如何使用redis進行微服務間通訊 盡可能避免service to service通訊。為此,需要在服務之間推乙個訊息佇列。回顧一下微服務的概念 小型的,非常集中的程序彼此獨立執行並且易於維護,輕鬆的溝通,簡單的水平擴充套件,能夠在不影響平台其餘部分的情況下工作和更改單個服務。redis提供了生產 ...