Slack重构后端与客户端架构，推出Unified Grid服务大型客户

所有软件都建立在一组核心假设之上。随着新代码的加入和新用例的出现，软件可能会逐渐偏离这些假设。当这种情况发生时，一个根本性的矛盾就会出现：是重新审视那些基础假设——这通常意味着大量的工作——还是试图在现有架构之上支持新的行为。通常建议采用后一种方式，以节省时间并降低风险。

然而，有时候重新审视大型软件应用的核心架构是值得的。最近在 Slack，我们就做了这件事，退后一步，从基础层面改变我们的后端和客户端（桌面和移动应用）的工作方式。

Slack 于 2013 年以简单的架构上线——每个用户属于一个单一工作区，在其中加入频道并发送消息。要查看来自另一个工作区（你同样已登录的）的消息，你需要点击进入那个工作区。

这一模式一直延续到 2017 年，我们发布了 Enterprise Grid，它允许 Slack 最大的客户将其组织划分为多个工作区，每个工作区有特定的侧重点。起初，Enterprise Grid 用户通常只属于一个工作区，但随着时间的推移，使用模式发生了变化，如今这些用户往往属于多个工作区。与此同时，我们为 Slack 客户端构建了在同一 Grid 上跨多个工作区共享数据的方式，例如 Threads 和 Unreads 视图以及跨工作区频道。

这引出了一个自然的问题：如果数据在同一 Grid 上的多个工作区之间共享，而用户需要在那些工作区之间切换来完成工作，那为什么不改为提供一个统一的视图，展示用户在 Grid 内可以访问的所有数据？这不仅会提供更优越的用户体验，还能消除一类因跨多个工作区同步组织级数据而产生的 bug。而且它会提升性能，因为多个工作区的数据可以在单次 API 请求中加载。

基于这一洞察，Unified Grid 项目诞生了。但由于 Slack 的架构假设几乎所有数据都特定于单一工作区，最初并不清楚 Unified Grid 是否可行。尽管如此，我们决定，既然产品持续在突破以工作区为中心架构的极限，我们就必须尝试。

要理解是什么让 Unified Grid 如此雄心勃勃，值得拉远视角来审视 Slack 的架构及其多年来的演变。

2013 年，Slack 以相对简单的模型上线。用户属于工作区，在工作区内加入频道并发送消息。每个工作区代表一个客户，特定工作区的所有数据存储在单个数据库服务器（即“分片”）上。Slack 客户端使用包含用户 ID 和工作区 ID 的会话令牌（称为“工作区令牌”）对其 API 请求进行身份验证；后端随后解析工作区 ID，用它来将每个 API 请求与工作区关联，将查询路由到该工作区的数据库分片，并执行访问控制。这一模型也延伸到了客户端，每个工作区的数据存储在独立的仓库中，拥有不同的登录会话。

随着 Slack 的发展，我们注意到同一公司内的各个部门经常创建独立的 Slack 工作区。我们希望为企业提供一种简单的方式，通过单一 UI 来管理这些工作区，使他们能够在整个组织范围内执行安全策略和处理计费。于是，Enterprise Grid——我们为最大、最复杂客户提供的解决方案——诞生了。

为了支持 Enterprise Grid，我们引入了“org”的概念，它实际上充当多个工作区的“父级”。用户仍然从单个工作区的视角来浏览 Slack，但现在数据也可以存储在组织级别。例如，客户可以创建跨工作区（XWS）频道，这些频道存储在组织的数据库分片上，并在多个工作区中可见。这意味着 Slack 后端需要同时查询工作区分片上的数据，如果那里没有，还要查询组织分片上的数据（对于属于 Enterprise Grid 的工作区）。由于 Enterprise Grid 用户可以在工作区和/或组织级别被分配权限，后端还必须在工作区和组织两个级别检查权限。

最初，由于终端用户通常只属于一个工作区，他们在 Enterprise Grid 中的体验并没有太大变化。然而，随着时间的推移，客户使用 Slack 的方式发生了变化。现在，相当一部分用户确实属于 Grid 上的多个工作区，这导致了上下文切换和活动遗漏。

我们希望解决这些问题，而我们所做的几项基础设施层面的变更指明了前进的方向。通过 Vitess 迁移，我们开始沿工作区或组织 ID 之外的轴向对数据进行分片，这意味着对于我们最重要的表，不再需要工作区或组织来将查询路由到适当的数据库分片。我们还增强了实时消息（RTM）栈，消除了将组织级数据扇出到 Grid 上每个工作区的需要（我们一些最大的客户拥有数千个工作区！）。最后，我们更新了客户端，使其在其 Grid 内的所有工作区之间共享组织级数据。利用这些基础设施投资，我们构建了聚合多个工作区内容的视图，例如我们的 Threads 和 Unreads 视图。

然而，即使有这些改进，我们以工作区为中心的架构仍然造成了显著的困扰。我们知道，要真正解决这个问题，我们需要转向组织级架构，即使这意味着要更新数千个 API、数据库查询和权限检查。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）