Dubbo、Zookeeper、Redis、RabbitMQ的示例分析

這篇文章將為大家詳細講解有關(guān)Dubbo、Zookeeper、Redis、RabbitMQ的示例分析，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

一、主要負責微信商城訂單模塊的開發(fā)

訂單的邏輯：訂單創(chuàng)建、訂單支付、訂單生產(chǎn)、訂單確認、訂單完成、取消訂單等訂單流程。還涉及到復雜的訂單狀態(tài)規(guī)則、訂單金額計算規(guī)則以及增減庫存規(guī)則等。

這個過程需要各個數(shù)據(jù), 因此，訂單系統(tǒng)接入所需的公共服務模塊接口，在訂單系統(tǒng)即可完成對接公共系統(tǒng)的服務。(自己在這個過程中做了什么？那些流程是自己做的？)

二、以前一個項目有多個類，一旦其中一個類出了問題，就會導致整個服務宕機，現(xiàn)在把一個項目拆分成多個微服務（生產(chǎn)者和消費者）（也就是表現(xiàn)層和服務層？） 就像兩個單獨的計算機，大家都知道兩個單獨的計算機不提供任何外界條件如網(wǎng)絡環(huán)境，這兩臺計算機是無法同信的，那么回歸到項目中，表現(xiàn)層和服務層兩個單獨的工程是如何通信的呢？實現(xiàn)遠程通信的方法有：使用dubbo：使用RPC協(xié)議進行遠程調(diào)用，直接使用socket通信。傳輸效率高，并且可以統(tǒng)計出系統(tǒng)之間的調(diào)用關(guān)系、調(diào)用次數(shù) ，來解決這個宕機問題，從而使用Dubbo來管理這些微服務。

2. 解耦合。如果使用 MQ，A 系統(tǒng)產(chǎn)生一條數(shù)據(jù)，發(fā)送到 MQ 里面去，哪個系統(tǒng)需要數(shù)據(jù)自己去 MQ 里面消費。如果新系統(tǒng)需要數(shù)據(jù)，直接從 MQ 里消費即可；如果某個系統(tǒng)不需要這條數(shù)據(jù)了，就取消對 MQ 消息的消費即可。這樣下來，A 系統(tǒng)壓根兒不需要去考慮要給誰發(fā)送數(shù)據(jù)，不需要維護這個代碼，也不需要考慮人家是否調(diào)用成功、失敗超時等情況。

A 系統(tǒng)就跟其它系統(tǒng)徹底解耦了。

3.異步

以前同步的話，要分別等待ABCD分別執(zhí)行完任務才響應給用戶，這個過程需要3+300+450+200ms,而現(xiàn)在，則只需3+5秒即可。無需等待它們。

關(guān)于“Dubbo、Zookeeper、Redis、RabbitMQ的示例分析”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。