本文從穩定性、核心能力、治理能力以及使用習慣等方面，對比阿里雲雲訊息佇列 Kafka 版與開源Apache Kafka。
穩定性
專案 | 雲訊息佇列 Kafka 版 | Apache Kafka |
磁碟水位 | 磁碟寫滿刪除舊資料。 | 磁碟寫滿直接宕機。 |
線程池隔離 | 讀冷資料仍可以保證寫入基本正常。 | 讀冷資料直接導致線程堵塞，資料寫入大量失敗。 |
分區規模 | 萬級分區仍然可以保證穩定寫入。 | 千級分區就會出現大量抖動。 |
巡檢系統 | 針對死結、宕機等問題進行自動探索和修複。 | 無。 |
Bug修複 | 及時發現並修複。 | 只能等社區緩慢修複，且通常要等新版發布，周期長。 |
核心能力
專案 | 雲訊息佇列 Kafka 版 | Apache Kafka |
彈效能力 | 秒級彈縮，業務幾乎無感知。 | 小時級彈縮，期間會因為複製流量加大，對叢集造成影響。 |
儲存成本 | 專業版提供高可靠雲端儲存，節省大量儲存空間。 | 出於可用性和可靠性考慮，業界通常都是3副本儲存，儲存壓力大。 |
治理能力
專案 | 雲訊息佇列 Kafka 版 | Apache Kafka |
版本升級 | 一鍵自助升級。 | 手工操作易出錯。 |
Metrics曲線 | 能看到完整Metrics曲線，追蹤流量、排查問題必備。 | 只能看到即時Metrics，歷史資料較難查看。 |
堆積警示 | 警示及時發現問題。 | 無。 |
訂閱關係 | 完整的訂閱關係。 | 比較簡略。 |
分區狀態 | 可以看到完整的狀態圖。 | 比較簡略。 |
發送訊息 | 控制台直接發送訊息。 | 只能命令列操作，成本高。 |
查詢訊息 | 控制台根據時間或者位點直接查看訊息。 | 命令列可以消費，但無法根據位點或者時間直接定位到具體的訊息。 |
使用習慣
雲訊息佇列 Kafka 版在用戶端協議層面和開源Apache Kafka完全一致，因此基於開源版本開發的應用和代碼可以無縫遷移到雲訊息佇列 Kafka 版。在通訊協定完全相容的前提下，為了提供更豐富的訊息管控和治理功能，雲訊息佇列 Kafka 版會對使用習慣作出一些限制，具體說明如下。
專案 | 雲訊息佇列 Kafka 版 | Apache Kafka | 差異原因 |
Topic | |||
建立方式 |
|
| 雲訊息佇列 Kafka 版預設通過阿里雲控制台和OpenAPI管理Topic資料，以實現細粒度的許可權管控、資源Action Trail等安全管控能力。 說明
|
命名規範 |
| 支援大小寫字母、數字、底線（_）、短劃線（-）和英文句號（.），限定在3~249個字元。 | 過長的資源命名可能導致在其他系統傳輸過程中受限制，因此雲訊息佇列 Kafka 版限制Topic長度。 |
刪除方式 |
|
| 雲訊息佇列 Kafka 版預設通過阿里雲控制台和OpenAPI管理Topic資料，以實現細粒度的許可權管控、資源Action Trail等安全管控能力。 說明 雲訊息佇列 Kafka 版暫不支援通過開源方式刪除Topic。 |
Group | |||
建立方式 |
| 服務端自動建立 | 雲訊息佇列 Kafka 版預設通過阿里雲控制台和OpenAPI管理Group資料，以實現細粒度的許可權管控、資源Action Trail、訂閱組堆積警示監控等能力。 重要 如需開源方式建立Group，請參見自由使用Group。開啟後則無法再使用上述功能。 |
命名規範 |
| 支援大小寫字母、數字、底線（_）、短劃線（-）和英文句號（.），限定在3~249個字元。 | 過長的資源命名可能導致在其他系統傳輸過程中受限制，因此雲訊息佇列 Kafka 版限制Group的長度。 |
刪除方式 |
| Kafka CLI | 雲訊息佇列 Kafka 版預設通過阿里雲控制台和OpenAPI管理Group資料，以實現細粒度的許可權管控、資源Action Trail等安全管控能力。 說明 雲訊息佇列 Kafka 版暫不支援通過Kafka CLI刪除Group。 |