[本文由 Les Worley 撰写。]
你知道那种感觉。您正在冲浪，然后 BAM！ 你得到了可怕的
503服务不可用）
服务器当前不可用（因为它超载或
由于维护原因而关闭）。
您还记得上次发生的事情时您在搜索什么吗？或者你 会 从哪家公司购买？可能不会。
更糟糕的是，如果您刚刚点击“提交订单”并等待…… 然后 出现这样的错误……您是否知道订单是否成功，或者您的信用卡是否被扣款？
商家很可能会永远失去您这个客户。你在谷歌上搜索了其他人并且从不回头。
当然，作为开发人员，您 希望 您的服务被大量使用。否则，有什么意义呢？但负载取决于很多因素：一天中的时间、月末处理、通宵批处理、新闻发布、产品发布——应有尽有。
那么如何确保 您的 API 能够处理最重的负载呢？你如何让你的顾客不走开？
不要因不可靠的 API 而失去权威
从消费者的角度来看，这只是 API 服务 无法处理负载的一个例子。结果导致客户流失。
当您发布 Web 服务时，您希望成为每个人都视为权威的人——尤其是当他们付费使用 API 时。
也许您的 API 仅供“内部使用”。但总有人依赖结果。也许网络团队使用您的 API 来搜索您公司的产品目录。然后他们将结果显示给您的客户。繁忙的服务器，没有结果——没有销售。也许您的 API 毕竟不是内部的。
无论哪种方式，您最不想看到的就是让您的用户尖叫错误，例如
- 暂停服务
- 连接被拒绝
- 服务器超时
- 或者“发生未知错误”
如果您是服务的 消费者 ，例如金融交易 API，您希望您的应用程序处理 API 抛出的任何异常。但作为 API 发布者 ，您有责任确保您的 API 能够处理繁重的负载，这样它就 不会 抛出这些异常。或者，如果是这样，它会以一种定义明确且记录在案的方式优雅地进行。
如果你不能保证你的用户在重负载下的可预测性，你就会失去这种权威。他们会付钱给其他人以获得更可靠的 API。
换句话说，您需要对其进行测试。
对 API 进行负载测试的典型方法有 3 种。这些以及各种混合动力车各有缺点。
#1 伪造它——API 模拟
对 负载测试 最无用的是 API 模拟。这些基本上是 API 开发期间使用的临时占位符。开发人员将这些用于早期单元测试。但他们也向其他需要从他们自己的代码中调用未完成的 API 的团队提供这些“虚拟”版本。
模拟返回硬编码的响应，其格式在开发过程中经常发生变化。他们身后几乎没有“肉”，只有可以提供的罐头回应
马上起来。而且它们是一次性的——一旦实际的 API 完成，代码就被丢弃了。换句话说，创建模拟的工作在首次使用后就被浪费了。
而且由于模拟尚未连接到实际数据源，因此它们的性能根本不能代表现实世界。
总之，模拟可能对单元测试有用，但它们不能代表现实世界。
#2 克隆它——一个完整的测试环境
模拟 API 方法假定 API 实际上并不完整，或者没有可用的实时数据源。如果 API 完整并准备好进行测试，我们可以使用克隆方法。这种方法使用生产数据的快照来建立一个成熟的测试环境。
通常您还会拥有所有正在运行的应用程序的副本，因为您的代码依赖于其他 API，而不仅仅是数据库查询。
这种方法的好处是它非常能代表实时系统的性能。如果您的负载测试使系统崩溃，没问题！它不会伤害任何人。
坏的部分胜过好的部分。一方面，生产数据通常包含敏感的客户信息，因此数据隐私法规可以发挥作用。此外，如果您自己的 API 使用按使用付费的服务，则此测试可能会变得非常昂贵。最后，生产数据是有状态的，即使在克隆环境中也是如此。如果您需要重新运行测试，则每次都必须重新加载测试台。
总之，克隆环境可为您提供接近生产质量的负载测试结果，如果您的测试导致生产崩溃，则不会损害生产。但是，它们会引起隐私问题，需要不断重新加载数据，并且如果调用第三方 API 可能会非常昂贵。
#3 进入生产环境——负载测试实时 API
可悲的是，许多公司使用的方法是对生产本身进行测试。为什么？嗯，它是活的，所以它是所有方法中最具代表性的。它也很“简单”——无需建立和维护单独的测试环境。但这就是有用性结束的地方。
在生产中，您不能使用“真实”数据。相反，您必须维护单独的“测试帐户”。在真实环境中使用测试帐户可以在一定程度上减少隐私问题。当然，这些数据是有状态的，因此您必须在每次测试运行之前重置它们。而且您仍然需要担心按使用付费的 API 的成本。
将负载测试安排在“下班时间”很重要。这可能很棘手，因为互联网允许您的客户全天候 24/7 访问。即便如此，如果您的负载测试导致服务器宕机或破坏生产数据， 您就会被解雇 （或者您很快就会希望自己被解雇）。
请记住， 服务不可用会 向您的客户和 他们的 客户表明您的网站或您的 API 服务不可靠。
#4 API 虚拟化——无风险的方法
您想要对您的 API 执行详尽的负载测试 - 并保留您的现有客户 和 您的工作。这排除了对生产系统的影响。
在克隆环境中，您还需要的不仅仅是 API 的测试版本。您需要在可以控制测试方面的负载条件的环境中测试真实的 API。
这就是
API 虚拟化的用武之地
。虚拟 API 提供了一个沙盒环境，您可以在其中模拟网络带宽、服务器和数据库连接、并发用户等环境负载。
通过 API 虚拟化，建立和测试 API 所需的资源最少。您测试 API 本身， 而不是 测试端到端应用程序及其所有必需的后端系统。这消除了对生产环境的克隆的需要。这意味着您不必再重置和重新加载下游数据。
数据输入和数据输出可以像您希望的那样真实。您可以创建自己的请求和响应以进行测试，或者捕获和存储来自已知来源的 实际请求和响应 。可以在负载测试期间回放数据，按您希望的快慢触发请求。
还有那些按使用付费的 API？您也可以将它们虚拟化，模拟实际 API 可能引入的各种响应和延迟。
结果？您可以单独测试您的 API，在各种负载条件下衡量对真实数据的反应。您可以对其进行微调，直到它以优异的成绩通过。不需要或损坏生产系统。
不要屈服于压力
在生产中敲打 API 来模拟繁重的请求负载是不明智的。您最终可能会激怒并失去真正的客户，更不用说您的工作了。更不用说影响无数的下游系统。
API 虚拟化允许您在与系统其余部分隔离的情况下对 API 进行负载测试。通过配置请求和响应——或捕获真实的请求和响应——你的 API 可以响应各种请求和任意数量的响应——好的和坏的。通过完全控制测试条件，您可以模拟网络负载、最大连接限制、延迟和现实世界中发生的其他条件。
了解您的 API 在压力下将如何响应可以让您修复它、调整它、优化它—— 然后再 释放它供您的客户使用。
关于作者：Les Worley 是一名自由 B2B 撰稿人，在商业软件开发、IT 和项目管理方面拥有近 30 年的经验。他专门为技术公司提供战略性 B2B 内容。您可以通过
Les@LesWorley.com
或通过他的网站
www.LesWorley.com
与他联系