何时开始考虑可伸缩性？[关闭]

我遇到了一个有趣但又可怕的问题。我将要启动一个新的（iPhone）应用程序。这是在我自己的自定义后端上运行的基于回合的多人游戏。但是我怕发射。

由于某种原因，我认为它可能会变得很大，并且它的流行将杀死我可怜的孤独的单服务器+ MySQL数据库。

一方面，我在想如果它正在增长，那么我最好做好准备，并拥有可扩展的基础架构。

另一方面，我只是想将其发布到世界上，看看会发生什么。

我经常读诸如“过早的优化是万恶之源”之类的文章，或者有人说您应该立即使用手头的工具来构建杀手级游戏，而后再担心诸如可扩展性之类的问题。

我很想听听专家或有经验的人对此的一些看法。谢谢！

实际上，这是一个很容易的选择。

现在，您的用户为零，可伸缩性不是问题。

理想情况下，您希望达到拥有数百万用户的地步，而可伸缩性成为问题。

现在，您没有可伸缩性问题。您有许多用户问题。如果您解决可伸缩性问题，则不会解决用户数问题，这意味着您将解决尚未出现的问题，也不会解决已有的问题。最可能的结果是您的产品无法实现，您的所有工作将一事无成。

如果您处理用户数量问题，那么您将解决当前存在的问题，然后您可以专注于下一个问题，这可能是可伸缩性。

关于可伸缩性问题的好处是，按照定义，拥有它们通常意味着业务非常好，这反过来又意味着您可以花钱在优化可伸缩性上。您不会一夜之间从零用户增长到一千万，并且如果您关注系统的性能，那么您将有足够的时间进行优化。

当然，这有助于在编写当前所需的代码时牢记可伸缩性，但是花数十甚至数百个工时来使用您不知道是否需要的功能并没有多大意义。永远需要它，最有可能的情况是您将不需要。现在，您主要关心的是出货。之后会发生什么？好吧，您稍后可以担心。

在您知道需要优化之前，没有理由进行优化。您怎么知道需要优化？你测量。

假设您的服务器具有某种基于Web的界面，则可以使用Apache JMeter之类的工具来模拟很多用户。了解如何使用该工具，然后开始对后端进行压力测试。您应该能够学习足够的知识，以了解系统的局限性。然后，您可以将该信息与您拥有的用户数量以及一次运行的平均数量结合起来，以决定何时进行扩展。

TL; DR在编写第一行代码之前，您应该考虑可伸缩性。

首先是第一件事。可扩展性！=优化

在编写第一行代码之前，您应该考虑可伸缩性。这并不意味着您会在可能会大受欢迎的情况下建立一些庞大的基础设施。考虑可伸缩性意味着：

• 确保已编写代码以便扩展。 我见过很多项目，这些项目没有考虑过扩大规模。结果是一个代码库，无论您使用哪种硬件，它都不会扩展，或者扩展成本过高。
• 找出您的扩展策略。 制定有关如何支持所有用户的计划。您有一个MySQL数据库，是要对其进行分片或群集还是其他。诸如分片之类的策略需要预先考虑，因为它对体系结构提出了要求。集群，少了。您是否在支持会话，会话将如何与多个前端服务器进行响应？您是否需要在负载均衡器中进行粘性会话。
• 制定实施策略。 您是否打算使用AWS进行扩展。您是否可以利用任何产品或服务来立即进行动态扩展？这还涉及了解您的费用。

但是听起来您已经有了一个代码库。现在的问题是何时开始扩展。这完全取决于您的代码。

如果您的代码适合扩展，那么您将完成艰巨的工作。您可以获得一个AWS账户，根据需要启动服务器，然后就可以使用了。

如果您的代码无法扩展或存在瓶颈，那么您需要做的工作。您需要确定瓶颈所在并加以解决。“时间”真的很难知道。一些服务处于平稳状态，一些服务稳定增长，而另一些则爆炸。决定何时以类似规模的方式投入资源通常是业务的功能，并且是对风险的评估。

在您的位置上，我可能会发布“测试版”并管理用户的期望。这样我就可以拿出产品了，看看它如何展开。

因此，您应该考虑两次可扩展性。

首先，在编写一行代码之前，应该仔细考虑一下。这是为了确保您不会陷入可伸缩性漏洞中，并确保对您的代码进行了测试以提供第二次所需的度量。

第二次考虑可伸缩性的事情已经变得越来越慢了。这意味着您需要知道“太慢”是什么意思，以及事情在负载下如何反应。如果您的服务的驱动程序（可能是qps）每月增加N％，那么如果您的资源使用情况是负载平方或负载线性的，则您的时间与“消耗的95％的机器资源”时间截然不同。

对于基于回合的游戏，您应该具有不错的安全边际（您可能没有一个游戏世界，如果这样做，则可能存在内部几何结构，这意味着您不必“每个人都与每个人交互转”问题）。

在不知道具体细节的情况下，我将花费一两天的时间来思考您在哪里遇到了扩展问题以及解决这些问题的可能策略。但是，这很重要，请考虑一下。不做，只想想（和记录）。除非您的伸缩性问题开始在数百个用户中体现出来，否则您应该有时间检查负载并增加更多后端资源。

根据您的描述，听起来可能有两种结果：

• 游戏失败，然后您不在乎。
• 游戏成功了，然后您的后端将无法处理负载，结果将是失败。

嗯

以下是一些要问自己的问题：

• 您当前的后端可以处理多少个用户，并具有可接受的性能？
• 如果您看到某种快速增长（例如，暂时将游戏从应用商店中撤出），您是否制定了某种计划来限制对当前用户的影响
• 如果成功，您多快能想到一个更好的后端？
• 等待的业务含义是什么？你能养活自己吗？有什么风险？
• 鉴于上述问题的答案，现在发布的业务含义是什么。

一旦考虑了这些问题，答案就会变得显而易见。没有任何专家可以告诉您在没有更多信息的情况下该怎么做，因为每个系统都不相同，每个业务都不同。

您的服务器将被用户交互使用。这意味着等待时间以非常深刻的方式影响着用户体验。延迟延迟总是会导致不良的用户体验。

至少按照Bryan的描述进行一些临时的负载测试。

更严肃的方法

做一些模拟运行，找出延迟对用户体验的影响（使用网络延迟模拟或仅在应用程序内部使用sleep（））。找出延迟变得越来越明显，变得烦人并且变得无法使用的延迟时间。

然后是朝优化方向迈出的第一步。决定服务器的SLA：例如，在最糟糕的情况下，有10％的呼叫具有令人讨厌的延迟，而有1％的呼叫具有不可用的延迟。有了这些限制，您就可以使用负载测试来找出您的服务器可以支持多少用户。

不测量延迟（或至少在负载测试期间手动使用服务器）的纯吞吐量测试不是那么有用，因为它无法告诉您所测量的吞吐量数字是否会带来可承受的用户体验。

吉尔·特内（Gil Tene）讲的关于测量延迟的非常好的演讲：http : //www.infoq.com/presentations/latency-pitfalls

在业务需求阶段，然后用于建立对下游所有元素（例如体系结构，操作，开发，质量保证和产品监控）的性能的共识。如果您没有对需要的内容达成共识，那么您将需要组织的各个部门在执行整个生命周期中的特定任务时对性能进行假设（或根本不考虑它们）。应用。无论您是从事瀑布式，短瀑布式，敏捷式，还是在简历关键字列表上当下最热门的开发方法，这都是事实。

性能和可伸缩性很难。功能很容易。可伸缩的扩展代码将无法满足您提供给它的任何资源池，因此，通过购买大型硬件来转移成本泡沫只需要花费很长时间，您就必须修复效率低下的代码或购买更多的硬件。将其放在最后要优先考虑也是非常昂贵的。在应用程序生命周期的早期就有一些架构和设计决策，为了满足与性能相关的最新要求，可能必须完全颠倒-考虑一下高性能跑车制造商必须从铝制转向铝制碳纤维在设计周期的后期达到了与性能相关的功率/重量比，以及这如何影响工具，培训，汽车的构造等。

向组织中的架构师，开发人员和操作人员询问应用程序的性能要求是什么。如果这些不是从企业中捕获的，那么即使您在同一组中也收到来自不同个人的不同答案（或没有答案），也不要感到惊讶。这些“假设”总是会再次打击组织的部署。