如何设计基于事件驱动架构的销售库存微服务？- Jasbir

在这篇文章中，我将带领大家了解OneShop（我们的电子商务产品）的销售库存解决方案。
销售库存解决方案也是一个为所有渠道（OneShop、OneApp等）和Natcos统一的多租户解决方案。它确保了销售视图和仓库库存之间近乎实时的同步。

库存管理流程

• 每当收到一批新设备，管理员就会更新库存中的设备。
• 一个用户在一个渠道（网络，应用程序）上显示对库存中的设备感兴趣。一旦用户将设备添加到他的购物车中，它就会被保留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，反之亦然。

2、将数据加载到销售库存中

• 销售库存的数据加载可以由管理员手动完成，也可以由仓库实时请求。
• 库存通过库存管理界面手动加载到销售库存中，或者通过连接到仓库的分销商自动加载。
  对销售库存的POST API操作导致mongo中的数据变化，然后执行上述的 "状态同步事件驱动核心"。

3、添加到购物车时的销售库存更新。在购物车或提交订单中增加一个项目会导致设备的状态发生变化。

• 每当一个项目被添加到购物车中，一个项目就会在预订集合中的一个临时文件中被保留X分钟，其TTL为X分钟。
• 每当预订过期时，文件会从集合中删除，变化流事件会触发 "状态同步事件驱动的核心"。
• 像上面一样，同样的事情发生在提交订单的情况下。订单意味着将预订晋升为订单。因此，库存的实际计数被递减并触发 "状态同步事件驱动的核心"。

4、将状态暴露给渠道。任何渠道都可能需要查询每个设备的库存状态或数量。销售库存为这一目的从其核心暴露了简单的GET操作。

解决方案的亮点

1. 该设计是模块化和事件驱动的。由多个微服务组成的解决方案是松散耦合的。
2. 通过使用mongo变更事件，我们能够监听到库存状态的每一个变化。
3. 导游工作流的使用帮助我们消除了销售目录和销售库存两个领域之间的耦合。
4. 我们能够设计解决方案的事件驱动核心，该核心已被插入与销售库存的所有类型的互动中，无论是数据加载、项目购买还是预订到期。
5. 有一个单一的驱动程序来更新设备的状态变化。