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

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

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

資料是動态的且實時性強，宜采用生産端推送

訂單系統有一些訂單資料，供應鍊系統需要訂單系統的訂單資料，并做後續處理。例如， 訂單系統的訂單支付完成之後會轉到供應鍊系統中做出庫，配送等處理。

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

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

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

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

推送的優點

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

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

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

推送的缺點

不能確定發送成功，如果生産端推送失敗，需要生産端維護失敗的推送。

缺乏資料的多樣性，推送的資料的内容格式一緻，可能會有比較大的資料備援存在，不能根據消費端的不同需求進行變化。

總結

前面簡單總結了一些推送和拉取的适用場景和差別。實際工作中，服務之間的互動是會采用混合式的，

例如，“先推後拉”，“先拉後推”等等，在不同的業務場景下，服務間的互動方式會做對應的調整。

大家也可以談談你工作中采用的服務互動方法，歡迎留言。