領先一步
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。