?中間件是什么

首先，一個擁有信息化建設積累的公司內部可能同時運行著多個不同的業務系統，而這些系統可能基于不同操作系統，不同存儲數據的數據庫等，若需要將這些信息系統可以結合成一個協同工作的整體，實現企業跨平臺、分布式應用，就需要一個中介者完成這個使命，而中間件便是天選之子，它處于操作系統和應用程序之間，它是脫離了具體的設計目標，而具備提供普遍獨立功能需求的模塊(可替換)，屏蔽了底層操作系統的復雜性，使得開發人員面對簡單而統一的開發環境，將注意力放在業務的實現上。中間件的使用不僅是對于開發而言更加簡便，也降低了后續的系統維護成本。常用的中間件包括負載均衡中間件(Nginx、CDN)，分布式消息中間件(RabbitMQ、Kafka),緩存中間件(MemCache、Redis),緩存中間件(Mycat、ShardingJdbc),等

注意：項目架構和重構中國，需要謹慎思考和斟酌，因為任何技術的融入和變化都會增加相應成本，建議初創公司或者業務比較單一等先選擇單體架構即可，后續隨著業務或者項目不斷驅動再加入對應的技術

消息中間件是什么

在理解消息中間件是什么之前，我們先普及一下單體架構和分布式架構區別；

單體架構

公司開發初期架構中，基本都采取的是單體架構模式，他的特點就是把所有業務和模塊代碼放在一個工程下。單體架構本質就是我們發起一個請求，由JVM分配線程并調用需要使用的服務串行處理響應。引發的問題就是：我們升級其中一個模塊或者迭代都需要整個項目重新編譯和重新發布。這種架構存在的問題包括：代碼耦合度太高，運維成本高，不利于升級架構

分布式架構

分布式架構的使用是建立在業務驅動下使用，相比單體架構，分布式架構中一個請求則是由多個系統(服務)共同協同完成，JVM和環境都是獨立的。優勢在于：a.合理分配服務資源 b.系統獨立維護和部署，耦合度低，可插拔 c.每個系統的架構所使用的技術棧可靈活選擇(比如Java/PHP/GO) d.彈性部署，不會造成平臺因部署造成癱瘓

缺點：a.學習成本高，技術棧多 b.人員/運維/服務器成本增高 c.系統面臨的容錯性也會成倍增加

消息中間件

消息中間件是在消息傳輸過程中保存消息的一種容器,主要應用于分布式系統之間進行通信.通信過程中服務之間采取異步方式,被用于緩沖或緩解高峰期工作負載等業務場景

分布式架構中消息中間件示例

?從示意圖可以了解什么是消息中間件(本質就是接收數據->存儲數據->發送數據)：

1.利用可靠的消息傳遞機制進行各個服務間的通訊

2.利用消息傳遞和排隊機制，在分布式架構中擴展服務間通訊

消息中間件的組成部分

1.消息隊列協議

消息隊列協議都是基于TCP/IP協議實現的一種約定俗成的規范，目的是讓客戶端(Java/Go/Python)進行無障礙通訊，且這種協議下的各種實現必須具有持久性、高可用、高可靠性能。常見的消息隊列協議包括：AMQP、MQTT、kafka、OpenMessage

AMQP協議-實現者RabbitMq、ActiveMQ

MQTT協議-物聯網重要組成部分

?

?OpenMessage協議-實現者RocketMQ(謹慎，萬一公司倒閉，若研發能力不足則需要重構)

kafka協議-實現者Kafka(由于沒有定義復雜的報文頭，基于二進制傳輸更接近于底層，但不支持事務)

彩蛋：為什么消息中間件不直接使用 http 協議?

因為 http 請求報文頭和響應報文頭是比較復雜的，包含了cookie、數據的加密解密、狀態碼、響應碼等附加的功能；對于消息而言，并不需要這么復雜的附加功能，目的只有負責數據傳遞、存儲、分發，只需要簡潔，快速保證高性能即可。
大部分情況下 http 都是短鏈接，當請求到響應這個過程出現中斷后不會進行持久化，會造成請求的丟失。而對于消息中間件的業務場景，當出現問題和故障要時必須對數據或進行持久化，目的就是為了保證消息和數據的高可靠和穩健的運行

2.消息隊列持久化

將消息數據存儲到磁盤，使得數據可以永久保存，而不是存儲在內存隨服務器重啟斷開而消失

消息數據持久化

3.消息的分發策略

MQ消息包含了生產者、存儲消息、消費者，當生產者生成消息以及MQ存儲數據到磁盤后，消費者是如何獲取消息的呢？其實MQ采取的是一種推送機制，而消息推送分發的策略包括如下幾種：

消息分發策略對比

其中：

? ? ? ? a.發布訂閱：所有MQ實現者均支持，對于MQ隊列的數據，都會推送給每一個消費者?，比如有90條數據，那么每個消費者都會收到90條數據

? ? ? ? b.輪詢分發：MQ按照公平分發給每個消費者(不考慮各消費者服務性能的高低)，且不會重復消費數據，但不會按照順序消費。比如：有90條數據，那么每個消費者都會收到30條數據

? ? ? ? c.公平分發：不會重復消費數據，但相比輪詢分發，它會依據各消費者服務器性能有所傾斜，即能者多勞。比如：消費者甲qp為1000/ms，乙為100/ms，丙為300/ms，則對于90條數據，可能甲會消費5條，乙消費50條，丙消費35條

? ? ? ? d.重發：當某個消費者出現異常故障，則隊列會出現消息堆積，當消費者正常后，可重新發送消息，保證高可靠。但Kafka不支持重發

4.消息隊列高可用和高可靠

高可用：指的是服務在某條件或時刻下處于可執行狀態的能力，一般采取集群部署保證高可用

集群模式1-Master-slave主從共享數據部署

????????生產者將數據發送到Master消息隊列節點，所有Slave節點和master共享存儲數據，一旦master節點故障無法寫入，則由slave節點繼續服務，保證高可用，適合小型項目。但共享的數據一旦丟失，那么master和slave就沒有意義了，所以出現了主從同步或者主從復制模式

Master-slave主從共享

集群模式2-Master-slave主從同步數據部署

????????這種寫入數據依然在master節點上，但同時master會同步數據到slave節點形成副本，對于存在多個消費者可以達到負載均衡效果，同時消息的拷貝和同步也會占用比較多的帶寬和網絡資源

Master-slave主從同步數據

?集群模式3-多主集群同步數據部署

?????????和模式2區別在于，寫入時可以采用任意的節點，這樣每個都相當于主節點

多主集群同步數據

集群模式4-多主集群轉發數據部署

多主集群轉發數據

集群模式5-Master-slave和broke-cluster組合部署?

Master-slave和broke-cluster組合部署?

?總結：在不同業務中保證消息高可用有三種方式:消息共享，消息同步，元數據共享(大型項目)

高可靠：指的是系統服務長期無故障持續運行，比如系統突然崩潰等并不影響線上業務正常運行

實現中間件可靠性：

? ? ? ? a.消息的傳輸：通過協議保證系統間數據解析正確性

? ? ? ? b.消息的存儲：通過持久化來保證消息可靠性

消息中間件優勢

? ?a. 異步:消息本身是異步的,它允許在生產者發送消息很長時間后再由消費者接收消息,而不需要等待響應；如果不用 MQ 的話,只能通過調用接口的方式進行同步處理.這樣會存在如下問題：一是會阻塞，像我們系統提醒業務處理過程通常要 1-2 秒，如果一下來了太多請求，可能是處理不過來的，后面的請求只能一直等甚至超時；而 MQ 支持消息堆積，很好解決了這個問題；?二是調用失敗無法自動重試,MQ 可以很容易實現失敗重試
?? ?b. 解耦:消息隊列減少了消息之間的耦合性,不同的服務之間通過消息隊列通信不需要關心彼此之間的實現細節，只要定義好消息格式即可
?? ??? ?如果用調用接口方式,調用三次接口,也不是不可以實現.但是如果后期 B 系統說你不需要推送給我了.我這邊是不是需要刪除掉推送給 B 的代碼,這就是代碼耦合了
?? ?c. 廣播:我們只要將消息送到隊列即可,減少聯調和開發的工作量
?? ?d. 流量削峰與流控:當上下游系統處理能力存在差距的時候,利用消息隊列做一個通用的 ”載體”.在下游有能力處理的時候，再進行分發與處理

消息中間件不足

????a. 系統可用性降低: 如果 MQ 出現問題,就會導致使用到MQ的服務報錯,最終導致系統崩潰
?? ?b. 系統復雜度提高: 加入MQ后,需要考慮如何保證消息的順序性？消息傳遞過程中如何保證不被重復消費？保證消息不會丟失？等等問題
?? ?c. 一致性問題: 比如服務A給服務B、C、D發送了消息,只有都成功才返回成功；若只有C成功,其他失敗,但是返回成功,這就出現一致性問題

?消息中間件對比?

?????????RabbitMQ: 基于Erlang開發,并發能力強,微妙級別延時;吞吐量屬于萬級別,稍遜與十萬級別的RockerMQ和Kafaka;更適合并發量不高的業務場景
?????????RockerMQ: 阿里基于Java開發的產品,可以根據源碼來定制公司的MQ,公司有技術實力我覺得用 RocketMQ 挺好
?????????Kafka? ? ? ? :超高吞吐量,毫秒級延遲,高可用和高可靠,適用于大數據領域中的實時計算以及日志采集場景

消息中間件應用場景

1.跨系統進行數據的分發和異步處理，比如發送郵件、推送短信等

2.高并發的流量削峰

3.大數據分析與傳遞，比如大數據領域的實時分析

高并發流量削峰示意圖

總結

以上是生活随笔為你收集整理的分布式中间件之消息中间件的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。