领先一步
VMware 提供培训和认证,以加速您的进步。
了解更多如果你想从战略层面了解 VMware 最近宣布收购 SpringSource 的影响,有几个不错的资源,包括Steve Herrod(VMware 首席技术官)的博客文章、Rod Johnson 的评论、Paul Maritz 的新闻发布会和分析师电话会议以及Darryl Taft 在 eWeek 上发表的富有见地的文章。
在这篇文章中,我将更多地关注这在技术层面意味着什么,让你了解可以期待的各种功能。
首先,让我重申一下,就我们的开源项目和 SpringSource 产品而言,没有任何变化。也就是说,除了未来我们将有更多机会为它们添加令人兴奋的新功能之外,没有任何变化。Spring 3.0 即将到来,我们刚刚发布了里程碑版本 4。 dm Server 正在快速发展,即将发布2.0 版本,我们还为即将发布的 tc Server 版本准备了一些非常酷的东西。 Groovy 的 Eclipse 工具支持 正在引起广泛关注,Grails 正在向1.2 版本推进,我们的 Spring 项目中正在发生令人兴奋的事情。所有这些都将继续快速发展。
当 Spring 驱动的应用程序在生产环境中部署时会发生什么?在典型场景中,多个协同工作的组件需要配置和连接。例如,一个http 服务器 在一组tc Server 实例上进行负载均衡,而这些实例又与以主/从设置配置的数据库进行通信。这些(中间件)组件构成应用程序的逻辑层(现在使用“大型”应用程序这个术语)。逻辑层映射到实际部署中的物理层(例如,你可以在同一台机器上或不同的机器上部署数据库和应用程序服务器)。当首次发明此术语时,物理层确实是物理的。但如今,你的物理层当然可能是虚拟的,而这些虚拟机又映射到物理资源…… 还在听吗?
正如我们有一个应用程序蓝图来描述 Spring 驱动的应用程序的组件以及它们如何组合在一起一样,一个部署蓝图可以描述给定部署场景的组件——有哪些组件,它们如何连接和配置,以及如何处理安全和(反)亲和性等横切关注点。作为起点,有一些常见的部署模式(例如我前面提到的 tc Server 集群示例)可以捕获到目录中。随着时间的推移,你可以想象一个运维团队使用他们自己的自定义蓝图来扩展该目录以进行应用程序部署。
VMware vSphere 支持称为 vApp 的概念。vApp 是“包含一个或多个虚拟机的逻辑实体,它使用行业标准的开放虚拟化格式来指定和封装多层应用程序的所有组件,以及与其相关的操作策略和服务级别”。
vApp 是体现部署蓝图的完美打包单元。相同的 vApp 可以在你的数据中心和公共vCloud 上受支持。vApp 还可以公开配置属性——操作员在部署 vApp 时为这些属性提供值。
从dm Server 开始(注意即将发布的 2.0.0.M5 版本中的更多详细信息),我们正在使我们的中间件能够通过 vApp 属性进行配置。这使操作员能够在部署 vApp 时覆盖端口和其他配置设置,而无需了解虚拟机或内部中间件组件的配置。此功能也扩展到中间件组件之外,你还可以配置应用程序属性(这些属性将由 Spring 进行依赖注入),这些属性来自操作员在部署时指定的 vApp 属性。
在平台即服务模型中,你的数据中心或任何注册为 vCloud 服务提供商的多个供应商都会提供可供选择的部署蓝图目录。每个蓝图都可以被认为是平台(在 PaaS 中),你可以将应用程序部署到其中。你选择要部署到的平台,相应的 vApp 将代表你进行配置(也许有一个 Web 前端允许你指定蓝图公开的任何 vApp 属性),然后你将应用程序工件上传到已配置并正在运行的平台实例。对于使用Grails 或Roo构建的应用程序,如果我们对应用程序的结构有更深入的了解,则可以通过插件从 Grails(或 Roo)命令行提供部署蓝图选择和工件上传。想想这种模型将为此类应用程序打开的托管机会!
在应用程序设备模型中,开发或运维团队选择一个起始部署蓝图,创建一个相应 vApp 的实例,并将应用程序工件安装到正在运行的系统中。到目前为止,这看起来与 PaaS 模型一样。但是下一步有所不同。虚拟机(现在已安装应用程序工件)打包为新的 vApp,并且每个部署中可能发生变化的任何特定于应用程序的属性(例如,如果 vApp 依赖于外部数据库,则为数据库 URL 和密码)都配置为 vApp 属性。因此,现在整个应用程序以及运行它所需的一切都打包为一个 vApp(应用程序设备),可以作为一个单元进行配置(并进行版本控制)。将应用程序投入生产然后变得像部署 vApp 一样简单——不会出错,一切都已预先打包和测试。
如果没有 Spring 提供的知识,vApp 就只是 vSphere 可以在其可用的物理资源上配置的虚拟机的集合。但是当使用应用程序蓝图和部署蓝图的知识进行配置时,事情会变得更加有趣。现在我们突然对应用程序和中间件组件以及它们如何连接有了某种了解,我们可以优化虚拟基础架构以支持它。例如
关于向上(或向下)扩展,扩展点只是部署蓝图中的另一段元数据,“1..n”(或“3..8”,或您决定的任何值)表示扮演此角色的服务器数量。指定后,只需让 Hyperic HQ 和 vCenter 协同工作来管理和优化服务器数量即可(甚至可以关闭暂时不需要的物理机器以节省能源成本)——所有这些都基于您指定的应用程序 SLA 和虚拟基础设施 SLA。