聊聊消息中間件在你們的項目業務里是如何落地的？

業務場景介紹

這篇文章，我們通過落地到某個具體業務系統的某個場景，看看如何使用消息中間件，然後其效果是什麼。

業務場景的話，咱們就用大家都很熟悉的電商業務為例，這裡為了便於理解，對其做了一定的抽象和簡化。

還是來考慮一個下訂單的業務流程，比如你下個訂單，此時需要干幾件事情：

更新訂單狀態為「待發貨」(耗時20ms)

扣減商品庫存(耗時100ms)

增加會員積分(耗時80ms)

附贈優惠券(耗時50ms)

倉儲調度發貨(耗時幾十秒)

說明一下：上述環節，為了便於大家理解，做了簡化。實際真正複雜的電商系統里，整體環節和業務流程會比這個複雜很多倍，而且耗時也絕對不是上面那麼簡單的。

我們還是通過一張手繪圖，來看看這整個的業務流程：

如上圖，這個下訂單的業務流程中：

更新訂單狀態(20ms) 扣減商品庫存(100ms) 增加會員積分(80ms) 附贈優惠券(50ms) = 250ms。

也就是說，僅僅是這4個流程的話，也就200多毫秒的耗時。

200多毫秒的耗時，對用戶下單體驗來說是非常快速的，幾乎就是一瞬間就完成了，不會感到過多的停頓，也就是一下子就可以看到自己下單成功了。

但是，如果加上那個調度倉儲發貨呢?

那個環節需要讀取大量的數據、使用多倉庫/多貨位的調度演算法、還要跟C/S架構的倉儲系統進行網路通信，因此我們這裡假設這個環節可能會耗時數十秒。

一旦加上那個調度倉儲發貨的環節到這個下單流程里，就可能導致用戶要等頁面卡頓幾十秒後才會看到下單成功的提示，這個用戶體驗就相當的差了。

對於這種場景，完全適合使用消息中間件來進行非同步化調用。

也就是說，訂單服務對倉儲調度發貨，僅僅是發送一個消息到MQ里，然後倉儲服務消費消息之後再慢慢的執行調度演算法，然後分配商品發貨任務給對應的倉庫即可。

這樣的話，就可以把耗時幾十秒的倉儲調度發貨的環節，從下單流程里摘除出去了。進而保證下單流程就僅僅是耗時200多毫秒而已。

至於那個耗時幾十秒的倉儲調度發貨環節，我們通過非同步的方式慢慢執行即可，不會影響用戶下單的體驗。

以上過程，如下圖所示：

初步落地

好!接下來我們就假設大家在實際生產中還沒用過消息中間件，咱們從0開始，看看如何落地?

對於已經在生產中使用過消息中間件的小夥伴，不妨也看看，權當複習，溫故知新!

我們以RabbitMQ為例，假如你用的消息中間件是RabbitMQ，那麼我們對這個消息中間件應該如何安裝和部署呢?

很簡單，RabbitMQ的官方文檔里提供了非常詳細的安裝部署步驟，你可以在自己的筆記本電腦本地安裝，也可以在公司的伺服器上部署。

現在假設你已經參考了官方文檔並安裝完成，那麼接下來在代碼層面應該怎麼來引入RabbitMQ以及在系統里實現收發消息呢?

下面通過一些HelloWorld級別的代碼和一些簡單的示例圖，給大家演示一下RabbitMQ是如何收發消息的。

對於很多在實際生產中使用過MQ的同學，這些代碼可能對實際生產中使用過MQ的同學，顯得太簡單了。

不過考慮到很多初學者可能連用都沒有用過MQ，甚至是才聽說消息中間件不久，所以筆者認為這些demo代碼以及手工繪圖，還是很有必要。

好!看完了代碼，這時我們可以通過一張圖來想像一下兩個服務之間的通信。

訂單服務你可以啟動多個，不同的訂單服務都可以往一個RabbitMQ的queue里推送消息。

倉儲服務你也可以啟動多個，多個倉儲服務會採用round-robin的輪詢演算法，每個服務實例都可以從RabbitMQ queue里消費到一部分的消息。

上面的圖裡，訂單服務在MQ專業術語中叫做「生產者」，英文是「Producer」，意思就是這個服務是專門負責生產消息投遞到MQ的。

倉儲服務在MQ專業術語中叫做「消費者」，英文是「Consumer」，意思就是這個服務專門是負責從MQ消費消息然後處理的。

這個時候，這套非同步通信的架構就可以跑起來了。

好了，到目前為止，雖然這個代碼還存在不少問題，但是沒關係，大體上我們已經給一些不太熟悉MQ技術的同學，從一個比較形象的簡化後的電商業務場景出發，通過HelloWorld級別的示例代碼和手工繪圖，將MQ這個技術落地跑起來了。

更進一步，各位同學完全可以參照這個文章里的案例，思考一下：自己負責的項目里，有沒有類似的業務場景可以使用MQ的?

然後想辦法在自己的項目里落地使用MQ的技術來做一下非同步化，提升核心流程的性能。

這樣未來在跳槽面試的時候，才可以做到遊刃有餘，有自己的一套東西可以說。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！