Monzo 如何构建独立备份系统抵御云故障
Monzo Stand-In
在 Monzo，我们深知客户的生活没有停机维护时间，因此必须确保服务 24/7 不间断。为此，我们构建了完全独立的备份基础设施 Monzo Stand-in，运行在 Google Cloud Platform 上，作为 Primary Platform（运行在 Amazon Web Services 上）的最后一道防线。与传统的灾难恢复不同，我们并未简单复制现有服务，而是重新开发了仅包含核心功能的 18 个微服务，以避免因代码缺陷或强一致性要求导致的同步故障。这套系统成本仅为主平台的 1%，通过最终一致性数据同步和 Monzo Advices 机制，确保在主平台完全瘫痪时，用户仍能进行刷卡、转账等关键操作，并在主平台恢复后无缝合并状态。
如果我们在所有数据中心运行相同的软件，那么无论拥有多少个数据中心都毫无意义。
HN 评论区
67- danpalmer
我忍不住觉得这未必是个好主意，它引发了太多问题。故障切换机制是怎样的（对我而言它就失效了！），能否安全地进行故障切换，产品团队如何看待技术栈，资金是否充足，如何瞬间将系统从零扩展到承载全部流量，如何有效地保持该环境处于热备状态，如何判定哪些服务关键到必须纳入其中，如何在两套独立的技术栈中高效定位 Bug，诸如此类，不胜枚举。
我觉得更好的做法或许是投资一个跨多个故障域分布的平台。有些公司称之为“单元架构”（cell architecture）。对 Monzo 而言，这可能意味着真正的多云部署，但他们已经为银行集成提供了裸机服务，所以在某些方面已经是混合架构了。
这不是我会做的决定，我也不确定是否认同他们的理由，但我也得承认，我没经营过银行，不了解他们面临的所有约束，而且 Monzo 确实有一些不错的技术人才。话虽如此，我是 Google 的 SRE，所以我想我在这方面并非完全天真。
编辑：仔细阅读后我有些困惑。他们选择 Stand-In 而非传统横向扩展的理由是数据一致性的难度（这点我同意！），但 Stand-In 本身终究也只是最终一致性，反而在双向同步上引入了问题。诚然，我是被 Spanner 惯坏了，但我确实怀疑 Monzo 是否正被过去的架构选择所困扰。
- jmkni
只是指出一下，这篇文章发表于 2025 年 2 月，所以这事儿已经有一段时间了。
- sdcfgy
鉴于最近那次故障切换并未正常工作，这应该改名为 Monzo Limp-In（蹒跚入场）。
- janpeuker
小事一桩，但我挺喜欢他们在支付/金融语境下使用 "Stand In" 这个词，这通常指代“代理处理”（STIP），即当银行离线时用于维持公共交通等关键服务的机制。
- tarun_anand
我觉得分布式系统里有个术语专门形容这种情况："优雅降级"。