如何擴展微服務？ 如果使用卡夫卡

Question

我基於kubernetes搭建了一個微服務平台，但是服務中使用Kafka作為MQ。 現在出現了一個非常令人困惑的問題。 Kubernetes旨在方便微服務的擴展。 但是，當擴容超過 Kafka 分區數時，部分微服務無法消費。 我應該怎么辦？

Answer 1

這是 Kafka 的限制，與您的服務調度程序無關。

Kafka 消費者組根本無法擴展到分區數之外。 因此，如果您有一個單獨的分區主題，因為您關心嚴格的事件順序，那么只有一個服務副本可以從該主題處於活動狀態並使用該主題，並且您需要以 scope 之外的特定方式處理故障轉移卡夫卡本身。

如果您關心的是 k8s 自動縮放器，那么您可以查看 KEDA 自動縮放器的 Kafka 服務

Answer 2

正如 OneCricketeer 所指出的，Kafka 通過分區數量限制了消費的並行性。

如果將處理與消耗結合起來，這會將在任何給定時間執行工作的實例數限制為要消耗的分區數。 因為 Kafka 消費者組協議包括支持將崩潰（或無響應......）消費者使用的分區重新分配給組中的不同消費者，所以運行比分區更多的服務實例至少允許其他實例成為快速故障轉移的熱備件。

可以將處理與消費分離。 大致的輪廓可能是讓您的服務的每個實例都加入消費者組。 最多實際消費的實例數量將從主題中消費。 然后，他們可以根據他們為進行處理而使用的消息向另一個（或相同）實例發出負載平衡的網絡請求。 如果您允許消費者有多個正在運行的請求，這會將您的擴展范圍擴展到max-in-flight-requests * number-of-partitions 。

如果碰巧分區中的消息不需要按順序處理，則請求的簡單循環負載平衡就足夠了。

相反，如果實際上有多個邏輯消息流復用到給定分區中（例如，如果消息由設備 ID 鍵控；ID A 的第二條消息需要在第一條消息之后處理，但可以在與來自 ID B 的消息相關的任何順序），您仍然可以執行此操作，但需要注意確保順序。 此外，考慮到您應該能夠從單個分區的消費者那里獲得的吞吐量量，需要擴展到您擁有比分區更多的處理實例的點，這表明您需要研究負載平衡方法，如果請求 B 需要在請求 A 之后處理（可能是因為請求 A 可能會影響請求 B 的結果），A 和 B 被路由到同一個實例，因此它們可以利用本地內存 state 而不是從數據庫中讀取然后 write-to-db pas de deux 。

這種架構可以用任何語言實現，盡管保持合理的可用性和一致性水平將很困難。 有一些框架和工具包可以提供很多這樣的功能：Akka (JVM)、Akka.Net 和 Protoactor 都在這個領域實現了有用的原語（免責聲明：我受雇於 Lightbend，它維護並提供商業支持）其中，盡管在我在那里工作之前我已經（並且實際上已經）提出了相同的建議）。

當以這種架構風格使用來自 Kafka 的消息時，您肯定必須在最多一次和至少一次交付保證之間做出選擇，這將推動您在提交偏移量時做出決策。 請特別注意，如果至少執行一次，則在處理（或丟棄）該偏移量之前的每條消息之前不要提交，以免最終得到“至少零次”，這不是一個有用的保證。 如果做至少一次，您可能還想嘗試一次有效：至少一次與冪等處理。