微服務間如何選擇推送和拉取數據

在如今的系統架構中，服務間會大量採用消息來進行通訊。在消息系統中，通常有兩種消費模式：生產端推送和消費端拉取。那麼在什麼狀況下，咱們採用生產端推送，什麼狀況下換爲消費端拉取呢？今天本篇文章就針對這個話題談談我我的的想法，但願對你們有用。

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

數據是動態的且實時性強，宜採用生產端推送

訂單系統有一些訂單數據，供應鏈系統須要訂單系統的訂單數據，並作後續處理。例如， 訂單系統的訂單支付完成以後會轉到供應鏈系統中作出庫，配送等處理。

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

數據有多樣性需求且實時性不強，宜採用消費端拉取

CRM系統須要拉取訂單數據展現，CRM系統要作一個報表展現或實時性不強的操做。這種狀況就能夠設計成系統主動去拉訂單系統的訂單數據，而後根據CRM系統的業務維度，分析訂單數據，展現訂單數據。這樣作可減輕訂單系統的壓力。爲了提高性能，能夠採起分頁形式來拉取數據，經過隊列分組處理訂單數據，對於重複數據，能夠記錄時間戳的形式來解決，時間戳要持久化在CRM系統中。

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

推送的優勢

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

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

3. 交互簡單。推送模式中，消費者只須要提供接受數據接口便可，不須要額外的開銷。

推送的缺點

1. 不能確保發送成功，若是生產端推送失敗，須要生產端維護失敗的推送。

2. 缺少數據的多樣性，推送的數據的內容格式一致，可能會有比較大的數據冗餘存在，不能根據消費端的不一樣需求進行變化。

總結

前面簡單總結了一些推送和拉取的適用場景和區別。實際工做中，服務之間的交互是會採用混合式的，例如，「先推後拉」，「先拉後推」等等，在不一樣的業務場景下，服務間的交互方式會作對應的調整。你們也能夠談談你工做中採用的服務交互方法，歡迎留言。

掃描二維碼或手動搜索微信公衆號： ForestNotes

歡迎轉載，帶上如下二維碼便可