搶先一步
VMware 提供培訓和認證，以加速您的進展。
了解更多虛擬化 & 企業級 Java
如果您想從策略層面了解 VMware 近期宣布收購 SpringSource 的意涵，有幾個不錯的資訊來源，包括 Steve Herrod（VMware 技術長）的部落格文章、Rod Johnson 的評論、 Paul Maritz 的媒體與分析師電話會議，以及 Darryl Taft 在 eWeek 上發表的精闢文章。
在這篇文章中，我將更著重於這一切在技術層面上的意義，讓您了解您可以期待哪些功能。
首先，讓我重申，關於我們的開放原始碼專案和 SpringSource 產品，一切維持不變。除了我們未來將有更多機會為它們添加令人興奮的新功能之外，一切都不會改變。Spring 3.0 即將推出，而我們剛剛發布了 milestone 4。dm Server 正朝著 2.0 版本 快速邁進，而且我們為即將發布的 tc Server 準備了一些非常酷的功能。針對 Groovy 的 Eclipse 工具支援 引起了廣泛的興趣，Grails 正朝著 1.2 版本 邁進，並且在我們的 Spring 專案中發生了令人興奮的事情。所有這些都將持續快速發展。
藍圖的力量
每個 Spring 驅動的應用程式都有我們稱之為「應用程式藍圖」的東西。 這個藍圖包含構成應用程式的所有組件（beans）的描述、它們如何配置和連接、它們如何與周圍環境互動，以及如何處理安全性與交易等跨領域關注點。藍圖在運行時由 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 是「一個邏輯實體，包含一個或多個虛擬機器，它使用行業標準的開放虛擬化格式來指定和封裝多層應用程式的所有組件，以及與之相關的營運政策與服務等級。」
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。