Atlassian 使用边车和高容错设计将可用性提升到 6 个 9 以上
Atlassian 使用边车和高容错设计将可用性提升到 6 个 9 以上
作者 | Eran Stiller
译者 | 明知山
策划 | 丁晓昀
Atlassian 工程播客最近分享了其租户上下文服务（Tenant Context Service，TCS）如何让可用性超过了 99.9999%。Atlassian 通过实现高度自治的客户端边车实现了这种高可用性，能够主动保护自己免受 AWS 区域故障的影响。边车通过并发地查询多个 TCS 服务并确保请求在内部是完全隔离的来实现这一目标。
TCS 是 Atlassian 的一项关键基础设施服务，在大多数 Atlassian 云产品的每个 Web 请求路径中都会被多次调用。它提供了“租户元数据”的高可用性、读优化的视图。2022 年 7 月，TCS 每天处理 320 亿次请求，峰值请求率为每秒 586308 次。总体可用性超过了 99.999%，最高吞吐量的客户端在高峰期的平均响应时间约为 11μs。
为了实现这些指标，Atlassian 的工程师采用 CQRS 模式设计了 TCS。当“租户元数据”目录发生变化时，TCS 将“租户元数据”的转换视图导入 AWS DynamoDB。此外，TCS 广泛使用 L1 内存缓存，以及基于 SNS 的缓存失效广播系统。与客户端应用程序一起部署的边车作为 Web 服务器缓存的远程扩展，并通过与多个 TCS 部署通信来提高可用性。下图描绘了 TCS 的架构。
图片来源：https://www.atlassian.com/engineering/atlassian-critical-services-above-six-nines-of-availability
由于边车的缓存命中率通常超过 99.5%，无法命中的情况相对较少。因此，TCS 边车会在缓存未命中时抢先发送重复的请求——一个发送给选定的“主”父 TCS，一个发送给随机的辅助 TCS。这种方法的一个好处是，边车将无缝地处理父节点或网络故障。它不需要检测失败的请求，因为“后备”请求已经在进行中。
Atlassian 的主要开发者 David Connard 解释了这种方法的细节。
虽然这种逻辑可以很好地应对快速失败的场景，但还需要为缓慢失败的场景做好计划，这通常是系统要处理的最成问题的故障模式，此时关键要进行一些适当的隔离。对于我们来说，适当的隔离意味着任何单亲 TCS、AWS 服务或整个 AWS 区域的故障都不能影响我们的边车在不同区域运行的能力。
为了实现这种高水平的隔离，Atlassian 工程师使用独立的任务队列和线程池来处理请求，对于每个父 TCS 来说是完全隔离的（甚至连 HTTP 连接池实例都是如此）。他们通过减少请求负载（有选择地丢弃请求）和动态调整线程池（限制延迟较低的 TCS 部署的线程池的大小）来防止因任务排队并消耗额外的资源导致的慢故障场景。
在服务器端，失效广播系统进行跨区域调用，发布失效消息。由于跨区域延迟明显较高，可能会影响失效广播。Connard 解释了工程师如何保护 TCS 免受这个问题的影响。
不能让跨区域停机（例如某个目标区域中的 AWS SNS 故障）延迟或阻止从该 TCS 服务器向其他区域发送失效广播。为了实现这种隔离，TCS 服务器失效广播系统将所有失效广播数据和处理线程复制到单独的特定于区域的队列中。然后，隔离的工作线程仅从其中一个队列发布到每个目标区域。向一个目标区域发送广播的速度减慢或完全失败只会减缓该区域的处理速度，不会影响向其他目标区域发布消息。
除了提高系统的可用性外，Atlassian 的工程师还采用了多种方法来伸缩系统，包括使用 SNS 扇出模式、包含边车网络监控功能的自定义请求负载平衡策略，以及采用 gRPC 作为 HTTP API 的低延迟替代方案。
原文链接：
https://www.infoq.com/news/2022/09/atlassian-high-availability/
声明：本文为InfoQ翻译，未经许可禁止转载。
点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！
今日好文推荐
编程神器Copilot逐字抄袭他人代码？GitHub 回应：相似，但不同......
Htmx意外走红，我们从React“退回去”后：代码行数减少 67%，JS 依赖项从 255 下降到 9
硅谷“网红”技术大牛 Steve Yegge：退休后面试工程主管，他们居然让我写点代码
智联招聘：Q3 全国平均招聘月薪 10168 元；曝特斯拉拒招小鹏前员工；英特尔或裁员数千人，国内公司涉多起劳动纠纷｜Q 资讯
