前言

使用叢集建立龐大的艦隊服務，常常需要面臨龐大的使用者請求，面對這群使用者還需要搭建一些「事件串流平台」來滿足使用者，例如接收即時行情，買賣或搶購資訊。 這就要從 Kafka 開始說起。

歷史

• Kafka 的誕生源自於 LinkedIn 的內部專案，2010 年，LinkedIn 為了處理龐大的即時活動流（activity stream），為了實現以下需求：
  • 高吞吐（每秒百萬筆事件）
  • 分散式（跨多個節點保證可用性）
  • 持久化（不是單純的 in-memory queue）
• 工程師 Jay Kreps、Neha Narkhede、Jun Rao 在 LinkedIn 開發出一個新系統 — Kafka。
• 2011 年，Kafka 被捐贈給 Apache 基金會，正式成為開源專案，進入 Apache Incubator。
• 當時的 Kafka，其定位是「分散式 Commit Log」，有別於 傳統的 MQ（ActiveMQ、RabbitMQ） 不同。
  • Publisher/Subscriber 模式 + 持久化儲存
  • Partition 提供水平擴充
  • Zookeeper 管理叢集一致性

演變

• 隨著 LinkedIn 自己用 Kafka 處理各種活動日誌，其他公司（Netflix、Uber、Airbnb）也開始導入。 Kafka 陸續加入
  • Kafka Streams（資料處理 API）
  • Exactly-once semantics（避免重複處理）
  • KRaft 模式（逐步取代 Zookeeper）

  幾乎是要實現 事件驅動架構、資料管線、即時分析 的標配了。

商業化

• 2014 年，Kafka 的三位作者 Jay、Neha、Jun 離開 LinkedIn，創辦了 Confluent。
• 目標很明確： 「把 Kafka 變成企業級資料串流平台，而不是單純的訊息系統。」
• Confluent 在 Kafka 的基礎上，提供：
  • Schema Registry（管理資料結構演進）
  • Kafka Connect（與資料庫、雲端服務整合）
  • Control Center（GUI 監控與管理）
  • Confluent Cloud（雲端全託管 Kafka 服務）
• 原本的 Apache Kafka 是 Apache 2.0 License
• Confluent 的元件，起初也大多是 Apache 2.0 License，包含 Schema Registry、KSQL、Control Center，但在 2018 起，Confluent 引入 Confluent Community License (CCL)
  • CCL 允許使用者可以免費使用，但禁止建立「提供 Kafka 即服務」的 SaaS 平台，目的是避免 AWS、Azure、GCP 直接拿開源 Confluent 元件來包裝販售

結論

• 想單純用 Kafka：直接用 Apache Kafka，社群版本足夠應付大多數情境
• 想省管理麻煩：考慮 Confluent Cloud 或 AWS MSK

  MSK 沒有完整 Confluent 元件!!!

• 想要進階功能（Schema Registry、Control Center）：
  • 需接受 Confluent 的授權