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

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

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

流拓撲將使用產品 ID作為分割槽鍵來連線所有 Kafka 主題中存在的資料。所有連線的結果將釋出到 Kafka 主題中，然後可以寫入資料庫。正在生成的此資料聚合將稱為SaleProduct。
我們可以在SaleProduct資料庫之上構建一個新服務（REST API、GraphQL API）。前端應用程式可以查詢這個新端點，並且這個端點可以將產品作為響應提供服務，而無需任何中間處理。

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

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

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