你的应用的设计好坏会在多云环境中对性能产生影响。使用以下这些监控和管理技术来避免应用的性能问题。
对于大多数IT组织来说，“性能”意味着响应时间或用户体验的质量。就像大多数应用一样，一个多云应用，或者一个横跨多个云平台的应用，会受到三个主要因素的影响：总体可用性，网络延迟和丢包，应用程序及其组件的处理延迟。
一个多云应用的设计在其性能表现上起到关键的作用。应用都越来越趋向于“组件化”，即应用的功能被分割成一个个独立的组件。微服务就是这种趋势的一个最新的例子，由于单独的部件可以水平扩展从而能够提高应用的处理能力，组件化被视为一种向云靠拢的方式。这句话有对也有错的地方。
组件化在云提供商和主机之间创建了一个长的，多线程的工作流。该工作流的各个环节的问题将影响用户体验的质量(QoE)。
应用性能管理的一个关键部分是衡量用户的体验质量并有一个基准来进行比较。最可靠的获取信息的途径是从最接近用户的设备或前端应用程序组件那里。如果你在一个应用程序工作流的内部来测量性能，你只会检测出和解决应用特定的那部分问题。如果软件不能在用户装置上来测量响应时间，那就手动进行测量，根据单个或一组的时序事务。“正常”或预期值将成为你的基准，任何偏差代表有问题需要确定并解决。
优化多云应用性能
当应用的性能在多云环境受到影响时，大多数企业会首先确定这个问题是否与特定的云服务提供商有关。查看云管理日志，看性能问题是否由一些云事件引起，如故障或应用实例的添加删除。如果是这样的话，问题可能与特定的云服务提供商有关，你应该在寻找多云本身的原因之前先解决这个问题。
如果问题不是某个单独的供应商造成的，则可以追踪横跨多云平台的整个应用的工作流。一个多云应用一般分为两类：一类是由云服务提供商在给定的地理区域或用户组托管的应用，另一类是用户的应用分散在多个供应商。在第一种情况下的QoE的问题会同特定的一组用户有关，这可以定位到涉及的云服务提供商。但第二种情况更复杂。
数据丢失或延迟是造成大多数应用性能问题的原因，所以必须了解工作如何在云服务提供商之间传递。有三大选择：提供商通过互联网传递工作，供应商通过自己的中央V**或通过一个专用网络互连。每种选项都需要不同的测试和修复方法。
如果通过互联网来连接工作流的话会难以监控，并且云供应商本身可能无法提供帮助。为了有效地监控工作流程在供应商之间的切换，在你的应用程序组件中构建丢失和延迟检测的功能。值得庆幸的是，许多应用都使用TCP/IP，而通过监控窗口的大小和读取中间件网络日志经常可以检测到长延迟，会表现为大的窗口或缓冲区，以及分组包丢失。
窗口/缓冲区和网络日志还可以帮助你监控内部V**或直云连接，但除此之外还有一些其他的选择。根据你的内部工具和技能来挑选合适的选项，或者考虑使用某个集成商，厂商或云提供商的专业服务，来设置你的应用便于监测。
如果你的多云应用工作流是通过V**在供应商之间连接的，使用一个数据监控探头来查看实际的数据包流。在某些情况下，你会发现一个延迟或损失的直接证据。同监控供应商进行核查，确保你可以得到所需要的数据并让理解数据包流的工作人员对结果进行解释。
还可以在云供应商的边界点将一个软件探测器插入到应用工作流。有一些监控的标准，如RMON，但厂商也会提供专门的测试和监控工具，这些工具可以提供更好的功能。尽可能的在探测器的级别上分析，而不是创建一个监控包流然后发送回远程位置再进行分析。第二个模型会引入自己的延迟和变化，往往掩盖了真正的问题。
找出一个多云模型中应用性能问题的根源，最好的办法是在组件的级别上或者至少在工作流跨公有云提供商的边界处将该能力构建到应用程序中。事务的序列号和时间戳可以提供可靠的数据包延迟和丢失数据，网络和云供应商都接受此信息作为问题的指示。
为了修复与多云应用性能相关的任何问题，将证据交给你的云和网络供应商，并与他们一起找到解决的方法。目标是要将你的性能问题关联到一个供应商可以修复的场景下。在某些情况下，你必须支付一个优质的服务，以提高性能，所以不要认为这是个能够由云供应商搞定的“问题”，你也得参与到其中。
