在系統開發初期，很容易出現這樣一種情況：不同業務線上開發人員，因為技術棧和版本時間的影響，在選型的時候會優先使用自己熟悉的，例如MQ中間件常用的：Kafka、Rocket、Rabbit等，
在系統開發初期，很容易出現這樣一種情況：不同業務線上開發人員，因為技術棧和版本時間的影響，在選型的時候會優先使用自己熟悉的，例如MQ中間件常用的：Kafka、Rocket、Rabbit等，這樣很容易忽略各個項目之間的元件差異問題；
在系統開發中後期，業務相對穩定之後，通常都會對資源占用較高的子產品逐漸重構，公共服務進行整合管理，進而使系統更具有整體性，在這個過程中，解決不同項目的中間件差異通常首當其沖，例如常見的緩存中心，MQ消息管理等；
這種情況一般來說很難避免，系統初期為了快速支撐業務，埋下很多坑點，一旦業務可以穩定發展，并且可持續性得到驗證，就會開始适當考慮逐漸進行子產品重構，降低成本。
2.1 初期問題
在某創業公司研發初期，業務線上存在五個項目并行開發的情況，當時對于MQ的使用狀況如下：
Rocket：核心業務3個項目，版本有差異；
Kafka：資料權重偏高，1個項目采用；
Redis：基于Python連接配接，隊列消息模式；
剛開始因為用的不多，整體還在可控範圍内，後續随着業務的持續疊代，項目間出現需要通信的情況，就開始混亂難以維護，然後就是被迫開始重構，統一消息元件。
2.2 二次選型
基于業務的綜合考量，對現有幾個項目進行MQ重新設計，形成的整體架構思路如下：
MQ元件選擇：采用RocketMQ；
換掉Redis元件的隊列模式；
将基于Python的系統改Java語言；
提供消息生産與消費兩個服務；
MQ的功能由上述服務進行統一維護；
這裡在核心業務線上沒有改變元件選擇，換掉kafka的一個原因是涉及大量結算業務，Redis隊列模式棄用，基于Python的管理系統功能不多，這裡隻是順手換掉，統一業務線的程式設計語言。這樣設計之後，從整體思路上看就會合理很多。
3.1 整體思路
涉及核心角色說明，從左向右依次：
生産用戶端：需要請求服務端通信的節點，調用生産服務端封裝的消息發送接口即可；
生産服務端：封裝消息發送API，并維護路由管理，權限識别等，消息落地存儲等；
消息存儲層：主要基于消息中間件進行存儲，資料庫層面用來處理特定情況下的二次排程；
消費服務端：封裝消息接收API，并根據路由辨別，請求指定的消費端接口，完成通信；
消費用戶端：響應消費服務端的請求，封裝消費時具體的業務邏輯；
在整體的技術難度上沒有太多差别，但是引入兩個服務【生産和消費】，用來管理MQ通信流程，适配特定的業務邏輯，引入資料庫做一次落地存儲，在異常流程的處理上更加靈活，這樣整個消息子產品具有很強的可擴充性。
3.2 細節描述
元件選型
消息中間件的選擇是比較多的，但是鑒于業務線上開發人員的熟悉程度，以及參考多方提供的測試對比報告，最終确定選用RocketMQ元件，同時RocketMQ相關特點：高性能、高可靠性，以及對分布式事務的支援，也是核心的考慮因素。
微服務架構
基于目前微服務的架構模式，把MQ功能本身內建在兩個核心服務中，進行統一管理和疊代，以及元件的版本控制，對于所有生産的消息，進行全局路由控制，以及特定情況下的，通過應用服務層面功能設計，實作消息延時消費，以及失敗消息的二次排程執行，和部分單條消息的手動觸發。
資料存儲
對消息實體進行二次存儲，主要還是适配部分特定的功能點，有些消息可以延時處理，例如當MQ隊列出現堆積的時候，或者達到監控的預警線時，可以通過配置手段，幹預一部分消息隻存儲入庫，不推送MQ，等待服務相對空閑的時候再去發送。
消息中間件作為系統間解耦的穩定支撐，在服務層面管理時，需要具備清晰的設計路線，以及流程關鍵節點的監控和記錄，確定整個鍊路的穩定和容錯。
同系列：分布式概念 | 分布式事務 | Kafka叢集 | RocketMQ元件 | Redis叢集
閱讀标簽
【Java基礎】【設計模式】【結構與算法】【Linux系統】【資料庫】
【分布式架構】【微服務】【大資料元件】【SpringBoot進階】【Spring&Boot基礎】
【資料分析】【技術導圖】【 職場】