云应用程序的性能测试和反模式

性能反模式（与设计模式类似）是组织中常见的有缺陷的流程和实现。 这些常见做法可能会导致应用程序面临压力时出现可伸缩性问题。 了解这些做法有助于简化软件从业者之间高级概念的沟通，在查看代码或诊断性能问题时，反模式知识可能会有所帮助。

下面是一个常见方案：应用程序在性能测试期间表现良好。 然后，该应用程序被发布到生产环境，并开始处理实际工作负荷。 此时，它开始性能不佳—拒绝用户请求、停止或引发异常。 然后，开发团队将面临两个问题：

• 为什么在测试期间未显示此行为？
• 我们要如何解决呢？

第一个问题的回答很简单。 很难在测试环境中模拟真实用户及其行为模式以及他们可能执行的工作量。 了解系统在负载下的行为方式的唯一完全确定方法是在生产环境中观察它。 为了清楚起见，我们不建议跳过性能测试。 性能测试对于获取基线性能指标至关重要。 但是，在实时系统中出现性能问题时，必须准备好观察和更正性能问题。

第二个问题的回答，如何解决问题，不太简单。 任意数量的因素都可能会造成影响，有时问题仅在某些情况下出现。 检测和日志记录是查找根本原因的关键，但还必须了解要查找的内容。

根据我们与 Microsoft Azure 客户的互动，我们确定了客户在生产中看到的一些最常见的性能问题。 对于每个反模式，我们描述了反模式通常发生的原因、反模式的症状以及解决问题的技术。 我们还提供演示反模式和建议的可伸缩性解决方案的示例代码。

当你阅读说明时，其中一些反模式似乎很明显，但它们的发生频率比你可能想象的要多。 有时，应用程序会继承一种在本地部署时有效但无法在云中扩展的设计。 或者应用程序可能从非常干净的设计开始，但随着新功能的添加，其中一个或多个反模式会逐渐出现。 不管怎样，本指南都会帮助你识别和修复这些反模式。

反模式目录

下面是我们识别的反模式列表：

反模式	说明
繁忙数据库	将过多处理任务转移到数据存储。
繁忙的前端开发	将资源密集型任务移到后台线程上。
琐碎 I/O	持续发送大量小型网络请求。
超量提取	检索的数据量超过需要，导致不必要的 I/O。
不当实例化	重复创建和销毁设计为共享和重复使用的对象。
单一式持久保存	对使用模式非常不同的数据使用相同的数据存储。
无缓存	无法缓存数据。
喧闹的邻居	单个租户使用不成比例的资源量。
重试风暴	过于频繁地重试对服务器的失败请求。
同步 I/O	I/O 完成后阻止调用线程。

后续步骤

有关性能优化的详细信息，请参阅 Well Architected Framework 中的 性能效率