architecture - 如何改进我的设计以处理跨越多个微服务/有界上下文的业务规则？

Question

我正在练习使用微服务建立一个系统，并通过将每个微服务设计为尽可能松耦合和自治来构建这个系统。我正在设置的应用程序必须能够管理视频租赁系统。为此，我有以下微服务，每个都有自己的有界上下文：

• 视频目录：用于管理可租借视频列表的服务。

• 用户：管理用户数据（他们的地址、他们的付款偏好）：我还存储最后一次租赁的日期。

• 在线帐户：允许您管理一个帐户（登录名和密码），以在用户希望查看其租赁列表时识别用户，以取消订阅。

• 出租：允许您管理用户的出租列表。

• 订阅：管理用户的订阅，并根据他的付款方式对该用户的账户进行扣款。

我为自己制定的业务规则之一是：

• 为了不拥有不断增长的用户群：在以下情况下，用户及其所有数据在 3 个月不活动（无新租用）后将被清除：

• 他目前没有租金
• 他的认购没有尚未结清的未付款项

这个规则使用了几个微服务，所以我尝试从用户微服务来管理这个：我在那里创建了一个每天在后台运行的服务：

• 对于最后租用日期超过 3 个月的所有用户：我向租用服务查询，自该日期以来没有其他记录。我通过订阅微服务确认没有未付费课程。然后如果没有活动或待付款，我要求微服务出租、订阅、在线帐户标记用户删除（软删除）用户及其数据从该日期起+每个微服务特定的时间段将被物理删除。如有必要，始终可以在每个微服务上独立取消软删除。

你觉得这个设计怎么样？对我来说，它允许在每个微服务中保持自治。

我认为另一种选择是尝试保持用户服务级别：最后一次租赁完成的日期、最后一次租赁的日期以及最后一次未偿还债务的日期。这将允许我管理我在用户微服务中的所有删除并仅发出 2 个事件：

• 由于不活动而标记为删除的用户
• 用户在第一次事件后一段时间后删除

另一方面，这些必须发出事件：

• 在租赁开始时
• 在租赁结束时
• 当有未付款时
• 当未偿债务清偿时，我保留所有这些事件的历史记录在用户微服务级别的未付账单和租金的历史记录：跟踪这些历史记录可能不是责任，对吧？

标签： architecturemicroservicesbounded-contexts

Answer 1

我认为你在正确的轨道上。删除非活动/无效用户可以被视为特定服务的责任，该服务充当协调器。

一种可能的方法也可以是将用户 ID 连同他们的最后操作日期一起存储在按日期排序的最小堆中。每次整个系统发生事件（例如出租、配置文件更新等）时，此微服务都会更新本地数据并刷新堆状态。此时，您的“清除”任务应该只是从顶部遍历堆，提取节点（-> 要删除的用户 ID）直到它没有达到有效日期。

在此示例中，我仅使用日期，但我想您也可以扩展到其他自定义规则。