您好,登錄后才能下訂單哦!
這篇文章將為大家詳細講解有關Dubbo、Zookeeper、Redis、RabbitMQ的示例分析,小編覺得挺實用的,因此分享給大家做個參考,希望大家閱讀完這篇文章后可以有所收獲。
一、主要負責微信商城訂單模塊的開發
訂單的邏輯:訂單創建、訂單支付、訂單生產、訂單確認、訂單完成、取消訂單等訂單流程。還涉及到復雜的訂單狀態規則、訂單金額計算規則以及增減庫存規則等。
這個過程需要各個數據, 因此,訂單系統接入所需的公共服務模塊接口,在訂單系統即可完成對接公共系統的服務。(自己在這個過程中做了什么?那些流程是自己做的?)
二、以前一個項目有多個類,一旦其中一個類出了問題,就會導致整個服務宕機,現在把一個項目拆分成多個微服務(生產者和消費者)(也就是表現層和服務層?) 就像兩個單獨的計算機,大家都知道兩個單獨的計算機不提供任何外界條件如網絡環境,這兩臺計算機是無法同信的,那么回歸到項目中,表現層和服務層兩個單獨的工程是如何通信的呢?實現遠程通信的方法有:使用dubbo:使用RPC協議進行遠程調用,直接使用socket通信。傳輸效率高,并且可以統計出系統之間的調用關系、調用次數 ,來解決這個宕機問題,從而使用Dubbo來管理這些微服務。
2. 解耦合。如果使用 MQ,A 系統產生一條數據,發送到 MQ 里面去,哪個系統需要數據自己去 MQ 里面消費。如果新系統需要數據,直接從 MQ 里消費即可;如果某個系統不需要這條數據了,就取消對 MQ 消息的消費即可。這樣下來,A 系統壓根兒不需要去考慮要給誰發送數據,不需要維護這個代碼,也不需要考慮人家是否調用成功、失敗超時等情況。
A 系統就跟其它系統徹底解耦了。
3.異步
以前同步的話,要分別等待ABCD分別執行完任務才響應給用戶,這個過程需要3+300+450+200ms,而現在,則只需3+5秒即可。無需等待它們。
關于“Dubbo、Zookeeper、Redis、RabbitMQ的示例分析”這篇文章就分享到這里了,希望以上內容可以對大家有一定的幫助,使各位可以學到更多知識,如果覺得文章不錯,請把它分享出去讓更多的人看到。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。