一、背景簡(jiǎn)介

在系統(tǒng)開(kāi)發(fā)初期，很容易出現(xiàn)這樣一種情況：不同業(yè)務(wù)線上開(kāi)發(fā)人員，因?yàn)榧夹g(shù)棧和版本時(shí)間的影響，在選型的時(shí)候會(huì)優(yōu)先使用自己熟悉的，例如MQ中間件常用的：Kafka、Rocket、Rabbit等，這樣很容易忽略各個(gè)項(xiàng)目之間的組件差異問(wèn)題；

在系統(tǒng)開(kāi)發(fā)中后期，業(yè)務(wù)相對(duì)穩(wěn)定之后，通常都會(huì)對(duì)資源占用較高的模塊逐步重構(gòu)，公共服務(wù)進(jìn)行整合管理，從而使系統(tǒng)更具有整體性，在這個(gè)過(guò)程中，解決不同項(xiàng)目的中間件差異通常首當(dāng)其沖，例如常見(jiàn)的緩存中心，MQ消息管理等；

這種情況一般來(lái)說(shuō)很難避免，系統(tǒng)初期為了快速支撐業(yè)務(wù)，埋下很多坑點(diǎn)，一旦業(yè)務(wù)可以穩(wěn)定發(fā)展，并且可持續(xù)性得到驗(yàn)證，就會(huì)開(kāi)始適當(dāng)考慮逐步進(jìn)行模塊重構(gòu)，降低成本。

二、重構(gòu)思路

2.1 初期問(wèn)題

在某創(chuàng)業(yè)公司研發(fā)初期，業(yè)務(wù)線上存在五個(gè)項(xiàng)目并行開(kāi)發(fā)的情況，當(dāng)時(shí)對(duì)于MQ的使用狀況如下：

• Rocket：核心業(yè)務(wù)3個(gè)項(xiàng)目，版本有差異；
• Kafka：數(shù)據(jù)權(quán)重偏高，1個(gè)項(xiàng)目采用；
• Redis：基于Python連接，隊(duì)列消息模式；

剛開(kāi)始因?yàn)橛玫牟欢?#xff0c;整體還在可控范圍內(nèi)，后續(xù)隨著業(yè)務(wù)的持續(xù)迭代，項(xiàng)目間出現(xiàn)需要通信的情況，就開(kāi)始混亂難以維護(hù)，然后就是被迫開(kāi)始重構(gòu)，統(tǒng)一消息組件。

2.2 二次選型

基于業(yè)務(wù)的綜合考量，對(duì)現(xiàn)有幾個(gè)項(xiàng)目進(jìn)行MQ重新設(shè)計(jì)，形成的整體架構(gòu)思路如下：

• MQ組件選擇：采用RocketMQ；
• 換掉Redis組件的隊(duì)列模式；
• 將基于Python的系統(tǒng)改Java語(yǔ)言；
• 提供消息生產(chǎn)與消費(fèi)兩個(gè)服務(wù)；
• MQ的功能由上述服務(wù)進(jìn)行統(tǒng)一維護(hù)；

這里在核心業(yè)務(wù)線上沒(méi)有改變組件選擇，換掉kafka的一個(gè)原因是涉及大量結(jié)算業(yè)務(wù)，Redis隊(duì)列模式棄用，基于Python的管理系統(tǒng)功能不多，這里只是順手換掉，統(tǒng)一業(yè)務(wù)線的編程語(yǔ)言。這樣設(shè)計(jì)之后，從整體思路上看就會(huì)合理很多。

三、改造過(guò)程

3.1 整體思路

涉及核心角色說(shuō)明，從左向右依次：

• 生產(chǎn)客戶端：需要請(qǐng)求服務(wù)端通信的節(jié)點(diǎn)，調(diào)用生產(chǎn)服務(wù)端封裝的消息發(fā)送接口即可；
• 生產(chǎn)服務(wù)端：封裝消息發(fā)送API，并維護(hù)路由管理，權(quán)限識(shí)別等，消息落地存儲(chǔ)等；
• 消息存儲(chǔ)層：主要基于消息中間件進(jìn)行存儲(chǔ)，數(shù)據(jù)庫(kù)層面用來(lái)處理特定情況下的二次調(diào)度；
• 消費(fèi)服務(wù)端：封裝消息接收API，并根據(jù)路由標(biāo)識(shí)，請(qǐng)求指定的消費(fèi)端接口，完成通信；
• 消費(fèi)客戶端：響應(yīng)消費(fèi)服務(wù)端的請(qǐng)求，封裝消費(fèi)時(shí)具體的業(yè)務(wù)邏輯；

在整體的技術(shù)難度上沒(méi)有太多差別，但是引入兩個(gè)服務(wù)【生產(chǎn)和消費(fèi)】，用來(lái)管理MQ通信流程，適配特定的業(yè)務(wù)邏輯，引入數(shù)據(jù)庫(kù)做一次落地存儲(chǔ)，在異常流程的處理上更加靈活，這樣整個(gè)消息模塊具有很強(qiáng)的可擴(kuò)展性。

3.2 細(xì)節(jié)描述

• 組件選型

消息中間件的選擇是比較多的，但是鑒于業(yè)務(wù)線上開(kāi)發(fā)人員的熟悉程度，以及參考多方提供的測(cè)試對(duì)比報(bào)告，最終確定選用RocketMQ組件，同時(shí)RocketMQ相關(guān)特點(diǎn)：高性能、高可靠性，以及對(duì)分布式事務(wù)的支持，也是核心的考慮因素。

• 微服務(wù)架構(gòu)

基于當(dāng)前微服務(wù)的架構(gòu)模式，把MQ功能本身集成在兩個(gè)核心服務(wù)中，進(jìn)行統(tǒng)一管理和迭代，以及組件的版本控制，對(duì)于所有生產(chǎn)的消息，進(jìn)行全局路由控制，以及特定情況下的，通過(guò)應(yīng)用服務(wù)層面功能設(shè)計(jì)，實(shí)現(xiàn)消息延時(shí)消費(fèi)，以及失敗消息的二次調(diào)度執(zhí)行，和部分單條消息的手動(dòng)觸發(fā)。

• 數(shù)據(jù)存儲(chǔ)

對(duì)消息實(shí)體進(jìn)行二次存儲(chǔ)，主要還是適配部分特定的功能點(diǎn)，有些消息可以延時(shí)處理，例如當(dāng)MQ隊(duì)列出現(xiàn)堆積的時(shí)候，或者達(dá)到監(jiān)控的預(yù)警線時(shí)，可以通過(guò)配置手段，干預(yù)一部分消息只存儲(chǔ)入庫(kù)，不推送MQ，等待服務(wù)相對(duì)空閑的時(shí)候再去發(fā)送。

消息中間件作為系統(tǒng)間解耦的穩(wěn)定支撐，在服務(wù)層面管理時(shí)，需要具備清晰的設(shè)計(jì)路線，以及流程關(guān)鍵節(jié)點(diǎn)的監(jiān)控和記錄，確保整個(gè)鏈路的穩(wěn)定和容錯(cuò)。

四、源代碼地址

GitEE·地址 https://gitee.com/cicadasmile Wiki·地址 https://gitee.com/cicadasmile/butte-java-note/wikis

總結(jié)

以上是生活随笔為你收集整理的分布式服务下，消息中间件改造的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。