我已經協助了一些大型客戶使用Kafka作為訊息傳遞主幹來構建微服務風格的體系結構，並對它的功能和真正使他們發揮作用的用例有了相當好的理解。但是我絕對不是卡夫卡的辯護律師。經歷瞭如此迅速的採用曲線的任何技術都必定會使其受眾兩極分化，並以某種錯誤的方式吸引某些開發人員，Kafka也不例外。像其他任何事情一樣，您需要花費大量時間來全面瞭解Kafka和事件流，然後才能完全熟練並可以利用其能力。一路走來，準備面對一些挫敗感。

我已經整理了一些缺點，這些缺點可能會引起開發人員的挫敗感，或者趕上毫無戒心的初學者。沒有特別的順序：

可調整引數太多

Kafka中的配置引數數量可能不計其數，不僅對於新手來說，對於經驗豐富的專業人士也是如此。可能是除了JVM的唯一例外，我想不出具有這麼多配置引數的另一種其他技術工具了。

這並不是說配置選項不是必需的。但有人想知道，這些引數中有多少可以被人體工程學代替，就像Java對G1所做的那樣。因此，與其指定過多的單個閾值和公差，不如讓運維人員設定效能目標，並讓系統得出最能滿足該目標的最佳值集。

不安全的預設值 

這是我對配置選項的最大抱怨。Kafka的作者圍繞其順序和訊息傳遞保證的實力提出了幾項大膽的主張。如果您認為預設值是明智的，那麼您將被原諒，因為預設值應該使安全性勝於其他競爭質量。

Kafka預設值通常會針對效能進行優化，並且在安全性很關鍵的情況下，需要在客戶端上顯式覆蓋預設值。 (效能和安全性是矛盾，kafka的預設值只照顧效能，如果你考慮安全性高於效能，那麼不能使用這些預設值)

幸運的是，設定屬性以保證安全性對效能僅產生很小的影響-卡夫卡仍然是野獸。記住優化的第一條規則：不要這樣做。如果卡夫卡的創作者給予更多考慮，卡夫卡本來會更好。

一些具體示例：

• enable.auto.commit ：—預設為true，這會導致使用者每5秒提交一次偏移（由 

  auto.commit.interval.ms），而不管消費者是否已完成記錄的處理。通常，這不是您想要的，因為它可能導致混合的訊息觸底語義-在使用者失敗的情況下，某些記錄可能會傳遞兩次，而另一些記錄可能根本無法傳遞。預設情況下，應該將其設定為false，讓客戶端應用程式指定提交。

• max.in.flight.requests.per.connection

   —預設為5，如果一個（或多個）排隊的訊息超時並重試，則可能導致訊息亂序釋出。這裡應該修改預設為1。

駭人聽聞的工具

命令列引數的命名不一致，並且釋出鍵式訊息的簡單操作要求您跳過：傳遞晦澀的、未記錄的屬性。甚至不支援某些本機功能，例如記錄頭。內建工具的可用性是Kafka社群中眾所周知的痛點。

這真是可恥。這就像買一輛法拉利，但交付的是塑料輪轂蓋。長期以來，大多數Kafka練習者都放棄了現成的CLI實用程式，而轉向其他開源工具（例如Kafdrop，Kafkacat和第三方商業產品，例如Kafka Tool）。

複雜的引導過程

客戶端用於建立代理連線的引導和服務發現過程很複雜，並且容易使使用者感到困惑。最初將為客戶端提供代理地址和埠的列表。然後，客戶端將直接連線到一個地址，發現其餘的代理節點，然後再直接建立與所發現節點的新連線。

在簡單，同質的網路設定中，這非常簡單，其中來自所有客戶端和對等節點的所有連線都遍歷單個入口。在異構網路中，可能存在多個入口點以隔離經紀人對經紀人的通訊，生活在同一本地網路上的內部客戶端以及可能通過Internet連線的外部客戶端。

引導/發現過程需要特殊的配置，需要專用的偵聽器和一組單獨的已通告的偵聽器，這些偵聽器將呈現給連線的客戶端。

搖搖欲墜的客戶端庫

使用Java，Python，.NET和C以外的語言編寫的客戶端庫的質量/成熟度均未達到標準。如果您是Java開發人員，那麼就已經做好了–那就是大多數開發工作的集中地。但是Golang和其他社群在努力獲取穩定的庫方面一直很努力，儘管其中一些“獨立”庫已經存在了好幾年，但我在這些語言中遇到的一些錯誤的數量和嚴重性卻是真正有關。

缺乏真正的多租戶

據Kafka的維護者說，它支援多租戶。其設計僅限於訪問控制列表（ACL）來隔離主題和維護配額，這給客戶端帶來了隔離的幻覺，但並未在管理平面中建立隔離。這就是說您的冰箱支援多租戶，因為它可以讓您將食物存放在不同的架子上。

真正的多租戶解決方案將在較大的物理群集中提供多個邏輯群集。這些邏輯叢集可以單獨管理；例如，一個邏輯叢集中ACL的配置錯誤對其他邏輯叢集沒有影響。

缺乏地域意識

地理複製不是內建於代理程式中的，並且公認的是高效能的Kafka群集和“stretch”拓撲不會混合使用。有一個開源專案  MirrorMaker  ，它實際上是一個管道，用於將記錄從一個叢集泵送到另一個叢集，而不保留任何關鍵的後設資料（例如偏移量）。

Confluent擁有其專有工具Replicator  ，該工具  將保留後設資料，但它是許可的Confluent Enterprise套件的一部分。

總而言之，儘管有上述幾點，我也不會說卡夫卡是垃圾-相反。當然，Kafka並非沒有缺陷。輕描淡寫地說，工具是低於標準的。Kafka的配置選項的廣度是壓倒性的，預設設定中充斥著陷阱，隨時可以震驚那些毫無戒心的初學者。

但是，作為事件流平臺，Kafka改變了我們現在架構和構建複雜系統的方式。它為我們提供了選擇，這是一件好事。它的好處超越了多餘的東西，並且使那些已經被如此積極採用的技術束縛住了所有的麻煩。