中間件團(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ù)庫）。
備選架構(gòu)1 - 開源方案評(píng)估
kafka：
人力成本：
測試代表傾向于引入 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)。
