現代應用程式中非人為產生的資料量之大，很容易超過傳統的單執行緒、阻塞式設計模型。 Reactor 旨在解決這個問題，它為 JVM 應用程式提供了一個基礎框架 - 這些應用程式在執行相當小的、無狀態的、非同步的處理時，需要高輸送量。 加入 Jon Brisbin，他將討論該專案背後的動機、啟發該專案的設計模式和現有技術，以及它如何融入當今的非同步生態系統，作為他即將在 SpringOne 2GX 2013 上發表的會議內容的預告。

此會議分享了在 vSphere 上執行 Java 的許多經過生產驗證的方法。 涵蓋如何調整 JVM 的大小，以及大規模部署的 VM。 該會議將有一個關於 GC 調整的特殊部分，並展示如何使用過去 15 年在 JVM 調整方面的實際領域經驗中開發的 GC 配方來調整各種 JVM。

本次會議討論了三個主要趨勢和相關的調整技術。 主要趨勢是：整合、彈性和靈活性以及效能

整合 我們的許多客戶發現他們的中介軟體部署已經擴散，並且正在成為與更高成本相關的管理挑戰。 我們看到客戶存在一種趨勢，他們尋求將虛擬化作為減少伺服器實例數量的一種方式。 同時，客戶正在利用整合的機會來合理化服務特定負載所需的中介軟體組件的數量。 中介軟體組件最常在 Java 虛擬機 (JVM) 中執行，觀察到的規模為 100 到 1000 個 JVM 實例，並為 JVM 實例整合提供了許多機會。 因此，中介軟體虛擬化提供了兩次整合的機會 – 一次是整合伺服器實例，第二次是整合 JVM 實例。 這種趨勢影響深遠，因為地球上的每個 IT 部門都在考慮整合的成本節省。 飯店業的一位客戶完成了整合伺服器佔用空間的過程，同時也整合了許多小於 1GB 堆積的較小 JVM。 他們將許多這些較小的 1GB JVM 整合為 2 個類別，一個是 4GB，另一個是 6GB。 他們以這樣的方式進行整合，使得應用程式可用的 RAM 總量等於原始 RAM 量，但 JVM 實例更少。 他們在提高效能並維持良好的 SLA 的同時，完成了所有這些工作。 由於他們必須管理的 JVM 實例數量減少，以及有助於輕鬆實現 SLA 的精簡環境，他們也大大降低了管理成本。
保險業的另一位客戶能夠實現與上述客戶相同的目標，但此外還能夠在開發和 QA 環境中過度分配 CPU，以節省第三方軟體授權成本。 另一方面，有時我們會遇到客戶，他們有合法的業務需求來為應用程式維護一個 JVM，和/或為一個業務線維護一個 JVM。 在這些情況下，您無法真正整合 JVM 實例，因為這會導致一個業務線的一個應用程式的生命週期與另一個應用程式的生命週期相互混合。 然而，雖然這些客戶無法透過 JVM 整合來消除額外的 JVM 實例而受益，但他們確實可以從更充分地利用伺服器硬體上可用的運算資源中受益，否則這些運算資源在非虛擬化環境中將未得到充分利用。

彈性和靈活性 越來越常見的是發現具有季節性需求的應用程式。 例如，我們的許多客戶會運行各種行銷活動，將季節性流量導向他們的應用程式。 透過 VMware，您可以透過在需要時自動配置新的虛擬機和中介軟體組件，然後在負載消退時自動關閉這些 VM 來處理這種流量爆發。 此外，在不造成停機的情況下變更更新/修補硬體的能力對於支援雲端時代規模和正常運行的中介軟體至關重要。 VMware VMotion 使您無需停止應用程式和/或 VM 即可移動 VM。 僅這種靈活性就使得在管理大規模中介軟體部署時虛擬化中介軟體是值得的。 金融領域的一位客戶每天處理數百萬筆交易，經常使用 VMotion 來安排他們的硬體升級，而無需任何停機時間。 否則，這將是他們業務的一項代價高昂的計劃性停機。

效能 客戶經常報告說，在虛擬化時中介軟體平台的效能有所提高。 效能的提高部分是由於客戶通常會在虛擬化專案期間更新的硬體。 由於強大的 VMware Hypervisor，效能也有所提高。 最近一位報告了很高效能水準的客戶提供了以下證詞

「透過我們的 OrderExpress 專案，我們升級了我們的中介軟體服務、商務、入口網站、WCM、服務層、DB2 資料庫； 從 AIX 遷移到 Linux； 在 VMware 上進行虛擬化； 將應用程式移至三層 DMZ； 將我們的交易量提高了 150% 以上； 並添加了重要的新功能，大大改善了客戶體驗。 一次性變更如此廣泛的技術組件是一個巨大的挑戰。 然而，透過使用 VMware vSphere 和額外的架構變更，我們成功地將效能提高了 300% 以上； 將成本降低了數百萬； 提高了安全性、可用性和可擴展性； 以及我們計劃如何繼續發展此應用程式，以保持每年超過 30% 的成長。」

– Jeff Battisti，Cardinal Health 高級企業架構師

在本會議中，我將展示一些適用於小型和大型 JVM 的中介軟體組件的實際 JVM 和 VM 大小。 還將詳細介紹我多年來開發的 GC 調整配方，該配方已顯示可以處理從 4GB 到 88GB+ 及以上的 JVM 堆積大小。 當然，記憶體資料庫的引入推動了擁有這些較大 JVM 的趨勢，因此我們將討論調整 JVM、VM 和它們部署所在的硬體平台的最佳方式。

我認為大小調整問題是我們的客戶群最常問的問題，因此我計劃在會議期間重點關注它。

基於 Actor 的並行模型是一種典範轉移。什麼是典範轉移？

科學理論統治下，基本假設或典範的改變。典範轉移使簡單的想法難以理解。即使 Actor 模型是一個簡單且革命性的想法，程式設計師也很難看到實際的好處和用法。同樣地，Scala 程式語言在簡化基於 Actor 的設計方面帶來了很多好處，但同時也帶來了一種新的編碼風格。解決這個問題的一個可能方法是根據舊的典範來評估新的典範。在本次演講中，我們將採用一個基於 Spring 的實際 Web 應用程式，並逐步使用 Actor 和 Scala 來實現它。我們將對新的想法持懷疑和猜忌的態度，但同時我們也會持開放的態度。我們將利用 Spring 的知識來學習基於 Actor 的並行模型。同時，我們也將學習 Actor、Scala 以及將它們與 Spring Framework 結合的最佳實踐。