是什么使应用程序具有可伸缩性？

我在职位发布中不断看到，申请人必须具有编写“可扩展”应用程序的经验。是什么使应用程序具有可伸缩性？我如何知道我的代码可以扩展到数百万个用户？

我想表达这个问题的一种更好的方法是：如何在编写代码时考虑可伸缩性？这样一来，代码就可以从一开始就进行扩展，而不是事后才想到。是否有某些设计方法？还是仅仅是为工作选择正确的算法？

可伸缩性有两个方向：

• 纵向（又称纵向扩展）：更快的CPU，更多的RAM，更多的磁盘空间；
• 水平（又称横向扩展）：CPU中有更多核心，更多CPU，更多服务器；

对于第一个，您只需要注意没有任何限制即可。这些是因为整数大小太小或固定/有限长度的结构。这些结构可能与基础操作系统有关。例如，如果您尝试使用更多的线程或进程进行扩展，则有时将达到操作系统的极限。这就是为什么当前为实现高可伸缩性而构建的服务器正在基于异步事件进行并发的原因。在著名的C10K文档中描述了此问题。

第二个比较困难。它需要在编程时注意两点：数据将并行处理，并且数据可能会物理分布。节点之间的通信应受到限制。实际上，这通常意味着牺牲ACID的某些部分（事实证明您不能拥有完整的ACID和同时扩展能力）。该范例中最著名的数据存储解决方案是NoSQL解决方案。它们的范围从非常简单的键值存储到类似RDBMS的系统，仅剥夺了进行联接的能力。该键值存储是超级可扩展，但那是作为价格。您基本上只能查询主键。但是有解决方案，它的地图缩小。如果从累积复杂度的角度看，这似乎不是很理想，但是必须记住，它是大规模并行运行的。

如果您想通过实际示例阅读有关可伸缩性的更多信息，请访问HighScalability.com博客。

可伸缩性是根据某些变量根据吞吐量来衡量的。例如，X个用户的每秒请求数。描述可伸缩性的最简单方法是：

负载增加时的效率度量。

在设计可伸缩性时，您需要了解的第一件事是哪种测量对您的应用程序最重要？衡量效率的几种方法是可伸缩性的关键组成部分：

• 每秒并发请求
• 每个请求的平均响应时间
• 每秒/分钟处理的记录数

可以使用更多的效率度量，但是这些度量对于基于Web的系统或批处理系统来说是常见的。

可扩展性的下一个方面是衡量随着负载增加效率发生了什么变化。增加负载的常见方法是：

• 更多的用户访问服务器（即更多的网络流量）
• 数据库中的数据更多（即查询需要更长的时间，或处理需要更长的时间）
• RAID中的硬盘故障（存储性能/可靠性受到影响）
• 网络饱和

可扩展应用程序的目标是在处理负载问题时保持或提高效率。简而言之，如果响应时间过长，是否可以添加另一台服务器来平均分配负载？这种方法减少了一台服务器要做的工作量，并使服务器在该“最佳位置”运行以提高效率。

您的应用程序将需要专门设计来按比例缩放。这意味着您必须小心会话数据，将请求路由到正确的服务器，减少瓶颈，这些瓶颈限制了应用程序扩展的能力。

当您增加用户数量和/或处理更大的数据集和/或以更多语言提供界面时，您基本上希望避免性能瓶颈。

您基本上会看一下数据库架构，算法和软件开发过程，并尝试预测未来的问题。您还希望设置性能监视以在问题开始累积时发现问题。

当我阅读《构建可伸缩网站》（链接到亚马逊）时，我学到了这些技巧。

希望这可以帮助！

应用程序真正可伸缩的唯一方法是不受任何无法通过的限制（或者非常昂贵）。

一个典型的例子是，当可用的CPU周期用完时会发生什么？如果您的程序是多线程的，则可以在具有多个内核的盒子上运行，但是当您不能再购买更大的盒子时会发生什么呢？您的应用程序再也无法增长，因此无法扩展。

任何真正可扩展的应用程序都必须能够以透明的方式分布在多台计算机上，并且这样做必须没有明显的障碍。这并非易事，这是Google如此成功的原因之一。

支持大型应用程序存在一些独特的问题。职位发布正在寻找在那种环境中工作并且必须解决此类问题的申请人。

通过不断问这个问题，如果要求这段代码在非常短的时间内运行数千次会发生什么，那么从高级应用程序开始就可以扩展。这意味着管理您的内存占用量，利用总计和数据的缓存，使用自身可扩展的数据源等。

如果您正在构建一个搜索功能，当该功能在数据库中有100行要搜索并且有10个用户同时使用时，该功能运行良好。当100个用户同时使用它并且要查找10万行时，它的性能如何。

如果它执行相同的功能，那么它就非常好。如果执行的结果与用户/数据量成正比（意味着数据要多10倍==处理时间要长10倍），那就太好了。如果执行得越低，它拥有的数据越多（要处理的10倍模式数据== 10x ^ 10更长），则扩展性就不好。

我的示例确实应该以Big O表示法显示，但是我目前还不太了解用Big O编写示例。

您可以通过将虚拟数据转储到数据库中来模拟更多数据，并且有一些工具可以模拟更多用户，例如Apache AB。