備選架構(gòu)1 - 開源方案評(píng)估

kafka：

人力成本：

網(wǎng)站建設(shè)哪家好，找成都創(chuàng)新互聯(lián)！專注于網(wǎng)頁設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、微信小程序開發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了尋烏免費(fèi)建站歡迎大家使用！

測試代表傾向于引入 Kafka，因?yàn)?Kafka 比較成熟，無須太多測試投入。

中間件團(tuán)隊(duì)部分研發(fā)人員也支持使用 Kafka，因?yàn)槭褂?nbsp;Kafka 能節(jié)省大量的開發(fā)投入。

可維護(hù)性：

Kafka 是 Scala 語言編寫的，運(yùn)維團(tuán)隊(duì)沒有維護(hù) Scala 語言開發(fā)的系統(tǒng)的經(jīng)驗(yàn)，出問題后很難快速處理。

運(yùn)維團(tuán)隊(duì)已經(jīng)有一套成熟的運(yùn)維體系，包括部署、監(jiān)控、應(yīng)急等，使用 Kafka 無法融入這套體系，需要單獨(dú)投入運(yùn)維人力。

業(yè)務(wù)場景：

部分人員認(rèn)為 Kafka 可能并不適合我們的業(yè)務(wù)場景，Kafka 是大容量的日志消息傳輸，而我們的消息隊(duì)列是為了業(yè)務(wù)數(shù)據(jù)的可靠傳輸。

學(xué)習(xí)成本：

業(yè)務(wù)主管傾向于采用 Kafka 方案，因?yàn)?nbsp;Kafka 已經(jīng)比較成熟，各個(gè)業(yè)務(wù)團(tuán)隊(duì)或多或少都了解過 Kafka

備選架構(gòu)2 - 自研集群 + MySQL 存儲(chǔ)

圖片

【簡單描述】

1. Java 語言編寫消息隊(duì)列服務(wù)器；

2. 消息存儲(chǔ)采用 MySQL；

3. SDK 輪詢服務(wù)器進(jìn)行消息寫入；

4. SDK 輪詢服務(wù)器進(jìn)行消息讀??；

5. MySQL 雙機(jī)保證消息盡量不丟；

6. 使用 Netty 自定義消息格式，并且支持HTTP 接口。

成本：

中間件團(tuán)隊(duì)的研發(fā)人員認(rèn)為這個(gè)方案比較簡單，實(shí)現(xiàn)成本低，但測試代表認(rèn)為這個(gè)方案測試人力投入較大。運(yùn)維團(tuán)隊(duì)認(rèn)為這個(gè)方案的硬件成本比較高，一個(gè)數(shù)據(jù)分組就需要4臺(tái)機(jī)器（2臺(tái)服務(wù)器 + 2臺(tái)數(shù)據(jù)庫）。

可維護(hù)性：

方案可以融入到現(xiàn)有的運(yùn)維體系中，而且使用 MySQL 存儲(chǔ)數(shù)據(jù)，可靠性有保證，運(yùn)維團(tuán)隊(duì)也有豐富的 MySQL 運(yùn)維經(jīng)驗(yàn)。

業(yè)務(wù)主管對(duì)這個(gè)方案既不肯定也不否定，因?yàn)殚_發(fā)和運(yùn)維都不是業(yè)務(wù)團(tuán)隊(duì)，對(duì)業(yè)務(wù)團(tuán)隊(duì)來說，只要保證消息隊(duì)列系統(tǒng)穩(wěn)定和可靠即可。

業(yè)務(wù)場景：

可以為業(yè)務(wù)場景定制開發(fā)各種特性，例如權(quán)限控制、消費(fèi)速度預(yù)警等。

性能：

部分研發(fā)人員對(duì)于這個(gè)方案的性能持懷疑態(tài)度，畢竟使用 MySQL 來

存儲(chǔ)消息數(shù)據(jù)，性能肯定不如使用文件系統(tǒng)。

其它：

是否會(huì)影響中間件團(tuán)隊(duì)的技術(shù)聲譽(yù)，畢竟用 MySQL 來做消息隊(duì)列，看起來比較“土”、比較另類。

備選架構(gòu)3 - 自研集群 + 自研存儲(chǔ)

圖片

1. 模擬 Kafka 的原理，用 Java 語言實(shí)現(xiàn)，也可以用 LSM 數(shù)據(jù)結(jié)構(gòu)來存儲(chǔ)消息。

2. 可以保證高可用高性能。

3. 加上可維護(hù)性的各種能力，嵌入到已有的運(yùn)維體系。

備選架構(gòu)3評(píng)估

成本：

要做到穩(wěn)定可靠的存儲(chǔ)系統(tǒng)，需要較長時(shí)間迭代，投入成本大。

自研存儲(chǔ)系統(tǒng)的測試難度高，投入也很大。

可維護(hù)性：

可以融入到現(xiàn)有的運(yùn)維體系中，但自研存儲(chǔ)系統(tǒng)需要較長時(shí)間才能成熟，增大了運(yùn)維風(fēng)險(xiǎn)和投入。

業(yè)務(wù)場景：

可以為業(yè)務(wù)場景定制開發(fā)各種特性，例如權(quán)限控制、消費(fèi)速度預(yù)警等。

性能：

性能上相比 MySQL 要高，但初步評(píng)估并不能高太多。

可用性：

從歷史經(jīng)驗(yàn)來看，新系統(tǒng)上線肯定有bug，而存儲(chǔ)系統(tǒng)出 bug 是最嚴(yán)重的，一旦出 bug 導(dǎo)致大量消息丟失，影響會(huì)很嚴(yán)重。運(yùn)維代表不太贊成這個(gè)方案，因?yàn)檫\(yùn)維之前遇到過幾次類似的存儲(chǔ)系統(tǒng)故障導(dǎo)致數(shù)據(jù)丟失的問題，損失慘重。

團(tuán)隊(duì)技術(shù)實(shí)力：

方案復(fù)雜度太高，按照目前的團(tuán)隊(duì)人力和技術(shù)實(shí)力，要做到穩(wěn)定可靠的存儲(chǔ)系統(tǒng)，有較大風(fēng)險(xiǎn)。

運(yùn)維團(tuán)隊(duì)并不相信目前的中間件團(tuán)隊(duì)的技術(shù)實(shí)力足以支撐自己研發(fā)一個(gè)存儲(chǔ)系統(tǒng)。

備選架構(gòu)4 - 直接用阿里的 MetaQ

RocketMQ

成本：

低，接入即可。

可維護(hù)性：

UC 機(jī)房和阿里機(jī)房隔離，打通困難，如果在 UC 機(jī)房部署阿里的系統(tǒng)，部署、維護(hù)、升級(jí)的人力成本太高。

UC 機(jī)房3年內(nèi)估計(jì)不會(huì)切換阿里機(jī)房。

業(yè)務(wù)場景：

可以為業(yè)務(wù)場景定制開發(fā)各種特性，例如權(quán)限控制、消費(fèi)速度預(yù)警等。

性能：

性能上和 Kafka 基本持平。

可用性已經(jīng)上線運(yùn)行，支撐阿里業(yè)務(wù)，久經(jīng)考驗(yàn)。

文章標(biāo)題：消息隊(duì)列備選架構(gòu)選擇，你選擇哪個(gè)？
文章網(wǎng)址：http://uogjgqi.cn/article/cooccpi.html