內(nèi)容回顧 | 不寫代碼，分享兩個解決方案……

最近，確實有點太忙了，昨天回到家都已經(jīng)十點了，所以一直也沒有時間搞事情。

然后這兩天在寫新需求的時候，發(fā)現(xiàn)公司系統(tǒng)架構(gòu)方面有一些比較好的解決思路，今天我們把思路梳理下分享出來，主要是針對消息中心的一套解決方案；同時空閑時間，也看了一些限流方面的解決方案，今天我們就利用中午時間和大家分享下這兩個技術(shù)方案。

先看第一個技術(shù)方案，消息中心。

消息中心

消息中心一般就是用來給各個平臺發(fā)送消息的，應(yīng)用規(guī)模小的時候，平臺單一的時候（比如只有釘釘或者企業(yè)微信一個平臺），我們可以直接在應(yīng)用中嵌入Jms組件，實現(xiàn)消息發(fā)送、異步業(yè)務(wù)處理等業(yè)務(wù)需求。

但是隨著系統(tǒng)規(guī)模的擴展，以及平臺的擴張，我們可能需要同時給多個平臺發(fā)送各類消息（需要同時支持釘釘、企業(yè)微信、飛書等），處理各類業(yè)務(wù)需求，這時候單一的Jms組件已經(jīng)無法滿足我們的需求，而且從架構(gòu)上來說，所有服務(wù)都封裝在一個系統(tǒng)中，耦合性高，不利于擴展。

這時候，把消息發(fā)送處理單獨封裝成一個獨立應(yīng)用就顯得特別重要，而且后期獨立的消息系統(tǒng)可以對接各種各樣的系統(tǒng)和平臺。

我們需要做的僅僅是定義一個主消息隊列，封裝一個通用的消息體，然后定義一個主消息隊列的業(yè)務(wù)處理類，在這個類中我們做統(tǒng)一的消息保存、消息分發(fā)等操作。

看起來有點復(fù)雜，但是實際系統(tǒng)架構(gòu)應(yīng)該要比這個復(fù)雜的多。

簡單介紹下，上面這張架構(gòu)圖中，消息中心收到主消息隊列的消息后，會保存消息內(nèi)容，同時會根據(jù)不同的消息類型，把它轉(zhuǎn)發(fā)到對應(yīng)的子隊列中，然后由對應(yīng)的子隊列的消費者處理相關(guān)消息或交易。以上就是消息中心的構(gòu)建思路，具體實現(xiàn)，我們今天就不展示了，改天我抽時間做一個demo分享下。

限流組件

關(guān)于限流組件，我查了一些資料，其中的解決思路大致是這樣的：先構(gòu)建一個token池，池子的大小就是我們限流大小，每收到一個請求，將一個token發(fā)給這個請求，知道token全部發(fā)送完。這種解決方案，主要應(yīng)用在秒殺、搶購等應(yīng)用場景中，可以有效防止超庫存下單等情況。

感覺這種場景在我們?nèi)粘Ｉ钪幸彩呛艹Ｒ姷?，比如博物館發(fā)送免費門票，然后游客憑票參觀，這就是典型的限流。

如果訪問請求沒有token或者token無效，則相關(guān)請求不予以處理。一般我們用redis來創(chuàng)建token池。

這里我們同樣只分享思路，具體實現(xiàn)后面再分享。

好了，今天這兩種解決方案的分享就到這里吧！另外最近我剛剛好在做釘釘、企業(yè)微信創(chuàng)建個人日程的需求，等忙過這一陣，我想把這一塊的內(nèi)容也分享下，供大家參考，讓大家少走彎路。好了，今天的內(nèi)容就到這里吧。