虚拟化与企业级 Java

工程 | Adrian Colyer | 2009年8月13日 | ...

如果你想从战略层面了解 VMware 最近宣布收购 SpringSource 的影响,有几个不错的资源,包括Steve Herrod(VMware 首席技术官)的博客文章Rod Johnson 的评论Paul Maritz 的新闻发布会和分析师电话会议以及Darryl Taft 在 eWeek 上发表的富有见地的文章

在这篇文章中,我将更多地关注这在技术层面意味着什么,让你了解可以期待的各种功能。

首先,让我重申一下,就我们的开源项目和 SpringSource 产品而言,没有任何变化。也就是说,除了未来我们将有更多机会为它们添加令人兴奋的新功能之外,没有任何变化。Spring 3.0 即将到来,我们刚刚发布了里程碑版本 4dm Server 正在快速发展,即将发布2.0 版本,我们还为即将发布的 tc Server 版本准备了一些非常酷的东西。 Groovy 的 Eclipse 工具支持 正在引起广泛关注,Grails 正在向1.2 版本推进,我们的 Spring 项目中正在发生令人兴奋的事情。所有这些都将继续快速发展。

蓝图的力量

每个 Spring 驱动的应用程序都有我们所谓的“应用程序蓝图”。此蓝图包含对构成应用程序的所有组件(bean)的描述,它们如何配置和连接,它们如何与周围环境交互,以及如何处理安全和事务等横切关注点。蓝图在运行时由一组BeanDefinitions表示。BeanDefinitions 来自各种来源,包括 XML 定义、注释、JavaConfig、Groovy DSL 以及任何可以插入 Spring 的其他配置机制。Spring 容器的任务是获取你为应用程序指定的蓝图并“实现它”。应用程序蓝图使 Spring 能够深入了解应用程序的工作原理。我们稍后会回到这个想法……

当 Spring 驱动的应用程序在生产环境中部署时会发生什么?在典型场景中,多个协同工作的组件需要配置和连接。例如,一个http 服务器 在一组tc Server 实例上进行负载均衡,而这些实例又与以主/从设置配置的数据库进行通信。这些(中间件)组件构成应用程序的逻辑层(现在使用“大型”应用程序这个术语)。逻辑层映射到实际部署中的物理层(例如,你可以在同一台机器上或不同的机器上部署数据库和应用程序服务器)。当首次发明此术语时,物理层确实是物理的。但如今,你的物理层当然可能是虚拟的,而这些虚拟机又映射到物理资源…… 还在听吗?

tc Server farm deployment blueprint

正如我们有一个应用程序蓝图来描述 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 属性。

vApp 配置 这些功能可以结合起来实现许多有趣的方式,但我只想选择我认为可以说明其潜力的两种方式:平台即服务 (PaaS) 模型;以及应用程序设备模型

在平台即服务模型中,你的数据中心或任何注册为 vCloud 服务提供商的多个供应商都会提供可供选择的部署蓝图目录。每个蓝图都可以被认为是平台(在 PaaS 中),你可以将应用程序部署到其中。你选择要部署到的平台,相应的 vApp 将代表你进行配置(也许有一个 Web 前端允许你指定蓝图公开的任何 vApp 属性),然后你将应用程序工件上传到已配置并正在运行的平台实例。对于使用GrailsRoo构建的应用程序,如果我们对应用程序的结构有更深入的了解,则可以通过插件从 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 服务器管理为单个逻辑资源),自动添加清单,并默认设置合适的控制操作和警报。无需手动安装和配置任何内容。

智能运行时管理

智能配置很棒,但这并非全部。vSphere 包含复杂的机制,可在运行时优化您的虚拟机和数据中心使用情况。迄今为止,这些机制在运行时并未了解虚拟机试图支持的应用程序。当您将 Hyperic HQ 提供的应用程序洞察与 vCenter 提供的虚拟基础设施洞察相结合时,就可以创建组合的应用程序健康和管理模型,该模型可根据应用程序 SLA 优化运行时。例如,如果 HQ 检测到来自 tc 服务器节点的响应时间接近 SLA 中指定的上限,并且这与显示 CPU 或内存成为瓶颈的指标相关,则可以使用多种纠正措施,包括为现有服务器上的虚拟机分配更多物理资源,使用vMotion将虚拟机迁移到更强大的硬件,或启动其他 tc 服务器虚拟机以分担负载。

关于向上(或向下)扩展,扩展点只是部署蓝图中的另一段元数据,“1..n”(或“3..8”,或您决定的任何值)表示扮演此角色的服务器数量。指定后,只需让 Hyperic HQ 和 vCenter 协同工作来管理和优化服务器数量即可(甚至可以关闭暂时不需要的物理机器以节省能源成本)——所有这些都基于您指定的应用程序 SLA 和虚拟基础设施 SLA。

触手可及

虽然在本博文中我主要关注实际的生产部署,但此技术在开发过程中也具有难以置信的价值。想象一下,拥有一个虚拟机目录,其中包含应用程序必须运行的所有不同环境(不同的浏览器、操作系统、应用程序服务器等,视情况而定),并且能够直接从您的 IDE 中启动并在任何一个环境中测试您的应用程序。想象一下,能够在 QA 期间发生难以重现的错误时拍摄一组虚拟机的状态快照,然后让开发人员直接从SpringSource Tool Suite中启动和分析他们自己的 VM 副本。想象一下,能够在具有代表性的生产环境中运行基本的规模和性能测试,而无需实际设置一个生产环境。想象一下……

接受挑战……

又一波创新浪潮,另一个行业颠覆点。在 SpringSource,我们热爱并擅长应对这些挑战。接受挑战!

获取 Spring 新闻通讯

通过 Spring 新闻通讯保持联系

订阅