开发者要应对各种各样的问题。有时候应用会出现开发过程中没出现过的问题，出现这种功能性问题一般是因为软件没在真实世界中测试过，或是因为负载太高，导致系统压力过大。

因此，一定要在发布应用前进行可扩展性测试，确保应用能适应用户和负载的增长。

本文重点介绍可扩展性测试（计算机学家称之为压力或性能测试）以及如何在不影响用户使用体验的基础上进行测试：

1. 什么是可扩展性?
2. 垂直与水平可扩展性
3. 弹性与可扩展性
4. 什么是可扩展性测试?
5. 向上与向下可扩展性测试
6. 可扩展性测试的优缺点
7. 可扩展性测试的属性
8. 如何进行可扩展性测试
9. 用声网扩展 RTC 应用

什么是可扩展性?

可扩展性是指软件能适应不断增加的工作量的能力。它决定了一个系统可以处理多少个并发用户和请求。如果你想扩展实时语音、视频或聊天应用程序，就必须使用可扩展软件。如果软件没有可扩展性，操作就会受到限制。

例如，一个电商网站在大促销期间需要扩展至容纳 10 万个并发用户，否则就会影响产品售卖，或者会拖慢系统，进而影响客户体验。而且，可扩展的软件架构可以防止由于系统放缓而产生的安全缺陷和漏洞。

垂直与水平可扩展性

可扩展性可以分为水平可扩展性和垂直可扩展性。

水平可扩展性，或称扩展，是指在系统中增加更多的组件或资源以适应增长的需求。例如，一个公司在现有服务器的基础上增加服务器，以分担系统的负载。水平扩展最简单也最昂贵，硬件增多也会增加维护的难度和成本。

垂直扩展性指的是提高应用程序现有组件的容量或性能。垂直扩展比水平扩展便宜，因为不需要大量投资硬件，但垂直扩展更复杂，因为垂直扩展容易导致兼容性问题和组件堆积，进而影响系统性能，导致输出更加缓慢。

如上所述，可扩展性主要是硬件问题，可以通过添加更多的服务器或升级组件使应用程序具有可扩展性。同时，也可以通过软件来解决，可以通过良好的编程实践来优化代码，使其更有效地运行，在消耗更少资源的基础上容纳更多用户。

另外，还可以使用基于云的解决方案。云平台根据需要分配资源（如 CPU 和存储），从而实现纵向扩展，还可以让应用程序更有弹性和可扩展性。

说到这里，弹性和可扩展性的区别是什么呢？

弹性与可扩展性

不提及弹性的可扩展性讨论是不完整的。两者有些类似，但含义略有不同。

可扩展性是指系统的负载随着时间的推移而逐渐增加。例如，如果一个企业的客户在稳步增长，网站就需要不断扩大规模以适应增加的需求。可扩展性设定了系统可以容纳的工作负荷阈值。它本质上是主动的，需要提早考虑到未来的需求并提前扩大规模，以确保运营能不间断地进行。

弹性是指系统增加和减少资源以适应动态负载的能力。换句话说，它指的是系统适应激增或骤降的需求的灵活性。例如，一个电商应用程序在黑色星期五或圣诞节等高峰期可能需要应对 500,000 个并发用户，但在一年的其他时间里只需应对 50,000 个用户。这种情况下，弹性系统可以在高需求期间分配资源，在低需求期间释放资源。

如果使用的是按使用量收费的基于云的系统，那么弹性至关重要。它可以确保你在低负载期间无须为闲置资源支付过多费用，还可以将资源分配给更需要的应用程序。

了解弹性和可扩展性的区别（以及何时适用）至关重要，因为实现弹性和扩展性的解决方案不同。

可扩展的架构需要“传统”的扩展方法，如增加更多的服务器或提高现有机器的规格。这两种解决方案都能永久地增加系统的负载能力。

弹性架构需要做到实时分配资源。并非所有云服务都支持实时分配资源，所以大家可以先配置那些支持实时分配资源的云服务，使其具有弹性。

最后一个不同是，弹性系统必然是可扩展的，但可扩展系统不一定是弹性的。

什么是可扩展性测试?

可扩展性测试是一种非功能性软件测试，测试的是应用程序或系统在不同的用户负载下的性能表现，目的是测试系统在设定的负载下是否会崩溃，以便进行修复。

可扩展性测试通常是预测到负载增加（因用户、交易、流程和其他系统增加）时进行的。这个测试可以找出系统中待改进的地方，保证网站或应用程序能稳定运行。

可扩展性测试与负载测试类似，都是根据应用程序的负载能力来评估其性能，但两者之间有一个重要的区别。

负载测试是让系统一次性承受最大的负载来找到系统的突破点。它的主要关注点是性能问题。

可扩展性测试是逐步进行的，目的是搞清楚系统在某些负载水平下出现某种情况的原因，并给出改进意见，这个测试主要是要找出系统能容纳目标数量的用户或交易的原因。

向上与向下可扩展性测试

可扩展性测试还可以分为向上可扩展性测试和向下可扩展性测试。

向上测试包括向应用程序添加虚拟工作负载，直到达到一个突破点，目的是确定系统能处理的最大容量。

向下测试则相反，从高的工作负载开始逐渐减少，直到达到最佳负载水平。向下测试通常在向上测试之后进行，或者是在应用程序未能通过首次可扩展性测试之后。

可扩展性测试的优缺点

优点

为什么可扩展性测试对企业的成败如此关键？我们一起来看看定期可扩展性测试的商业优势。

可扩展性测试可以及早发现错误，在发布软件或扩展软件之前修复错误。这样不仅能优化产品，还可以降低成本。根据 1-10-100 法则，在开发过程中修复一个错误的成本是 10 倍，而在发布软件后该成本高达 100 倍。

可扩展性测试也可以帮我们确定需要的计算资源的确切数量，以满足预期需求，有助于避免在新硬件或基础设施投资上的过度支出。

归根结底，可扩展性测试是为了提供最佳的用户体验。如果系统负荷过大导致出现崩溃、反应迟缓和速度减慢等问题，就会严重影响用户体验，最终失去用户。

可扩展性测试可以测试系统并检查其响应能力，从而及时发现性能瓶颈，在旺季之前解决这些问题。

缺点

可扩展性测试会花费时间和成本，尤其是较大的应用程序。完善的可扩展性测试需要相当长的时间才能完成，可能会延迟应用程序的发布，或导致产品成本超出预算，因此，在进行可扩展性测试之前，一定想好是否有必要做这个测试。如果一个企业软件有数十万并发用户，那么做这个测试可能是必要的；如果只是一个用户数量非常有限的简单应用，可能就不必如此大动干戈了。

差异

另外要注意的是可扩展性测试并不是一个完美的解决方案。测试环境不可能百分百反映生产环境，总会有一些无法预先知道也无法复制的情况。

这些“未知”的负载都可能会导致测试结果比实际情况好。同样的，如果可扩展性测试的范围有限或指标测量错误，也会造成以上结果。

可扩展性测试的属性：我们测试什么?

我们可以用可扩展性测试评估许多不同的变量，具体选择哪一个变量取决于应用程序和基础设施的性质。常见的衡量标准包括以下内容：

响应时间

响应时间是指用户执行一个动作（如点击按钮或提交表格）到从应用程序收到响应之间的延迟。

响应时间的最基本的测量方式是，当用户点击链接或在浏览器上输入 URL 时，网页加载的时间长度。这是可扩展性测试最重要的指标之一，因为响应时间与用户体验密切相关。如果响应时间过长，用户就会觉得应用程序反应很慢甚至“出现故障”。

响应时间长的最常见原因是服务器延迟，而这通常就是可扩展性测试要研究的问题。具体来说，可扩展性测试的目标是在响应时间变得过慢之前，确定网络能够支持的最大用户数量。

一般来说，用户的数量越多，响应时间就越长。这很好理解，用户数量越多，服务器要处理的并发的用户请求数量就越多。如果用户在地理位置上离服务器较远，也会带来响应时间的延迟。

响应时间在云或混合环境中略有不同，因为工作负载通常分布在多个服务器之间。这种情况下，可扩展性测试能测试负载平衡器在确保每个服务器不被过多请求占用的有效性。

在分布式架构中，测量每个服务器组件的响应时间也可以。不然，无论应用程序的负载如何，都需要测量整体的响应时间。

改善响应时间过长的最好方法是优化网络，如使用内容交付网络（CDN），其功能是将数据传播到全球各地，减少用户和服务器之间因地理距离造成的延迟。

过长和过于复杂的代码也会延长响应时间。即使只是几秒钟的延迟，乘以数以千计的用户，也会导致速度显著下降。优化和简化代码和脚本可以加快服务器的处理和响应时间。

吞吐量

吞吐量衡量的是应用程序在设定的时期内可以处理的请求或进程的数量，这个变量因具体应用程序而异。

例如，网站吞吐量可能是服务器在一小时内可以处理的网页请求的数量，数据库吞吐量可能是每分钟可以处理的 SQL 查询数量。

一般来说，无论系统服务器的负载是多少，吞吐量都不会改变。举个例子，一家快餐店每分钟可以为十个顾客服务。就算有成千上万的顾客在外面排队也一样，它每分钟仍然只能服务十个顾客。因此，在进行可扩展性测试时，开发人员通常会定义应用程序在各种负载下需要满足的吞吐量。

我们经常用可扩展性测试确定应用程序的上限或最大吞吐量。在测试中，我们会持续添加虚拟用户，直到吞吐量开始保持稳定。但是，如果吞吐量开始下降，就意味着应用存在更深层次的问题或应用程序进入瓶颈状态。

另一个例子是：假设你正在做一个可扩展性测试，发现应用的吞吐量在某一点急剧下降，进一步调查显示，下降的时候系统在数据库层有一个减速，那么数据库就是降低吞吐量的瓶颈。

如上所诉，吞吐量不稳定往往只是潜在问题的外在表现形式。

内存使用情况

内存使用情况衡量的是应用程序的每个用户进行每个任务消耗的内存，以字节（ 如千兆字节或兆字节）为单位。这是一个资源利用率指标，因为它衡量应用程序如何有效地使用系统资源（RAM）。

内存使用量是一个非常重要的指标，它可以决定应用程序的速度和响应程度。如果系统内存不足，就会减慢速度或使程序完全崩溃。即使是内存使用量的轻微增加，如果乘以多个用户，也会造成严重影响。

修复内存使用问题可以通过下列两个方法：

第一，内存的使用主要与编程实践相关。开发人员必须对应用程序进行编码，使其消耗的内存最小化。例如，应用程序代码应该优化对数据库的 SQL 查询，尽量减少 RAM 的使用或冗余调用。

第二，内存的使用与硬件有关。系统内存能支持同步用户请求或交易是有限的。可扩展性测试的目的就是找到这个极限。一旦达到这个阈值，进一步扩展系统就需要增加更多的内存或数据库存储。

CPU

CPU 使用率衡量的是一个应用程序需要多少处理能力来工作，以赫兹为单位衡量，如兆赫兹（MHz）。

CPU 使用率类似于内存使用率。对于初学者来说，两者都是资源利用指标，用来评估应用程序使用系统资源的效率。它也直接影响到用户体验，如果 CPU 使用率高，就会拖慢应用程序或使其崩溃，甚至会缩短 CPU 的寿命。

编程实践太糟糕也会导致 CPU 的过度使用，就像内存一样。例如，使用“死”代码或线程会导致软件使用不必要的处理能力。

与内存一样，CPU 是一种有限的资源，只能处理一定数量的任务和用户请求。升级或添加更多的服务器组件可以帮助分散 CPU 的使用，提高性能。

网络使用情况

网络使用量是一个决定应用程序使用多少带宽的指标，以字节/秒（Bps）为单位。

对于可扩展的应用程序来说，即使用户请求量很大，也应该保持很小的网络使用量。如果网络使用量过多，就会造成网络拥堵，进而导致响应时间过长，用户体验不佳。

改善网络使用情况往往需要编程实践。例如，压缩算法可以减少应用程序在网络上发送的数据大小，最大限度地减少带宽使用。

可扩展性测试可以检测网络使用的突增，这样就可以进一步调查并解决问题。但网络拥堵也可能是由其他变量造成的，比如网络类型。要排除这些变量，就需要在各种网络条件下进行可扩展性测试。例如，要具备 4G、5G 和 Wi-Fi 网络的测试场景。

如何测试应用程序的可扩展性

可扩展性测试一般包括四个步骤：

第一步，评估应用程序的当前负载，并根据用户数量增加等因素预测其负载能力。这样做可以提供一个合适的基准，从而在合理范围内进行测试。例如，如果在高峰日只看到 50,000 个并发用户，就没必要做涉及 500,000 个并发用户的可扩展性测试，这是对时间、金钱和精力的浪费。

第二步，根据你想检查的指标来设计和测试。这涉及测试方案和测试环境。一定要在单独的测试环境进行可扩展性测试，否则会干扰系统的运作。测试环境要尽可能地反映生产环境和硬件规格，以确保准确的结果。

最好选择可靠的可扩展性测试工具。可以研究一些示例，如 Apache Jmeter、LoadNinja、Load Impact、Load View 和 NeoLoad。测试场景是一系列可重复的软件任务，你会用这些软件任务来测试系统的可扩展性。通常情况下，这些任务是应用程序在“最繁忙”状态下的最密集的处理器任务。例如，一个图形处理软件的像素计算算法，它占用了大量的 CPU 和 RAM。理想情况下，要在代表不同状况和不同负载水平（低、中、高）的单独的场景中检查应用程序的响应，最简单的是在测试中设置虚拟用户的数量。例如，你预计高峰期有 50 万名网站访问用户，那么就可以用 50 万个虚拟用户来验证应用程序是否会崩溃。

第三步，测试环境和脚本准备好就开始执行。最好的方法是定期测试。如果你是在分布式环境中进行测试，请务必检查负载平衡器是否利用了多个服务器，避免出现服务器过载。

最后，记录和分析执行测试后的结果，包括相关指标，如吞吐量和网络使用。弄清楚应用程序在哪个负载级别出现故障，实施一些改变，并重新运行测试场景以验证情况是否改善。

用声网扩展实时通信应用

可扩展性对于实时通信应用至关重要，它可以避免视频迟缓和通话滞后等故障，保证用户体验。

作为提供无缝实时语音聊天和视频聊天功能的领导者，声网可以提供卓越的用户体验。有了声网的超强可扩展性，你的应用程序就可以轻松处理突发的流量高峰，在实时视频推流中同时支持数百万个并发用户。

欢迎大家使用声网的全球边缘网络扩展应用程序，让你的应用更顺畅。

想了解更多信息，欢迎访问声网官方网站。

原文作者：声网团队
原文链接：https://www.agora.io/en/blog/scalability/