Slack迁移至基于单元的架构

Slack在过去1.5年内，将其大部分关键用户服务从单体架构迁移到了基于单元的架构。这一迁移的触发原因是网络中断对单个可用区的影响，导致用户服务降级。新架构允许在5分钟内逐步将所有流量从受影响的可用区转移出去。

背景与问题

Slack的全球基础设施主要集中在美国东海岸地区（us-east-1），并使用可用区（AZs）进行故障隔离。然而，Slack仍然偶尔会遇到“灰色故障”，即在分布式环境中，间歇性问题使得确定组件的可用性变得困难，从而影响最终用户。例如，2021年6月30日，某个可用区的网络设备出现间歇性故障，导致了服务中断。

分布式系统中的故障检测难题

Slack的高级工程师Cooper Bethea指出，在分布式系统中检测故障是一个复杂的问题。一个Slack API请求可能会扩展到数百个后端服务的RPC调用，每个调用都必须完成才能向用户返回正确的响应。服务前端持续尝试检测并排除故障的后端，但在排除故障服务器之前，必须记录一些失败。

基于单元的架构

Slack团队决定采用基于单元的架构，每个可用区包含一个完全隔离的后端部署，组件仅限于单个可用区。流量通过使用Envoy/xDS的层路由到可用区范围内的单元。这种隔离的架构部分是由于Slack平台的异构性，使用了多种语言栈和服务发现接口，因此在后端服务之间引入复杂的路由逻辑会非常繁琐。

新架构的优势

新架构使得Slack能够在几秒钟内将流量从出现问题的单元转移出去。流量可以逐步（以1%的粒度）且优雅地转移（所有正在进行的请求在正在排空的单元中完成）。

AWS的指导与社区讨论

Slack的迁移路径遵循了AWS的指南，AWS建议在云架构中建立强故障隔离边界，以应对“黑天鹅事件”并减少意外故障的影响。Slack采用基于单元的架构在社区中引发了广泛讨论。一些用户指出，基于单元的架构已经存在至少10年，而其他用户则强调，AWS的指南基于亚马逊和AWS自己在云中提供弹性的努力。

其他公司的类似举措

最近，Roblox也分享了其向基于单元的架构迁移的旅程，并计划进一步提升平台的弹性。