各位看官,天熱了,先來個小風扇涼快一下,哈哈~
一、前情回顧
之前給大家聊了一下,面試時如果遇到消息中間件這個話題,面試官上來可能問的兩個問題:
-
你們的系統架構中爲什麼要引入消息中間件?
-
系統架構中引入消息中間件有什麼缺點?
關於這兩個問題的回答,可以參見之前的兩篇文章:
在問完這兩個問題之後,不同風格的面試官可能會展開不同的發問。
針對那種工作年限比較長的資深的同學,可能會開始就候選人所在公司使用的消息中間件,深入裏面的技術細節,比如讓你聊聊RocketMQ的架構原理和核心源碼?
但是另外一種面試風格,會先從你們的項目和業務入手進行考察,比如像下面這樣:
-
消息中間件在你們生產項目裏具體是哪個業務場景下落地的?
-
這個業務場景有什麼技術挑戰?
-
爲什麼必須要在這個業務場景裏用消息中間件技術?
-
具體使用消息中間件的時候是怎麼來用的?
好!這篇文章,咱們從第二種風格來聊聊。
二、業務場景介紹
我們會落地到某個具體業務系統的某個場景下,看看如何使用消息中間件,然後其效果是什麼。
業務場景的話,咱們就用大家都很熟悉的電商業務爲例,這裏爲了便於理解,對其做了一定的抽象和簡化。
大家還是來考慮一個下訂單的業務流程,比如你下個訂單,此時需要幹幾件事情:
-
更新訂單狀態爲“待發貨”(耗時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的技術來做一下異步化,提升核心流程的性能。
這樣未來在跳槽面試的時候,纔可以做到遊刃有餘,有自己的一套東西可以說。
個人觀後總結
文章來源:石杉的架構筆記(id:shishan100)