使用Apache Kafka對電子商務系統進行擴充套件的思路 - Bogdan

banq發表於2021-06-08
ApacheKafka套件

案例：我們正面臨一個以同步方式過度耦合到大量外部元件的遺留電子商務系統。由於這種高耦合度，我們的系統可能面臨多個問題，例如：
  • 當需要時卻難以擴充套件
  • 高負載下效能低
  • 外部服務不可用造成的不可用
  • 由於協調部署，難以維護

 

解決方案
下面將介紹針對上述場景的可能解決方案。它的靈感來自於構建資料密集型應用程式的一些設計原則。一些用於瞭解這些的更深入的資源可以是：


所提出的解決方案的主要思想是將所有主資料項轉換並聚合為單個派生項，該派生項隨後可以儲存到資料來源中並在需要時進行查詢。
由於我們已經使用Kafka生態系統來解決這個問題，最終的解決方案將是一個Kafka Streams 拓撲以及幾個Kafka Connect元件，這些元件將透過發件箱模式或更改資料捕獲的各種實現風格從資料來源中提取資料併發布將其傳送到 Kafka，以便在流應用程式中攝取。
流拓撲將使用產品 ID作為分割槽鍵來合併所有 Kafka 主題中存在的資料。所有合併連線的結果將釋出到 Kafka 主題中，然後可以寫入資料庫。
Kafka生產的資料聚合稱為SaleProduct，我們可以在SaleProduct資料庫之上構建一個新服務（REST API、GraphQL API）。前端應用程式可以查詢這個新端點，並且這個端點可以將產品作為響應提供服務，而無需任何中間處理。
 

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

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

不過，我必須說這不是一個高可用的解決方案，並且有兩個主要缺點：
  • 面對最終一致性： 我們在CAP 定理中選擇A（可用性）和P（分割槽容限），我現在要說的是：使用這種方法，我們必須準備好面對最終的一致性！
  • 資料治理：通常，在大型複雜企業中，很難像當前解決方案中那樣使用（檢索和派生）主資料和構建派生資料孤島。透過檢視Zhamak Dehghani 的資料網格，可以看到一些關於採用這種方法的概念。


 

相關文章