facebook - 使用Azure的Facebook Messenger Bot主动/推送通知

Question

我正在使用Microsoft Bot Framework为Facebook Messenger构建机器人。我打算将CosmosDB用于状态管理，也用作后端数据存储。 （我不受CosmosBD的束缚，需要时可以使用任何其他商店）

我需要根据用户的时间偏好将每日/每周的主动消息（推送通知）发送给用户。当他们第一次与机器人互动时，我将捕捉他们的时间偏好。

传递这些通知的最佳方法是什么？

当我将这些首选项存储在CosmosDB中时，我正在考虑使用ComosDB trigger of creating an Azure Function并根据用户时间首选项进行调度。这个Azure函数将调用我的webhook，它将传递这些消息。如果需要，我将在用户更改其偏好时更改功能计划。

我的问题是：


这是一个好方法吗？
还有其他选择（通知中心）吗？
我应该能够为通知设置特定的时间（例如在高峰时间之类的时间），安排在这些时间运行Azure函数是否有意义，而不是根据用户首选项创建函数（我可以实际上也结合了这两种方法）


先感谢您。

Answer 1

首先，我认为这里没有任何“正确”的答案。它在很大程度上取决于您域的特定需求。规模将在设计中起主要作用。您将有100个用户吗？ 10000个用户？ 100万用户？我将假设您想预先设计最大规模，但是这可能会过大。

首先，根据您的描述，我认为CosmosDB触发器不一定是解决问题的方法，因为只有在创建/更新首选项数据时才会触发。我认为，从那时起，您的功能需要在他们选择的时间段连续触发，对吗？

因此，假设您让人们在一天中的24小时内进行选择。幼稚的方法是简单地使用计划的触发器，该触发器每小时触发一次，查询CosmosDB以获取所有文档，其中首选项设置为该特定时间，然后从那里开始发送通知。问题是您如何从那里扩展并面对失败时的幂等问题。

首先，计时器触发器只会启动一个实例。如果您只是查询CosmosDB文档并开始在该单个触发器的范围内一个一个地处理它们，那么您可以相对迅速地达到可扩展到多少个通知的上限。相反，您想要做的是使用该计时器触发器将通知散布到尽可能多的“工作者”函数实例。计时器触发器可以充当协调器，因为它可以拥有针对CosmosDB的查询，然后将针对该特定通知时间窗口找到的每个文档结果转换为一条消息，并将其放在队列中以由单独的功能进行处理它将自行扩展。

实际上，可以通过几种方法使用Azure Functions完成此任务，这实际上取决于您对技术采用者的适应程度有多早。

第一种是所谓的“手动”方式，只需使用现有的Azure存储队列扩展名即可，方法是将IAsyncCollector<YourNotificationWorkerMessage>作为绑定到工作队列的计时器函数的参数，然后将其抽出通过那个。然后，编写第二个使用QueueTrigger的伴随函数，将其绑定到相同的队列，它将处理每个消息。第二个功能是进行缩放的地方，它可以根据您选择配置的任何缩放参数，尽快处理所有排队的消息。这是“最简单”的方法

第二种方法是采用更新的耐用功能扩展。使用该模型，您不必直接考虑创建工作人员队列。您只需从计时器功能中启动协调器功能的新实例，协调器就可以通过为每个通知调用N个“并发”调用来结束工作。现在，它恰好使用幕后的队列分配了这些呼叫，但这是实现细节，您不再需要维护自己。另外，如果传递通知的工作需要更多的工作和/或重试逻辑，则您可能实际上考虑使用子编排而不是简单的操作。最后，这种方法的另一个好处是，一旦所有通知都已交付，您便可以“扇回”您的主要协调器功能，以进行一些后续工作……即使这只是某种事件记录，通知这个小时的周期已经结束。

现在，这两种方法中的任一种的挑战实际上是处理以下问题：最初无法从CosmosDB中获取要通知的候选对象，对结果进行分页，并确保您实际上以幂等的方式将所有这些对象散开了。您需要在分页时处理可能出现的故障，并且需要处理整个功能可能被拆毁并且可能必须重新启动的事实。可能是在最初运行8AM通知时，您浏览了371页中的第273页，然后遇到了完全的网络连接故障或功能运行的VM断电的情况。您可以继续，但是您需要知道您在第273页上停了下来，并且实际上已经从该页开始处理了第27条记录，并从那里开始。否则，您可能会向用户发送双重通知。也许那是您可以接受的，也许不是。只要没有前272页，就可以重复该页面上的27条通知。同样，这是您需要为自己的域决定的事情，但是如果您想避免此问题，那么协调器功能将需要跟踪其进度，以确保它不会发送虚假信息。我再说一遍，持久功能具有配置重试的能力。无论哪种方式，维护特定运行的状态都由作者决定。