在测试场景中我们如何实现真实工作负载？

　　当我们谈论应用程序开发时，软件性能和可扩展性是常见的主题。一个重要原因是应用程序的性能和可扩展性直接影响其在市场上的成功。一个应用程序，无论用户界面多么好，如果响应迟缓，将不会有多大的市场份额。

　　这就是为什么当用户群增长时，我们花费这么多时间来改善应用程序的性能和可扩展性。

　　通常的测试做法失效

　　幸运的是，我们有很多工具来测试高压条件下的软件行为。还有一些工具可以帮助确定性能和可扩展性问题的原因，其他基准测试工具可以通过压力测试系统来提供高负载下系统稳定性的相对度量。然而，当我们尝试使用这些工具来了解企业产品的性能时，我们会遇到性能和规模工程问题。一般来说，这些产品不是单一应用，相反，它们可能包含几个不同的应用程序相互交互以提供一致和统一的用户体验。

　　如果我们仅测试其各个组件，可能无法获得有关产品性能和可扩展性问题的任何有意义的数据。只有在现实场景中测试应用程序，才能收集真实数据，这意味着让整个企业应用程序处理真实工作负载。

　　问题变成：在测试场景中我们如何实现真实工作负载?

　　容器来救场

　　答案是容器。为了解释容器如何帮助我们了解产品的性能和可扩展性，来看一下软件配置管理工具Puppet。

　　Puppet使用客户端 - 服务器架构，其中有一个或多个Puppet主机(服务器)以及要使用Puppet运行Puppet代理(客户端)进行配置的系统。

　　为了了解应用程序的性能和可扩展性，我们需要让Puppet主机处理来自运行在各种系统上的代理程序的高负载。

　　为此，我们可以在一个系统上安装puppet-master，然后运行多个运行我们操作系统的容器，并在操作系统上安装并运行puppet-agent。

　　接下来，我们需要配置Puppet代理与Puppet主机交互以管理系统配置。这会在处理请求时给服务器带来压力，并在更新软件配置时给客户端带来压力。

　　容器在这里有什么帮助呢?不能通过脚本来模拟Puppet主机的负载吗?

　　答案是不能。它可能已经模拟了负载，但是我们会对其性能有非常不切实际的看法。

　　原因很简单。在现实生活中，除了puppet-agent或puppet-master之外，用户系统还将运行多个其他进程，每个进程会消耗一定数量的系统资源，从而通过限制Puppet可以使用的资源直接影响到该puppet的性能。

　　这是一个简单的例子，但是在处理结合了少量组件的产品时，企业应用程序的性能和规模工程就会变得非常具有挑战性。而这正是容器发光的地方。

　　为什么是容器?

　　一个真正的问题是：为什么要使用容器而不是虚拟机(VM)或裸机?

　　运行容器的逻辑与我们可以启动的系统容器镜像数量以及其替代品的成本有关。

　　虽然虚拟机提供了强大的机制，但它们也对系统资源造成了很大的开销，从而限制了在单个裸机服务器上可以复制的系统数量。相比之下，在同一个系统上启动1000个容器是相当容易的(这取决于你尝试实现什么样的模拟)，而且可以实现较低的资源开销。

　　使用裸机服务器，性能和规模可以根据需要实现，但主要的问题是成本开销。试想，你会购买1000台服务器进行性能和规模实验吗?

　　这就是为什么容器总体上提供了一种经济可扩展的方式来测试产品在现实场景中的性能，同时兼顾资源、开销和成本。