備選架構1 - 開源方案評估

kafka：

人力成本：

測試代表傾向于引入 Kafka，因為 Kafka 比較成熟，無須太多測試投入。

中間件團隊部分研發人員也支持使用 Kafka，因為使用 Kafka 能節省大量的開發投入。

可維護性：

Kafka 是 Scala 語言編寫的，運維團隊沒有維護 Scala 語言開發的系統的經驗，出問題后很難快速處理。

運維團隊已經有一套成熟的運維體系，包括部署、監控、應急等，使用 Kafka 無法融入這套體系，需要單獨投入運維人力。

業務場景：

部分人員認為 Kafka 可能并不適合我們的業務場景，Kafka 是大容量的日志消息傳輸，而我們的消息隊列是為了業務數據的可靠傳輸。

學習成本：

業務主管傾向于采用 Kafka 方案，因為 Kafka 已經比較成熟，各個業務團隊或多或少都了解過 Kafka

備選架構2 - 自研集群 + MySQL 存儲

圖片

【簡單描述】

1. Java 語言編寫消息隊列服務器；

2. 消息存儲采用 MySQL；

3. SDK 輪詢服務器進行消息寫入；

4. SDK 輪詢服務器進行消息讀取；

5. MySQL 雙機保證消息盡量不丟；

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

成本：

中間件團隊的研發人員認為這個方案比較簡單，實現成本低，但測試代表認為這個方案測試人力投入較大。運維團隊認為這個方案的硬件成本比較高，一個數據分組就需要4臺機器（2臺服務器 + 2臺數據庫）。

可維護性：

方案可以融入到現有的運維體系中，而且使用 MySQL 存儲數據，可靠性有保證，運維團隊也有豐富的 MySQL 運維經驗。

業務主管對這個方案既不肯定也不否定，因為開發和運維都不是業務團隊，對業務團隊來說，只要保證消息隊列系統穩定和可靠即可。

業務場景：

可以為業務場景定制開發各種特性，例如權限控制、消費速度預警等。

性能：

部分研發人員對于這個方案的性能持懷疑態度，畢竟使用 MySQL 來

存儲消息數據，性能肯定不如使用文件系統。

其它：

是否會影響中間件團隊的技術聲譽，畢竟用 MySQL 來做消息隊列，看起來比較“土”、比較另類。

備選架構3 - 自研集群 + 自研存儲

圖片

1. 模擬 Kafka 的原理，用 Java 語言實現，也可以用 LSM 數據結構來存儲消息。

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

3. 加上可維護性的各種能力，嵌入到已有的運維體系。

備選架構3評估

成本：

要做到穩定可靠的存儲系統，需要較長時間迭代，投入成本大。

自研存儲系統的測試難度高，投入也很大。

可維護性：

可以融入到現有的運維體系中，但自研存儲系統需要較長時間才能成熟，增大了運維風險和投入。

業務場景：

可以為業務場景定制開發各種特性，例如權限控制、消費速度預警等。

性能：

性能上相比 MySQL 要高，但初步評估并不能高太多。

可用性：

從歷史經驗來看，新系統上線肯定有bug，而存儲系統出 bug 是最嚴重的，一旦出 bug 導致大量消息丟失，影響會很嚴重。運維代表不太贊成這個方案，因為運維之前遇到過幾次類似的存儲系統故障導致數據丟失的問題，損失慘重。

團隊技術實力：

方案復雜度太高，按照目前的團隊人力和技術實力，要做到穩定可靠的存儲系統，有較大風險。

運維團隊并不相信目前的中間件團隊的技術實力足以支撐自己研發一個存儲系統。

備選架構4 - 直接用阿里的 MetaQ

RocketMQ

成本：

低，接入即可。

可維護性：

UC 機房和阿里機房隔離，打通困難，如果在 UC 機房部署阿里的系統，部署、維護、升級的人力成本太高。

UC 機房3年內估計不會切換阿里機房。

業務場景：

可以為業務場景定制開發各種特性，例如權限控制、消費速度預警等。

性能：

性能上和 Kafka 基本持平。

可用性已經上線運行，支撐阿里業務，久經考驗。