用于将 Slack api 与多租户筒仓模型部署集成的应用程序架构

Question

我正在开发一个专门与 Slack 等消息平台集成的应用程序，但还有一个网络应用程序。整个堆栈位于 AWS 内，利用无服务器模型，因此每个客户在 Slack 组件之外都将拥有完全孤立的架构，该组件必须具有共享 API，以便根据其应用程序要求与 Slack 集成。

到目前为止，我想出的最好的处理方法是一个 DynamoDB 用户表，其中所有 slack ID 都绑定到 cognito_id/email，并且来自 Slack 的任何事件都会得到丰富，然后传递给特定的客户 lambda 函数，但我看到了维护方面相对较长的令人头疼的问题。

人们是如何处理这个问题的？

Answer 1

一般来说，将 Slack 集成到多租户应用程序中（每个租户都可以带来自己的 Slack 工作区）有一定的复杂性。

1. 授权和凭证管理。作为应用程序的开发人员，您将在 Slack 市场中注册一个 Slack 应用程序。当要求您的用户授权访问其Slack 工作区时，将使用该应用程序。在您的用户获得访问授权后，您将获得其 Slack 工作区的访问令牌，该令牌允许您调用 Slack API 向他们发送消息等，具体取决于您请求的范围。您需要存储这些凭据以供以后使用，并在应用程序中消除客户 ID 的概念。

2. 身份映射。如果您正在使用Slack 事件，您的单例 Slack 应用程序将从您客户的任何和所有工作区接收 Slack 事件。您需要查看事件负载并根据负载中的数据反向查找您自己的客户 ID。此过程可以基于 Slack 工作区 ID、最初在该工作区中授权您的应用程序的用户的 Slack ID，或生成该事件的用户（该工作区的成员）。一旦确定了应用程序客户的客户 ID，您就可以以特定于客户的方式处理该事件（例如将其传递给您案例中的相应 Lambda）。

3. 怪癖。Slack 尤其对事件和 Slash Command 处理有一些特定要求 - 您的应用程序必须在收到请求后3 秒内做出响应。如果您预计处理时间较长，则必须分两个阶段完成 - 首先，您快速同步响应以确认收到，然后花更多时间异步处理该事件。

要解决上述 1 和 2 问题，您需要使用某种存储机制，允许从您自己的客户 ID 或 Slack 身份开始双向查找身份。如果您在 AWS 中运行，DynamoDB或Aurora是合理的选择。

在应用程序中实现入站 Slack 集成时，除了这些之外还有更多考虑因素，包括限制、重试等。