近年来，蜂窝架构在大型在线服务中越来越受欢迎，作为增加冗余和限制站点故障影响范围的一种方式。
蜂窝架构：客户端连接到路由层。路由层使用 HTTP 重定向将客户端重定向到指定的蜂窝单元。
为了实现这些目标，我们在过去 1.5 年里将 Slack 中最关键的面向用户的服务从整体架构迁移到基于蜂窝的架构。
背景上下文
事实证明，检测分布式系统中的故障是一个难题。
来自用户的单个 Slack API 请求（例如，在通道中加载消息）可能会分散成数百个 RPC 来服务后端，每个 RPC 都必须完成才能向用户返回正确的响应。我们的服务前端不断尝试检测和排除出现故障的后端，但在排除出现故障的服务器之前，我们必须记录一些故障！让事情变得更加困难的是，我们的一些关键数据存储（包括我们的主数据存储 Vitess）提供高度一致的语义。
这对于我们作为应用程序开发人员来说非常有用，但也要求有一个后端可用于任何给定的写入。
如果应用程序前端无法使用主分片，则对该分片的写入将失败，直到主分片返回或辅助分片升级以取代其位置。
我们可以将上面的中断归类为灰色故障。
我们解决这个难题的方法不是尝试解决灰色故障的自动修复问题，是通过利用人类判断的力量来使计算机的工作变得更容易。在中断期间，工程师们很清楚地意识到，影响很大程度上是由于一个可用区无法访问，如有一个按钮可以告诉我们这个可用区可能无法访问就直观方便。
因此，我们着手构建一个按钮来减少可用区的流量。
我们的解决方案：可用区是单元格，单元格可能会被耗尽
其整体架构效果是：
- 所有服务都存在于所有可用区中，但每个服务仅与其可用区内的服务通信。
- 一个可用区内的系统故障就被限制在该可用区内，我们可以通过在前端重定向来动态路由流量，以避免这些故障。
详细点击标题