服务虚拟化-超越现实-第十章：最佳实践3：改进性能和扩展性.docxVIP

第十章 最佳实践3：改进性能和扩展性 在大多数企业中，性能组在预算和聘请专家方面的需求的优先级高，因为赌注是非常高的。性能团队通常是最后一道防线，确保不在市场上输掉游戏。 你需要感受到性能是多么关键。我们正在谈论的客户不只是上传最新搞笑图片到社交媒体的网站，他们正在运行的应用程序，处理着重要的业务。如果没有高性能，系统维持不了多长时间，无法扩展以满足不断增长的客户需求和要求。 虚拟化性能环境：难道你就等着失败？ 性能可以成就或毁掉一个应用。我们需要动用一切力量，确保即使是在不断变化和动荡的使用环境中，我们的软件可以持续扩展和保持高性能。 但几乎所有人，甚至是软件社区中很多非常聪明的人，仍然将性能测试看做“事后”的活动。在一定量的负载[每秒事务数（TPS）或多个“虚拟用户”]，我们运行一个完成或接近完成的应用，并对于每个请求记录应用的响应时间。 这种想法是确认我们的应用的速度是否满足合同服务水平协议（SLA）*或只是一个客户满意的目标： “我们已经确定，当网站的响应时间大于3.0秒，用户离开我们的站点25％的更频繁，所以确保它不会超过2.0秒。” “我们竞争对手的客户利率报价时间为2.5秒。我们需要更快一点。“ “如果被测应用在1,000 TPS，1小时的负载测试中最大响应时间小于500ms，它就通过客户的SLA协议。”如果性能测试和监控确认总能满足我们的目标，那就太好了。但是，如果性能失败了呢？ 因为传统的性能测试是从最终用户界面的角度来看的，它只能告诉我们什么有问题，但无法知道问题出现在复合应用程序哪里或如何解决它。你可以“调整”的网页做法的只有这么多，可能通过降低图像大小或改变网页的HTML如何加载。大部分的业务逻辑在机器对机器交易中体现。验证和调整应用性能的普遍做法是在上生产之前，只是这时对性能能作出任何实际改善的能力已经很有限了。 开发者试图要敏捷，在早期做更多的测试，在功能和单元测试中捕捉一些结构性的代码错误和缺陷。但是，当开发人员检查一段将成为一个性能缺陷的代码时，往往不可能检测到，直到几个月后，在实际环境的综合压力（图10-1），下才露出它狰狞的面目。 此外，性能实验室经常会闲置，坐等其他人完成他们的软件发布和整合。在多个串行开发周期结束是，只剩下不得不匆忙进行性能测试的问题。 图10-1。使用桩进行开发致使性能缺陷逃脱。当开发人员只进行“单元测试”，并在早期阶段编写模拟存根，他们可能意识不到他们正在将性能较差的代码检入到项目中。这些缺陷逃逸到后期甚至会导致生产上的性能问题，此时修复缺陷的代价是非常昂贵的。 服务虚拟化解决这一难题提供了积极的解决方案，并会彻底改变你的观点，应如何对当今的组合应用进行性能测试。 组件级性能预算 如果一个性能缺陷将要发生，我们需要将其隔离，并在很早的组件级测试中发现它。这似乎是不可能的，因为许多性能测试滞后都是因为与实际系统的交互，，直到集成或部署时才会浮出水面。让我们用SV去耦这些系统，并当它们组合在一起时还可以主动查看它们的性能。 我们称之为性能预算的技术，可以在令人难以置信的大量的分布式组件和团队对当前的组合应用进行变更时，使团队以一致方式实践性能工程。要优化应用的整体性能，必须将响应时间分解后，下发“预算”到每个组件。 我们也把服务水平这种概念进行分解。预期的服务水平必须被分解成更小的单元，然后进行验证，并在组件级别执行。 如图10-2的所示例子。一家领先的电信运营商客，在对接近完成的解决方案进行性能测试时失败。在顶行，我们看到了完整的解决方案（由验证，查询和报价等步骤组成）总共响应时间为4.0秒，这超过了2.1秒的SLA。接下来会发生什么？团队一般投入更多的硬件来解决该问题，也许是在测试实验室中安装更多的服务器，内存，存储等。但往往还是不行，这解决不了根本问题。 详细说明：性能测试团队拟投资于技术，以便更好地发现问题“根本原因。问题是这就像大海捞针，性能预算可以让你在非常小的地方找到针，并与开发团队要解决的任何其他问题一起解决。 快进到时间线下方“之后”的例子，显示了团队如何分解SLA到解决方案的的每一块，解决其自身的“性能预算” 并在组件级别进行优化。 SV允许团队通过模拟组件周围的依赖关系分离每个组件（预期的或观察到的响应时间）。 图10-2。使用服务虚拟化进行性能预算。服务水平协议（SLA）通常只需要一个总的响应时间（顶端），因此传统的性能测试只能猜测的性能下降的根本原因或是推荐更多的硬件。通过分解服务水平到单个团队，他们可以在虚拟服务上下文中进行组件级测试和并在开发的早期修复性能不佳的组件。 使用这种方法，例如，你可以判断该定价程序是否对整体解决方案提供响应时间。因为你对响应时间设置了预算，你可以在隔离环境下单独采取纠正措施来优化每个组件，速度更快，并且基础设施成本