0

假设我们需要在用户完成购物车后生成订单。

这是我们生成订单的步骤：

  • 生成挂起状态的订单（订单微服务）
  • 授权用户信用（记账微服务）
  • 将购物车的状态设置为关闭（购物车微服务）
  • 批准订单（订单微服务）

为此，我们只需创建一个节奏工作流，为每个步骤调用一个活动。

问题1：如果用户再次打开购物车或刷新页面，客户端如何检测到该购物车的订单创建正在进行中？（注意：假设我们的工作流还没有被worker执行）

我对问题 1 的解决方案：创建订单并将其状态更改为pending在运行工作流之前，因此对于下一个请求，客户知道订单处于待处理状态。但是如果订单创建成功，但启动工作流失败，会发生什么？它不是事务性的（订单创建和工作流程运行）

如果此解决方案也是您的解决方案并且您接受其风险，请告诉我。我是节奏的新手。

问题2：工作流程完成并准备好订单后如何通知客户？

请提供任何解决方案或文章或帮助？

4

1 回答 1

1

问题 1：有多种解决方案需要考虑：

1.1 在工作流中添加一个步骤，在调用订单微服务之前将订单更改为待处理状态，而不是在工作流之外进行。它将使您免于一致性问题，您可以在工作流中添加重试以确保状态最终保持一致。

1.2 增加查询工作流状态查询方法，用户/UI可以通过queryWorkflow调用获取工作流状态，查看订单状态。

1.3 将状态放入工作流的SearchAttribute中，用户/UI可以通过describeWorkflow调用获取状态

1.4. https://github.com/uber/cadence/issues/3729实现后，可以像1.3那样使用memo代替SearchAttribute

比较：如果您认为订单存储是订单状态的真相来源，则选择1.1，1.2 ~1.4将使工作流成为真相来源。这实际上取决于您要如何设计系统架构。

如果用户/UI 期望低延迟，1.2 可能不是一个好的选择。因为 QueryCall 可能需要几秒钟才能返回。

1.3~1.4 会更高效/更快。它只需要 Cadence 服务器进行数据库调用即可获取工作流状态。

如果您通过 ElasticSearch+Kafka 设置启用了高级可见性，那么 1.3 有另一个好处——您可以按订单状态搜索/过滤/计数工作流。但是 1.3 的限制是你应该只放置非常小的数据，比如字符串/整数，而不是状态块。

1.4 的好处是你可以放置一个状态块。

防止用户多次完成购物车：启动工作流时，使用与购物车关联的稳定工作流ID。这样您就可以在允许他们完成/结帐购物车之前调用 describeWF。一旦 StartWF 请求被接受，工作流就会持续存在。如果有活动的工作流程（未失败/完成/超时），则表示购物车处于待处理状态。例如，如果购物车使用 UUID，那么您可以使用该 UUID+前缀来制作工作流ID。Cadence 保证workflowID 的唯一性，因此不会出现为同一个购物车启动两个工作流的竞争条件。如果结帐失败，则用户可以再次提交结帐工作流程。

问题2：这取决于“通知”您想要什么。术语通知听起来像异步通知。如果是这种情况，您可以让另一个活动将通知发送到另一个微服务，或者将信号发送到另一个需要通知的工作流。

如果在这里您的意思是像在 WebUI 上显示的同步方式，那么它可以像我在问题 1中提到的解决方案一样解决。

于 2020-12-01T20:01:39.730 回答