Apache Kafka是一個高度可伸縮的分佈式流平臺，通常用於在基於微服務的系統中分發消息或事件。這些事件有時是業務流程的一部分，其中的任務分佈在多個微服務上。要處理複雜的業務流程，可以使用工作流引擎，但是要匹配Kafka，它就必須提供與Kafka相同的可伸縮性。Zeebe就是一個爲了滿足這種可伸縮性需求而生的工作流引擎，目前正在開發和設計中。在阿姆斯特丹的一次聯席會議上，Kai Waehner描述了Kafka的特性，以及它如何適用於事件驅動架構（EDA）， Bernd Rucker介紹了工作流引擎、Zeebe以及它如何與Kafka搭配使用。
對於Confluent的技術佈道者Waehner來說，如今許多人使用Kafka的一個原因是越來越多的應用程序、微服務、移動應用程序和物聯網設備被集成在一起，從而提供了更多的數據。我們必須處理比以前更多的消息，並且以更快的速度增長，而且通常是實時用例。許多年前，我們開始構建點對點集成，但是它的伸縮性不是很好，而且很難維護。大約10年前，我們開始使用企業服務總線（Enterprise Service Bus，縮寫ESB）進行集成。今天，ESB被一個類似Kafka的消息流平臺所取代，所有應用程序都連接到這個平臺上。
EDA不是一個新概念；這個概念已經存在了至少10到20年。新問題在於我們如何處理數據。不再將數據存儲在數據庫中供其他一些服務讀取和處理，這些數據現在是流動的，並且是連續處理的。事件流平臺的一個重要區別在於，它不像SQL或NoSQL數據庫那樣使用靜態存儲，而是存儲事件或其他消息。這將影響你構建應用程序的方式；現在，事件被髮布出來供其他應用程序消費。
Waehner指出，Kafka關乎三個概念：消息傳遞、數據存儲和處理。它是一個消息傳遞代理，就像許多其他代理一樣，它是一個存儲系統，在這個系統中，數據可以存儲任意期限，最後它還可以處理數據。Kafka與數據庫共享的兩個重要特性是：
-
嚴格的消息排序，這在許多用例中都非常重要；
-
持久性，所有消息都存儲在磁盤上，這意味着它在崩潰的時候也可以不丟失數據。
Kafka的另一個關鍵組件是，它是按分佈式設計的，並且在構建時充分考慮了失敗。其主要概念包括複製、容錯、分區和彈性縮放。
根據Waehner的經驗，許多開發人員只將Kafka看作是一個消息傳遞平臺，因此，他指出，Kafka還包括兩個組件：
-
Kafka Connect，一個基於核心Kafka的集成框架；連接器的例子裏包括許多數據庫和消息傳遞系統；
-
Kafka Streams用於流處理，在Waehner看來，這是處理數據最簡單的方法。
Waehner最後指出，越來越多的人在構建核心業務應用程序時使用Kafka——Kafka在運營業務。分析業務仍然很重要，但這只是一小部分。他看到的另一個趨勢是，他的大多數客戶都是混合的；他們在雲中構建新系統，但仍然有自己的系統，而且它們都需要通信。
Bernd Rücker
Rucker是Camunda的聯合創始人和開發大使，他認爲，在過去的幾年裏，在他的客戶中，有一個明顯的使用微服務的趨勢。他還注意到一種趨勢，即一些客戶已經開始使用事件驅動方法，而且現在正在將其用於所有事情。
使用事件通知模式，系統由負責業務不同部分的微服務構建。服務發佈事件來通知其他服務正在發生的事情。要完成業務功能，可能涉及多個服務，它們相互發送事件。Rucker將此稱爲點對點事件鏈，他指出一個問題，就是很難從業務角度得到整個流圖。他引用Martin Fowler的一篇文章指出，儘管事件通知模式可能很有用，但它也增加了忽略更大規模流的風險。
重新獲得事件流視圖的一種方法是使用監控和跟蹤。在InfoQ的一篇文章中，Rucker介紹了如何實現這一功能的例子。流程跟蹤是他喜歡的方式，因爲通過建模工作流並使用工作流引擎偵聽所有事件，可以從業務角度驗證每個事件流是否正確工作，並在它們失敗時獲得通知。
Rucker指出，過程跟蹤很容易應用，因爲不需要修改任何東西；只需將工作流引擎附加到Kafka基礎設施就可以。這也是處理潛在故障的第一步，例如，當流程花費太長時間才能完成時，添加超時和警告。他提到了Vodafone關於如何替換現有中間件的一個演示，首先使用跟蹤，然後藉助編制逐步替換每項任務。
點對點事件鏈的一個潛在問題是當工作流需要更改時，可能會要求多個服務必須更改它們的事件訂閱。這還需要團隊之間以及服務部署的協調，以及考慮系統中正在運轉的工作流和活動事件。爲了確保業務流程的實現，Rucker更願意將端到端職責提取到一個服務中。這樣有一個好處，你將有一個服務專門負責對公司而言非常重要的事情，並且只有一個點可以控制任務的順序。這也提供了開始使用命令來控制工作流的可能性。命令是編排—你告訴某人做某事—但是Rucker指出，編排是微服務的內部組成部分，而不是每個服務都使用的中心基礎設施機制。他還指出，對於一個負責工作流的服務，有一個點可以檢查正在運行的命令的狀態、命令成功的數量等等。
Camunda目前正在開發Zeebe，這是一個面向微服務的水平可伸縮的工作流引擎，它適合與Kafka一起用於低延遲和高吞吐量的用例。它仍然處於開發人員預覽狀態，但是，他們有運行100~200k工作流實例的試點客戶。據Rücker介紹，Camunda計劃於2019年7月正式投入生產應用。
在InfoQ的一次採訪中，Rucker指出，他認爲訂單履行（這對一個公司來說非常重要）有點奇怪，它不是在覈心領域處理的，而是必須通過監控事件來完成，因爲這樣可以檢測是否有任何訂單被卡住了。在他看來，訂單履行服務應該關注訂單的履行情況，而不是僅僅發佈一個已創建訂單的事件，並希望其他服務確保支付得到處理和貨物交付給客戶。
我們通常討論事件流，但Rucker認爲我們應該討論記錄或消息流，他還強調，Kafka API中的術語是記錄，而不是事件。在他看來，Kafka可以用於不同類型的消息，比如事件和命令，他提到了Gregor Hohpe和Bobby Woolf的重要著作《企業集成模式》，其中描述了命令、文檔和事件消息。