市值 3500 亿平台、崩了 5 个小时！AWS、Kafka 一起翻车

时机确实很微妙。就在 Coinbase CEO Brian Armstrong 谈到非技术团队也能“交付生产代码”几天后，Coinbase 就发生宕机，交易中断约 5 个小时。

不过，这次导致 Coinbase 数小时宕机的原因，并不是所谓“氛围编程”写出的底层代码。问题最初出现在 AWS 数据中心，但真正的原因，是一连串问题相互叠加。

Coinbase 平台负责人 Rob Witoff 表示，其中一个关键问题在于，Coinbase 部署的 Amazon Managed Streaming for Apache Kafka，也就是 AWS MSK，存在一个 bug，导致平台无法顺利完成故障切换。

结果是，单个可用区承担了 Coinbase 大部分核心负载。

单个可用区承担了 Coinbase 的大部分繁重任务……

问题起点是 AWS 的一次“热事件”，但原本设计好的快速恢复流程，最终演变成了一场混乱。

Witoff 没有甩锅。他说：“我们与亚马逊密切合作进行恢复，对方一直是出色的合作伙伴。”

但问题随之而来，这样一家大型加密货币交易所，是否真的具备多可用区，甚至多区域的故障切换能力？

相比之下，Monzo 在云服务严重中断时，可以从 AWS 切换到 GCP 上的精简版银行服务；金融科技公司 Dojo 的授权系统，则同时部署在谷歌云两个区域，即伦敦和法兰克福，以及 AWS 伦敦区域，三个区域会同时处理流量。

以下是 CEO Brian Armstrong 在 5 月 8 日的表态：

“我们设计的服务在任何一个 AWS 可用区（AZ）发生故障时都具有冗余性，昨晚我们的大部分系统都运行正常，但并非全部。我们的集中式交易所没有正常运行。交易所拥有独特的架构，针对延迟和客户端同地部署作了优化。虽然可以使交易所抵御可用区故障，但这可能会带来不必要的延迟……鉴于此次事件，我们将重新评估这些权衡或取舍，以确保为您提供最佳的交易场所。”

这番话听起来，更像是在承认，集中式交易所这部分，并没有真正做到抵御单个可用区故障。

Coinbase 表示，为了降低延迟，其撮合引擎，也就是撮合买卖双方的核心组件，被部署在单个可用区内。

但 Witoff 仍坚持认为：“我们拥有合适的复制因子（RF）来应对区域中断。此次硬件故障触发了托管集群中的一个漏洞，导致集群宕机，我们不得不与供应商合作进行修复。”

他也在 X 上承认：“在此次事件中，原本旨在隔离开来的主可用区故障，并没有被成功隔离。”

US-EAST-1 遭遇高温之夜

据 Coinbase 文档显示，其美国现货交易所基础设施托管在 AWS US-EAST-1，核心组件包括 FIX 订单网关、订单录入网关、交易引擎、WebSocket / FIX 市场数据，均位于 use1-az4 可用区。

上周 AWS 发生“热事件”时，use1-az4 是唯一受到影响的可用区。

由于工程师需要处理散热问题，整批机架停止运行，导致包括 MSK 在内的多项服务中断。

按理说，这不应该对 Coinbase 造成如此大的影响。

Coinbase 表示，公司部署了常见的分布式热备用方案，近期也做过相关演练。

去年 10 月，US-EAST-1 曾导致部分 AWS 服务中断约 3 小时，Coinbase 也是当时受影响最严重的公司之一。后来，这些服务被证实存在单点故障。

Coinbase 在那次故障后表示：“为了在未来做好更好的防备，我们在探索种种方案，包括审查我们的区域部署策略，以实施短期和长期解决方案，以降低此类故障的影响。”

当单个可用区故障并非全部原因时

Coinbase 多年来一直基于 AWS 基础设施构建系统，并使用 MSK 作为中央事件总线，处理来自大量用户、应用软件、数据库和加密货币数据源的事件。

Coinbase 和 AWS 此前曾介绍，MSK 如何支撑这家交易所实现超低延迟的服务间通信、ETL 管道和数据库变更数据捕获，同时将代理维护和恢复交由 AWS 负责。

在架构层面，Coinbase 曾将其描述为一套建立在 MSK 之上的“通用”Kafka 基础设施，具备多个代理和跨可用区可靠性。这样一来，团队可以更轻松地配置流式管道，并降低运维成本。

最终结果，是一个更标准化的流式传输层，支撑大规模实时数据摄取和分析。许多管道的端到端延迟低于 10 毫秒，而早期系统的延迟约为 200 毫秒。

长期以来，Coinbase 对这套架构，以及对 AWS 的依赖都相当满意。就在此次故障发生前不久，Coinbase 和 AWS 还宣布在 Amazon Bedrock AgentCore Payments 上展开合作。这是一个专为智能体打造的支付工具。

AWS 在谈到双方合作时表示：“Coinbase 多年来一直在 AWS 上进行创新，为数百万客户提供加密货币交易和开发者平台。”

Kafka 未能阻止故障

Coinbase 对 Kafka 并不陌生。它每天处理“数 TB”数据，也拥有相应的弹性保障设计。

Witoff 表示，Coinbase 甚至拥有“堪比美国宇航局的质量保证标准”。

但当一系列连锁故障导致交易所撮合引擎和分布式 Kafka 集群瘫痪时，Coinbase 仍然不得不依赖人工修复。

目前，外界并不清楚具体发生了什么。

Witoff 表示，即便系统在多个区域进行复制，也无法避免这次故障。准确说，这是“托管集群中的一个漏洞”，他后来进一步确认，这是一个极端情况。

他在 X 上告诉用户，故障沿着两条路径扩散：

1）交易所撮合引擎底层的多个硬件部件发生故障，需要恢复和故障切换；

2）负责 Coinbase 系统间消息传递的分布式 Kafka 集群无法维持可用状态，还需要将分区故障切换到拥有数 TiB 数据的新硬件代理节点上。

这个 Kafka / MSK 漏洞的具体性质，目前仍不清楚。

Coinbase 承诺，后续会发布更详细的事后分析报告。

Coinbase 仍在调查这起事故，但态度看起来相对克制。

故障发生后的第二天，Coinbase CEO Brian Armstrong 转发了一条略带讽刺意味的推文：“永远不要抱怨。没人喜欢爱抱怨的人。他们只会消耗周围所有人的精力。”

目前市值 515 亿美元（3507 亿元人民币）：

云头条声明：如以上内容有误或侵犯到你公司、机构、单位或个人权益，请联系我们说明理由，我们会配合，无条件删除处理。