使用Kafka重新架構電子商務系統 - Dina

示例是：向經過身份驗證的使用者顯示產品頁面，下圖顯示了在這種情況下如何執行請求。

為經過身份驗證的使用者顯示產品頁面，請注意，必須執行五個請求，但我們應該只計算四個順序請求。儘管如此，由於請求是以同步方式執行的，整個系統不容易擴充套件並且存在很多問題。

由於這種高耦合度，我們的系統可能面臨多個問題，例如：

• 需要時難以擴充套件
• 高負載下效能低
• 外部服務不可用造成的不可用
• 因協調部署而難以維護

解決方案的主要思想是將所有主資料項轉換並聚合為單個派生項，該派生項隨後可以儲存到資料來源中並在需要時進行查詢。

由於我們已經使用Kafka生態系統來解決這個問題，最終的解決方案將是一個Kafka Streams 拓撲以及幾個Kafka Connect元件，這些元件將通過發件箱模式或更改資料捕獲的各種實現風格從資料來源中提取資料併發布將其傳送到 Kafka，以便在流應用程式中攝取。

流拓撲將使用產品 ID作為分割槽鍵來連線所有 Kafka 主題中存在的資料。所有連線的結果將釋出到 Kafka 主題中，然後可以寫入資料庫。正在生成的此資料聚合將稱為SaleProduct。

我們可以在SaleProduct資料庫之上構建一個新服務（REST API、GraphQL API）。前端應用程式可以查詢這個新端點，並且這個端點可以將產品作為響應提供服務，而無需任何中間處理。

結論

總之，讓我們重新審視我們的系統面臨的上述列舉的問題，看看其中是否仍然存在：

• “需要時難以擴充套件”——在當前的解決方案中，元件不再難以擴充套件，因為 Kafka 拓撲可以通過新增分割槽輕鬆擴充套件。我們可以為新的SaleProduct資料儲存選擇特定的資料庫技術，該技術也可以輕鬆擴充套件（例如：Cassandra 資料庫）。此外，SaleProduct API是一個簡單的無狀態服務，可以橫向擴充套件。
• “高負載下的低效能”——通過使用來自“本地”資料庫的單個查詢替換所有用於聚合資料的同步 HTTP 請求，將顯著提高高負載下的效能。此外，查詢不會執行任何連線，資料可以直接儲存在所需的表示中（例如：JSON、XML 等）。
• “由於外部服務不可用而產生的不可用”——如果在之前的場景中，外部元件的不可用會導致所謂的“產品服務”的不可用，在當前的解決方案中，這是避免的，因為我們有資料已經儲存在我們的“本地”資料來源中。必須保持可用的單一元件必須是資料庫本身。
• “由於協調部署而難以維護”——這不再是問題，因為我們不再在空間或時間上與任何外部服務耦合。

不過，我必須說這不是一個防彈解決方案，並且有兩個主要缺點：

• 面對最終一致性——如果沒有人注意到，我已經在本文中基本描述了我們如何以及為什麼從著名的CAP 定理中選擇A（可用性）和P（分割槽容限），我現在要說的是：使用這種方法，我們必須準備好面對最終的一致性！
• 資料治理——通常，在大型複雜企業中，很難像當前解決方案中那樣使用（檢索和派生）主資料和構建派生資料孤島。通過檢視Zhamak Dehghani 的資料網格，可以看到一些關於採用這種方法的概念。