建站
咨詢
售后
建站咨詢
新聞中心
備選架構(gòu)1 - 開源方案評(píng)估
kafka：
人力成本：
網(wǎng)站建設(shè)哪家好，找成都創(chuàng)新互聯(lián)！專注于網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、微信小程序開發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了尋烏免費(fèi)建站歡迎大家使用！
測(cè)試代表傾向于引入 Kafka，因?yàn)?Kafka 比較成熟，無(wú)須太多測(cè)試投入。
中間件團(tuán)隊(duì)部分研發(fā)人員也支持使用 Kafka，因?yàn)槭褂?nbsp;Kafka 能節(jié)省大量的開發(fā)投入。
可維護(hù)性：
Kafka 是 Scala 語(yǔ)言編寫的，運(yùn)維團(tuán)隊(duì)沒(méi)有維護(hù) Scala 語(yǔ)言開發(fā)的系統(tǒng)的經(jīng)驗(yàn)，出問(wèn)題后很難快速處理。
運(yùn)維團(tuán)隊(duì)已經(jīng)有一套成熟的運(yùn)維體系，包括部署、監(jiān)控、應(yīng)急等，使用 Kafka 無(wú)法融入這套體系，需要單獨(dú)投入運(yùn)維人力。
業(yè)務(wù)場(chǎng)景：
部分人員認(rèn)為 Kafka 可能并不適合我們的業(yè)務(wù)場(chǎng)景，Kafka 是大容量的日志消息傳輸，而我們的消息隊(duì)列是為了業(yè)務(wù)數(shù)據(jù)的可靠傳輸。
學(xué)習(xí)成本：
業(yè)務(wù)主管傾向于采用 Kafka 方案，因?yàn)?nbsp;Kafka 已經(jīng)比較成熟，各個(gè)業(yè)務(wù)團(tuán)隊(duì)或多或少都了解過(guò) Kafka
備選架構(gòu)2 - 自研集群 + MySQL 存儲(chǔ)
圖片
【簡(jiǎn)單描述】
1. Java 語(yǔ)言編寫消息隊(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è)方案比較簡(jiǎn)單，實(shí)現(xiàn)成本低，但測(cè)試代表認(rèn)為這個(gè)方案測(cè)試人力投入較大。運(yùn)維團(tuán)隊(duì)認(rèn)為這個(gè)方案的硬件成本比較高，一個(gè)數(shù)據(jù)分組就需要4臺(tái)機(jī)器（2臺(tái)服務(wù)器 + 2臺(tái)數(shù)據(jù)庫(kù)）。
可維護(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ì)來(lái)說(shuō)，只要保證消息隊(duì)列系統(tǒng)穩(wěn)定和可靠即可。
業(yè)務(wù)場(chǎng)景：
可以為業(yè)務(wù)場(chǎng)景定制開發(fā)各種特性，例如權(quán)限控制、消費(fèi)速度預(yù)警等。
性能：
部分研發(fā)人員對(duì)于這個(gè)方案的性能持懷疑態(tài)度，畢竟使用 MySQL 來(lái)
存儲(chǔ)消息數(shù)據(jù)，性能肯定不如使用文件系統(tǒng)。
其它：
是否會(huì)影響中間件團(tuán)隊(duì)的技術(shù)聲譽(yù)，畢竟用 MySQL 來(lái)做消息隊(duì)列，看起來(lái)比較“土”、比較另類。
備選架構(gòu)3 - 自研集群 + 自研存儲(chǔ)
圖片
1. 模擬 Kafka 的原理，用 Java 語(yǔ)言實(shí)現(xiàn)，也可以用 LSM 數(shù)據(jù)結(jié)構(gòu)來(lái)存儲(chǔ)消息。
2. 可以保證高可用高性能。
3. 加上可維護(hù)性的各種能力，嵌入到已有的運(yùn)維體系。
備選架構(gòu)3評(píng)估
成本：
要做到穩(wěn)定可靠的存儲(chǔ)系統(tǒng)，需要較長(zhǎng)時(shí)間迭代，投入成本大。
自研存儲(chǔ)系統(tǒng)的測(cè)試難度高，投入也很大。
可維護(hù)性：
可以融入到現(xiàn)有的運(yùn)維體系中，但自研存儲(chǔ)系統(tǒng)需要較長(zhǎng)時(shí)間才能成熟，增大了運(yùn)維風(fēng)險(xiǎn)和投入。
業(yè)務(wù)場(chǎng)景：
可以為業(yè)務(wù)場(chǎng)景定制開發(fā)各種特性，例如權(quán)限控制、消費(fèi)速度預(yù)警等。
性能：
性能上相比 MySQL 要高，但初步評(píng)估并不能高太多。
可用性：
從歷史經(jīng)驗(yàn)來(lái)看，新系統(tǒng)上線肯定有bug，而存儲(chǔ)系統(tǒng)出 bug 是最嚴(yán)重的，一旦出 bug 導(dǎo)致大量消息丟失，影響會(huì)很嚴(yán)重。運(yùn)維代表不太贊成這個(gè)方案，因?yàn)檫\(yùn)維之前遇到過(guò)幾次類似的存儲(chǔ)系統(tǒng)故障導(dǎo)致數(shù)據(jù)丟失的問(wèn)題，損失慘重。
團(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ù)場(chǎng)景：
可以為業(yè)務(wù)場(chǎng)景定制開發(fā)各種特性，例如權(quán)限控制、消費(fèi)速度預(yù)警等。
性能：
性能上和 Kafka 基本持平。
可用性已經(jīng)上線運(yùn)行，支撐阿里業(yè)務(wù)，久經(jīng)考驗(yàn)。
當(dāng)前題目：消息隊(duì)列備選架構(gòu)選擇，你選擇哪個(gè)？
文章出自：http://www.dlmjj.cn/article/cooccpi.html
