如何設計基於事件驅動架構的銷售庫存微服務？- Jasbir

庫存管理流程

• 每當收到一批新裝置，管理員就會更新庫存中的裝置。
• 一個使用者在一個渠道（網路，應用程式）上顯示對庫存中的裝置感興趣。一旦使用者將裝置新增到他的購物車中，它就會被保留X分鐘。
• 如果使用者在X分鐘內下了訂單，裝置數量將從庫存中減去。
• 一旦池中的裝置用完，管理員將再次更新池。

產品的幾個重要狀態

1. 如果倉庫裡有超過一個單位的裝置，那麼就是有庫存IN-STOCK。
2. 如果倉庫中沒有任何單位可用，則為缺貨OUT-OF-STOCK 。
3. 如果它是一個新的獨家釋出的產品，可供預先訂購PRE-ORDER。

同步化的挑戰

1. 從銷售目錄提供的裝置清單應該反映裝置的正確狀態（IN-STOCK, OUT-OF-STOCK, PRE-ORDER）。
2. 如果裝置只剩下一個單位的庫存，在銷售庫存中建立一個X分鐘的預訂可能會更新裝置的狀態。這意味著裝置狀態從IN-STOCK過渡到OUT-OF-STOCK。
3. 在X分鐘後取消銷售庫存中的預訂，如果該裝置只有一個單位的庫存，應該影響該裝置的狀態。這意味著裝置狀態從OUT-OF-STOCK過渡到IN-STOCK。

我們正在尋找一個可以解決的方案：

• 如何保持物理庫存和裝置池資料庫之間的同步？
• 如何保留一個裝置X分鐘？
• 如何確保裝置預訂在正確的時間到期？
• 如何讓管理員的實時使用者訂單和庫存更新保持一致？
• 網頁和應用程式上的裝置列表是透過銷售目錄中的彈性搜尋（ES）提供的。我們需要在ES文件中提供一致的裝置狀態資訊，因為現貨裝置應該在上面。ES檔案將如何更新為正確的狀態？

技術方案

• MongoDB
• Elastic Search
• Netflix Conductor (orchestration engine)
• Spring boot based microservices

我們將問題分解為四個部分：

1、狀態同步事件驅動核心

• 它被用作實現的中心，以同步裝置的狀態，由於庫存載入、預訂更新、訂單等操作。
• 銷售庫存中的任何更新操作（POST/PUT）都會導致MongoDB中的資料變化。
• 因此，mongo產生了一個變化事件。
• 該變更事件被執行在銷售庫存微服務中的變更流事件監聽器監聽。
• 變化流事件監聽器啟動一個conductor工作流。
• 然後，conductor啟動一個任務calculate_capacity_status。這個任務在一個庫存微服務中執行。它透過讀取可用庫存和計算當前的預訂數量來計算裝置的狀態。
• 然後，conductor會決定（conveter_decision）銷售目錄中是否有狀態變化。
  如果狀態變化是適用的，那麼指揮者啟動一個任務update_catalog_capacity_status來更新ES中裝置的狀態。這個任務在銷售目錄微服務中執行，以更新裝置的狀態，從IN-STOCK到OUT-OF-STOCK，反之亦然。

• 銷售庫存的資料載入可以由管理員手動完成，也可以由倉庫實時請求。
• 庫存透過庫存管理介面手動載入到銷售庫存中，或者透過連線到倉庫的分銷商自動載入。
  對銷售庫存的POST API操作導致mongo中的資料變化，然後執行上述的 "狀態同步事件驅動核心"。

• 每當一個專案被新增到購物車中，一個專案就會在預訂集合中的一個臨時檔案中被保留X分鐘，其TTL為X分鐘。
• 每當預訂過期時，檔案會從集合中刪除，變化流事件會觸發 "狀態同步事件驅動的核心"。
• 像上面一樣，同樣的事情發生在提交訂單的情況下。訂單意味著將預訂晉升為訂單。因此，庫存的實際計數被遞減並觸發 "狀態同步事件驅動的核心"。

解決方案的亮點

1. 該設計是模組化和事件驅動的。由多個微服務組成的解決方案是鬆散耦合的。
2. 透過使用mongo變更事件，我們能夠監聽到庫存狀態的每一個變化。
3. 導遊工作流的使用幫助我們消除了銷售目錄和銷售庫存兩個領域之間的耦合。
4. 我們能夠設計解決方案的事件驅動核心，該核心已被插入與銷售庫存的所有型別的互動中，無論是資料載入、專案購買還是預訂到期。
5. 有一個單一的驅動程式來更新裝置的狀態變化。