领先一步
VMware 提供培训和认证，助力你快速进步。
了解更多虚拟化与企业级Java
如果你想从战略层面了解VMware最近宣布收购SpringSource的意义，有几个不错的来源，包括Steve Herrod（VMware首席技术官）的博文、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）的描述，它们的配置方式和连接方式，它们如何与周围环境交互，以及如何处理安全性、事务等横切关注点。在运行时，蓝图由一系列BeanDefinitions表示。BeanDefinitions来源于各种来源，包括XML定义、注解、JavaConfig、Groovy DSL以及任何其他可以插入Spring的配置机制。Spring容器的任务就是接受你为应用程序指定的蓝图并“实现它”。应用程序蓝图让Spring对应用程序的内部工作机制有了深入的了解。我们稍后再回到这个想法...当基于Spring的应用程序部署到生产环境中时会发生什么？在一个典型的场景中，有多个协同工作的组件需要配置和连接。例如，一个HTTP服务器在多个tc Server实例之间进行负载均衡，而这些实例又与配置为主从模式的数据库通信。这些（中间件）组件构成了应用程序的逻辑层（这里使用“大型”应用程序的概念）。逻辑层在实际部署中映射到物理层（例如，你可以将数据库和应用服务器部署在同一台机器上，或者不同的机器上）。当这个术语首次被发明时，物理层确实是物理的。但如今，你的物理层当然可能是虚拟的，而这些虚拟机又反过来映射到物理资源上......跟上我的思路了吗？
正如我们有一个描述Spring应用程序组件及其如何协同工作的应用程序蓝图一样，部署蓝图可以描述给定部署场景中的组件——有哪些组件，它们如何连接和配置，以及如何处理安全性、（反）亲和性等横切关注点。作为起点，有一些常见的部署模式（例如我前面提到的tc Server集群示例）可以被记录在目录中。随着时间的推移，你可以想象运维团队会用他们自己的自定义应用程序部署蓝图来扩展该目录。
从部署蓝图到vApp
将应用程序投入生产应该就像开发一个带有相关应用程序蓝图的应用程序一样简单，选择适合应用程序风格（例如 Web 应用程序、批处理、集成等）的部署蓝图，然后点击“部署”。你已经可以看到这种模式的早期实践示例，例如 CloudFoundry 在 Amazon EC2 上对 Web 应用程序部署蓝图的支持。VMware vSphere 支持一种称为 vApp 的概念。vApp 是一个“由一个或多个虚拟机组成的逻辑实体，它使用行业标准的开放虚拟化格式来指定和封装多层应用程序的所有组件，以及与之相关的操作策略和服务级别。”
vApps 是部署蓝图的完美打包单元。同一个 vApp 可以在你的数据中心和公共 vCloud 上得到支持。vApp 还可以暴露配置属性 - 运维人员在部署 vApp 时为这些属性提供值。
从dm Server开始（请关注即将发布的 2.0.0.M5 版本获取更多详细信息），我们正在使得我们的中间件能够通过 vApp 属性进行配置。这使得运维人员在部署 vApp 时可以覆盖端口和其他配置设置，而无需了解内部虚拟机或中间件组件的任何配置。此功能也超出了中间件组件的范围，你还可以配置应用程序属性（这些属性将由 Spring 进行依赖注入），这些属性来源于运维人员在部署时指定的 vApp 属性。
这些功能可以通过许多有趣的方式组合，但让我重点介绍两个我认为能够说明此处潜力的示例：平台即服务（PaaS）模型；以及应用设备模型。在平台即服务模型中，你的数据中心，或任何已签约成为 vCloud 服务提供商的多个供应商之一，会提供一个可供选择的部署蓝图目录。这些蓝图中的每一个都可以视为（PaaS 意义上的）平台，你可以将应用程序部署到其中。你选择要部署到的平台，相应的 vApp 将为你进行配置（可能带有允许你指定蓝图公开的任何 vApp 属性的 Web 前端），然后你将应用程序 artifact(s) 上传到已配置并正在运行的平台实例。对于使用Grails 或Roo 构建的应用程序（对于这些应用程序，我们对它们的结构了解得更多），可以通过插件直接从 Grails（或 Roo）命令行中选择部署蓝图和上传 artifact。想想这种模型将为这类应用程序打开的托管机会！
在应用设备模型中，开发或运维团队选择一个起始部署蓝图，创建一个相应 vApp 的实例，然后将应用程序 artifact 安装到正在运行的系统中。到目前为止，这看起来与 PaaS 模型非常相似。接下来的事情就不同了。将虚拟机（现在已经安装了应用程序 artifact）打包成一个新的 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。