在現在的系統架構中，服務間會大量採用訊息來進行通訊。在訊息系統中，一般有兩種消費模式：生產端推送和消費端拉取。那麼在什麼情況下，我們採用生產端推送，什麼情況下換為消費端拉取呢？今天本篇文章就針對這個話題談談我個人的想法，希望對大家有用。
簡單來說，是由實際業務決定、包括通訊間的雙方系統的技術實現、雙方系統的架構和效能，看日後是否此業務會經常修改等多方面決定的。
資料是動態的且實時性強，宜採用生產端推送
訂單系統有一些訂單資料，供應鏈系統需要訂單系統的訂單資料，並做後續處理。例如， 訂單系統的訂單支付完成之後會轉到供應鏈系統中做出庫，配送等處理。
我相信絕大多數做供應鏈系統的時候，都會決定在訂單系統的訂單付完款之後，把訂單資料推送到供應鏈系統中。如果要讓供應鏈系統去輪循地查詢訂單系統的訂單資料是否被付款，不僅不能保證發貨的實時性和準確性，而且系統效能上也會有不必要的消耗，供應鏈系統還要被迫處理重複訂單的問題。但注意一點的是，如果將推送設計成實時推送也是不合適的，推送成功與否不應是判斷訂單是否成功的條件，供應鏈系統與訂單系統並不是強關聯的，正確的做法是訂單付完款的動作後，做推送的動作設計成非同步，通過訊息機制，推送到供應鏈系統，供應鏈系統在接收到訂單後也會反饋一個接收成功的訊息給訂單系統，進入發貨流程。
資料有多樣性需求且實時性不強，宜採用消費端拉取
CRM系統需要拉取訂單資料展示，CRM系統要做一個報表展示或實時性不強的操作。這種情況就可以設計成系統主動去拉訂單系統的訂單資料，然後根據CRM系統的業務維度，分析訂單資料，展示訂單資料。這樣做可減輕訂單系統的壓力。為了提升效能，可以採取分頁形式來拉取資料，通過佇列分組處理訂單資料，對於重複資料，可以記錄時間戳的形式來解決，時間戳要持久化在CRM系統中。
最後我們來總結一下推送和拉取的優缺點。
推送的優點
1. 實時性高。消費者服務能第一時間拿到更新資料。
2. 服務壓力小。相比於拉取模式，每次推送都有資料，避免空輪詢消耗資源。
3. 互動簡單。推送模式中，消費者只需要提供接受資料介面即可，不需要額外的開銷。
推送的缺點
-
不能確保傳送成功，如果生產端推送失敗，需要生產端維護失敗的推送。
-
缺乏資料的多樣性，推送的資料的內容格式一致，可能會有比較大的資料冗餘存在，不能根據消費端的不同需求進行變化。
總結
前面簡單總結了一些推送和拉取的適用場景和區別。實際工作中，服務之間的互動是會採用混合式的，例如，“先推後拉”，“先拉後推”等等，在不同的業務場景下，服務間的互動方式會做對應的調整。大家也可以談談你工作中採用的服務互動方法，歡迎留言。
掃描二維碼或手動搜尋微信公眾號： ForestNotes
歡迎轉載，帶上以下二維碼即可
