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