Pokémon Go 发布提醒 为什么“按规模构建”与“按失败构建”一样重要

过去许多年来，DevOps 和云计算的流行语之一就是“构建以失败为目的”。 前提是，太多企业由于容量相关的性能问题而经历代价高昂的停机和收入（和生产力）损失，因此您应该构建您的应用程序和基础设施“以防万一”，以确保此类可怕的事件不会再次困扰您。 呵呵。 看到我做了什么了吗？ 是的，我独自一人在办公室远程工作。 有时我必须自娱自乐。

抛开糟糕的双关语不谈，最近 Pokémon Go 的巨大成功（你听说过，对吧？）也给很多人带来了极其令人沮丧的体验。 尤其是那些孩子的家长，他们非常兴奋，他们想现在就去，但却不能去，因为由于需求量太大，账户创建被暂时中止，然后受到严格计量。

现在，有些人可能会指出，亚马逊首席技术官沃纳·沃格尔斯 (Werner Vogels) 提出帮助公司解决容量问题，这意味着他们一开始就没有“迁移到云端”，而这才是根本问题，但这是假设他们没有迁移到云端，目前我还不太清楚。 说真的，根据维基百科对增强现实开发商的更新，它“每天处理超过 2 亿个游戏动作，因为人们与物理世界中的真实和虚拟物体进行互动”。 我认为我们可以在这方面给他们一点休息时间，或者至少我们这些了解这意味着什么的人在系统交互和推送数据包方面可以这样做。 更新指出“服务器问题”，但说实话，我们都知道“服务器”是“分布在应用程序和网络基础设施上的 15 个不同组件”的技术代码。

无论如何，这里的基本教训并不是云计算一定能更好地应对意外的成功。 很有可能，但不是因为它是云。 这是因为云不仅是为了失败而构建的，而且是为了扩展而构建的。

我无法确定为什么 Niantic Labs 无法满足需求。 也许是缺乏容量，在这种情况下云将是一个不错的选择，也许是应用程序和/或基础设施不是按规模构建的，在这种情况下云可能根本没有帮助。 重点其实不是要因为他们做过或没做过什么而责备他们。 关键在于，它们是应用世界中现实的完美例证，组织应该像关注成功构建一样关注失败构建。 而且并不是逐渐取得成功，而是立即、一夜之间取得的成功，就像 Pokémon Go 那样。

因为如果发生了这种情况，你肯定不希望这种成功的失败被传遍整个互联网。

可扩展性问题的一个常见根源在于数据源。 经验丰富的 Twitter 用户会记得，社交媒体早期受到数据库可扩展性挑战的困扰。 PayPal 是最早和最积极支持分片技术的扩展策略的公司之一，该技术旨在解决海量用户带来的挑战，并且已经被广泛采用，适用于数据库、性能服务和应用。 NoSQL 数据源的兴起宣称其优点之一是比传统关系数据库具有更高的可扩展性。

可扩展性问题的另一个根源完全在于基础设施。 云中的自动扩展依赖于不仅自动添加更多计算的能力，而且增加“应用程序端点”容量的能力。 在任何依靠规模来实现容量的增加的架构中，这意味着某种类型的负载均衡服务。 当计算量增加时，必须向负载均衡服务注册。 这意味着使用 API 和脚本、自动化和编排。 这些组件必须在需要之前到位，否则当需求要求增加容量时，就会出现延迟。

任何应用程序架构中都应该包含负载均衡服务。 负载均衡服务不仅满足了“构建失败”的需求（因为它本身支持两个应用实例之间的故障转移），而且还支持成功所必需的“构建扩展”的需求。 但不要认为它只是在应用程序（或微服务，如果你喜欢的话）前面添加一个负载均衡服务。 对于操作来说，实施自动化（脚本）和编排（流程）非常重要，这样才能实现自动扩展以满足需求。 今天的扩展是关于架构，而不是算法，重要的是预先考虑架构，否则架构债务会变得过于严格，以至于您无法使用现有的架构。

说实话，Niantic Labs 在应对失败方面做得很好。 容量故障会收到友好消息，而不是我经常遇到的默认 HTTP 状态代码页面。 它们很幽默，小孩子也容易阅读和理解（我知道，因为我 8 岁的孩子每 20 分钟就给我们读一次）。  他们没有想到的是，他们竟然获得了意想不到的成功。 这对每个人来说都是一个很好的提醒，规模化建设与失败建设同样重要。   

因为当你不这样做时，火箭队就会获胜。