随着云和虚拟化进入主应用平台，对水平扩展性和可用性管理的疑问随之而来。

软件架构师和CIO希望应用能持续提供优质体验。随着虚拟化和云进入到主应用平台的领地，对如何在应用和平台之间分配扩展性和可用性的问题也被提了出来。要想回答这些问题，架构师必须：

• 考虑两种方案的效能和成本
• 评估应用和平台演练控制的方法手段
• 确保两种策略的演进风险得到理解

应用开发朝着组件化开发的演进，为架构师创造设计更好的水平扩展性和可用性提供了机会，即可以为组件复制或替换提供上述能力来增强或恢复性能。如果某资源失效或超负荷了，在不同资源上启动受影响组件的一份拷贝并依靠应用的工作流引导能力，就能恢复正确的运行即可。

虚拟化和云可令此过程更加简单，但由于虚拟平台有一些原生的管理水平扩展性和可用性的能力，架构必须评估是要在这些功能的基础上进行开发，还是他们得利用平台提供的东西，或者两种同时利用。问题是扩展性和可用性与他们如何通过平台或应用处理方面是类似的，不同的是被检测到的效率。

应用组件可以设计成知道自己是否超载，只需为它提供一种监控等待它的工作的机制即可。然而，想要知道某样东西是否失效了却困难得多，因为失效的应用组件显然是没法做出决定的。

相比之下，像虚拟化管理器或云管理器这样的平台可在资源层或连接性上侦测失效，这两个都是应用很难检测到的。这意味着管理扩展性和可用性的第一步是确定如何检测问题。最起码，这要求去找出主机软件（虚拟化、云或传统服务器操作系统及中间件）能够首先识别问题的办法。

做出评估后，要注意被识别出来的机制是平台独立的。如果功能无法跨平台复制，那么就会有被锁定在特定的主机托管选择的风险上。

在评估扩展性和可用性事件的侦测时，需确保检查一下他们是如何执行的。当平台侦测到问题时，要想识别出哪些应用受影响也许并不容易，因此也很难知道该对哪些组件进行扩展。这种连接必须在处理之前建立。

一旦确定过载组件可被检测出来之后，流程就转移到整治上。通常的做法是根据需要复制或替换组件以确保QoE。但这可能也不是一件易事。

新组件如何才能集成进目前的工作流的问题需要处理。在这里，扩展性面临的挑战更大。包括了不同数量的组件实例的工作流必须分配工作。这种工作分配必须随着组件拷贝数的变化而扩大或缩小。如果进行扩展或被替换的组件是有状态的，那么负载均衡和工作流引导也必须相应是有状态的。

替换失效组件是不需要为组件或事件的每一份拷贝提供显式负载均衡。然而，当第二份拷贝被添加进来或从两份拷贝迁回一份上面时显式负载均衡就必不可少。

如果有若干特别的地方的扩展性可能是必不可少的话，为负载均衡设计工作流也许是个好主意，哪怕只有一个组件在用也如此。这会使得以后添加组件实例更加容易。

对失效或过载情况采取基于应用的检测和响应有一项优势，就是它可以在架构师的控制之下。在有平台工具的情况下使用平台工具进行替换（包括将机器镜像搬移到另一个VM）是明智之选。

为了反映出检测和处理水平扩展性或可用性事件的能力高低，可考虑创建一个通用功能或一组功能，并为不同的平台增加插件组件。这不仅能在不同环境下适应像云爆发这样的情况，还可以支持以后向不同平台的迁移。

架构师需要接受这一点，用于扩展性和可用性管理的平台工具会随着时间得到改善，而这会侵蚀到以应用为中心型方案的地盘。至少，应用将不得不适应和使用这些工具以实现用户QoE的最大化，可能会导致应用中心型解决方案的搁浅。架构师和规划师跟踪DevOps和云协调工具及标准的进展至关重要，这样才能恰当地将它们集成到应用中。此外，这还将使得组件管理和工作流管理成为可能，甚至组件设计未来也可得到优化。