領先一步
VMware 提供培訓和認證，助您加速進步。
瞭解更多虛擬化與企業 Java
如果您想從戰略層面瞭解 VMware 最近宣佈收購 SpringSource 的影響，有幾個很好的來源，包括 VMware 首席技術官 Steve Herrod 的部落格文章、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）的描述、它們的配置和連線方式、它們與周圍環境的互動方式以及安全性和事務等跨領域關注點的處理方式。藍圖在執行時由BeanDefinition集合表示。BeanDefinition來源於各種來源，包括XML定義、註解、JavaConfig、Groovy DSLs以及任何可以插入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。