领先一步
VMware 提供培训和认证，助您加速进步。
了解更多虚拟化与企业 Java
如果您想从战略层面了解 VMware 最近宣布收购 SpringSource 的影响，有几个很好的来源，包括 VMware 首席技术官 Steve Herrod 的博客文章、Rod Johnson 的评论、Paul Maritz 的新闻和分析师电话会议，以及 Darryl Taft 在 eWeek 上的深刻文章。
在这篇文章中，我将更多地关注这在技术层面意味着什么，以便让您了解可以期待哪些功能。
首先，让我重申，我们开源项目和SpringSource产品服务**没有任何变化**。没有任何变化，这意味着我们将来会有更多机会为其添加激动人心的新功能。Spring 3.0即将推出，我们刚刚发布了里程碑4。dm Server正在快速向2.0版本迈进，我们为即将发布的tc Server准备了一些非常酷的功能。Eclipse对Groovy的工具支持引起了广泛关注，Grails正在努力推出1.2版本，我们的Spring项目也正在发生令人兴奋的事情。所有这些都将持续快速进行。
蓝图的力量
每个由Spring支持的应用程序都有我们称之为“应用程序蓝图”的东西。此蓝图包含构成应用程序的所有组件（Bean）的描述、它们的配置和连接方式、它们与周围环境的交互方式以及安全性和事务等跨领域关注点的处理方式。蓝图在运行时由BeanDefinition集合表示。BeanDefinition来源于各种来源，包括XML定义、注解、JavaConfig、Groovy DSLs以及任何可以插入Spring的其他配置机制。Spring容器的任务是获取您为应用程序指定的蓝图并“使其实现”。应用程序蓝图让Spring对应用程序的运行方式有了高度的洞察力。我们稍后会回到这个想法...当一个由Spring驱动的应用程序部署到生产环境时会发生什么？在典型的场景中，有多个协同工作的组件需要配置和连接。例如，一个http服务器在tc Server实例集之间进行负载均衡，而这些实例又与主/从配置的数据库通信。这些（中间件）组件构成了应用程序的逻辑层（现在使用“大型”应用程序一词）。逻辑层在实际部署中映射到物理层（例如，您可以在同一台机器或不同机器上部署数据库和应用程序服务器）。当这个术语首次发明时，物理层确实是物理的。但如今，您的物理层当然可以是虚拟的，而这些虚拟机又映射到物理资源.....我跟上你了吗？
正如我们有一个描述Spring驱动应用程序组件及其如何协同工作的应用程序蓝图一样，部署蓝图也可以描述给定部署场景的组件——有哪些组件，它们如何连接和配置，以及如何处理安全性和（反）亲和性等跨领域关注点。作为起点，有一些常见的部署模式（例如我前面提到的tc Server集群示例）可以被捕获到目录中。随着时间的推移，您可以想象一个运维团队通过他们自己的自定义应用程序部署蓝图来扩展该目录。
从部署蓝图到vApp
将应用程序投入生产应像开发应用程序及其关联的应用程序蓝图一样简单，选择适合应用程序样式（例如Web应用程序、批处理、集成等）的部署蓝图，然后单击“部署”。您已经可以通过CloudFoundry对Amazon EC2上Web应用程序部署蓝图的支持，看到这种模型在实践中的早期示例。VMware vSphere包含对vApp概念的支持。vApp是“一个包含一个或多个虚拟机的逻辑实体，它使用行业标准的开放虚拟化格式来指定和封装多层应用程序的所有组件，以及与之相关的操作策略和服务级别。”
vApp 是部署蓝图实现的完美打包单元。同一个 vApp 可以在您的数据中心和公共 vCloud 中得到支持。vApp 还可以暴露配置属性——操作员在部署 vApp 时为这些属性提供值。
从dm Server开始（请关注即将发布的2.0.0.M5版本中的更多细节），我们正在使我们的中间件能够通过vApp属性进行配置。这使得操作员在部署vApp时可以覆盖端口和其他配置设置，而无需了解虚拟机器或内部中间件组件的配置。此功能也超出了中间件组件，您还可以配置应用程序属性（将由Spring进行依赖注入），这些属性来源于操作员在部署时指定的vApp属性。
这些功能可以通过多种有趣的方式组合，但我将选择两个我认为能说明其潜力的例子：平台即服务（PaaS）模型；以及应用设备模型。在平台即服务模型中，您的数据中心或任何签署成为vCloud服务提供商的多个供应商都会提供一份部署蓝图目录供您选择。这些蓝图中的每一个都可以被视为一个平台（在PaaS的意义上），您可以将应用程序部署到该平台上。您选择要部署到的平台，相应的vApp将为您预配（可能带有Web前端，让您可以指定蓝图暴露的任何vApp属性），然后您将应用程序工件上传到已预配并正在运行的平台实例。对于使用Grails或Roo构建的应用程序，我们对应用程序结构有更深入的了解，部署蓝图选择和工件上传可以通过插件直接从Grails（或Roo）命令行进行。想想这种模型将为这些应用程序带来的托管机会！
在应用设备模型中，开发或运维团队选择一个起始部署蓝图，创建相应的vApp实例，并将应用程序工件安装到该运行系统中。到目前为止，这看起来与PaaS模型相同。但接下来发生的事情有所不同。虚拟机（现在已安装应用程序工件）被打包成一个新的vApp，并且任何可能在每次部署时发生变化的应用程序特定属性（例如，如果vApp依赖于外部数据库，则为数据库URL和密码）都被配置为vApp属性。因此，现在整个应用程序以及运行它所需的一切都打包成一个vApp（一个应用设备），可以作为一个单元进行配置（并进行版本控制）。将应用程序投入生产就变得像部署vApp一样简单——不会出错，一切都已预先打包和测试。
智能配置
希望到现在您已经开始明白，部署蓝图与vApp模型结合如何能够简化从开发到生产的路径。但这种方法不仅仅让事情变得更快更容易，它还能实现更智能的配置。如果没有Spring提供的知识，vApp只是vSphere可以在其可用的物理资源上配置的虚拟机集合。但如果配置时结合了应用程序蓝图和部署蓝图的知识，事情就会变得有趣得多。现在我们突然对应用程序和中间件组件以及它们如何连接有了一些了解，我们可以优化虚拟基础设施来支持它们。例如：
- vSphere可以自动创建vShield区域，以便应用程序服务器节点只能从Web服务器访问，并且只有Web服务器节点可以公开访问
- vSphere可以自动设置反亲和性组，以便数据库主服务器不会配置在与从服务器相同的物理硬件上
- vSphere可以根据蓝图暗示的预期流量模式优化网络配置
- ...
- 蓝图内置了Hyperic HQ管理服务器，代理程序在vApp中的所有虚拟机上运行。因为我们了解蓝图，所以可以自动创建适当的HQ组（例如，将所有tc Server作为单个逻辑资源进行管理），自动添加库存，并默认设置适当的控制操作和警报。无需手动安装和配置任何这些。
智能运行时管理
智能配置很棒，但远不止于此。vSphere包含复杂的机制，可以在运行时优化您的虚拟机和数据中心使用情况。到目前为止，这些机制在没有任何关于虚拟机试图支持的应用程序知识的情况下运行。当您将Hyperic HQ的应用程序洞察与vCenter的虚拟基础设施洞察结合起来时，就有可能创建一个组合的应用程序健康和管理模型，该模型根据应用程序SLA优化运行时。例如，如果HQ检测到来自tc Server节点的响应时间接近SLA中指定的上限，并且这与显示CPU或内存是瓶颈的指标相关，那么就可以采取多种纠正措施，包括为现有机器上的虚拟机分配更多物理资源，使用vMotion将虚拟机迁移到更强大的硬件，或者启动额外的tc Server虚拟机来分担负载。说到扩容（或缩容），伸缩点只是部署蓝图中的另一段元数据，“1..n”（或“3..8”，或您决定的任何值），用于扮演此角色的服务器。指定这些之后，只需让Hyperic HQ和vCenter协同工作，为您管理和优化服务器数量（甚至可以在暂时不需要时关闭物理机以节省能源成本）——所有这些都基于您指定的应用程序SLA和虚拟基础设施SLA。