日常测试失败在哪？
幸运的是，我们有很多工具来测试高负荷条件下的软件行为，也可以帮助识别工具性能和可扩展性存在的问题。而其他基准测试工具也可以要求测试系统在高负荷下提供系统稳定性的测试。然而，当我们尝试使用这些工具来测试企业产品的性能时，我们遇到了性能和规模工程的问题。一般来说，这些产品不是单一的应用程序，而是由几个不同的应用程序相互交互，以提供一致和统一的用户体验。

如果我们只测试它的单个组件，我们就不能获得关于产品性能和可伸缩性问题的任何有意义的数据。只有在实际场景中测试应用程序，即把整个企业应用程序置于实际工作负载中，才能收集真实的数据。

问题是：我们如何能够在一个测试场景实现这一现实的工作量？

容器--救援集装箱

答案是容器。为了解释容器如何帮助我们测试产品的性能和可伸缩性，我们来看一个软件配置管理工具puppet。Puppet使用C5体系结构，其中有一个或多个Puppet主机（服务器），以及使用Puppet运行Puppet代理（客户端）配置的系统。

为了理解应用程序的性能和可伸缩性，我们需要在不同系统上运行高负载的puppet-master。为此，我们可以在一个系统上安装puppet-master，然后运行我们的操作系统的多个容器，在这里，我们安装和运行puppet-agent。

接下来，我们需要配置puppet-agent与puppet-master进行交互，以管理系统配置。这在服务器处理请求时强调服务器，并在客户端更新软件配置时强调客户机。

那么，容器在这里能起到什么作用呢？我们能不能只通过一个脚本模拟的Puppetmaster负载？答案是否定的。即使模拟了负载，我们也会对产品性能有不够客观的判断。在现实生活中，除了puppet-agent或puppet-master之外，用户系统还将运行许多其他进程，其中每个进程消耗一定数量的系统资源，因此直接通过限制puppet可以使用的资源来影响puppet的性能。

这是一个简单的例子，但是在处理多个组件组合的产品时，企业应用程序的性能和规模工程可能会变得脆弱。这就是容器的优势所在。

为什么是容器而不是别的？

一个真正的问题是：为什么要使用容器而不是虚拟机(VM)或仅仅是裸机？运行容器背后的逻辑与我们可以启动的容器图像的数量有关，还有它们相对于替代品的成本问题。

虽然VM提供了强大的机制，但它们也会占用巨大的系统资源，从而限制了可以在单个裸机服务器上复制的系统的数量。相比之下，在同一个系统上启动1000个容器是相当容易的，这取决于您想实现什么样的模拟，同时维持较低的开销。

使用裸机服务器，性能和规模可以根据需要实现，但一个主要问题是成本开销。你会购买1000台服务器只是为了进行测试吗？这就是为什么容器总体上提供了一种经济的和可扩展的方法来测试产品在实际情况下的性能，同时还能保持较低的资源成本和开销成本。

作者：SaurabhBadhwar
原文链接：https://opensource.com/article/17/8/containers-software-performance-and-scale
刘妮娜译