jvm 架構

您是否在生產中部署和取消部署基于JVM的應用程序（無論JVM容器/無容器）？ 也就是說，當您擁有某個應用程序或服務的新版本時，是否通過“取消部署”和“熱部署”該應用程序的新更新版本來更改正在運行的JVM？ 或者，您是否嘗試在運行時將應用程序的部署從一個JVM“移動”到另一個JVM？

許多流行的JVM的功能使您可以執行此操作。 無論是高級Java EE容器，流行的servlet容器，甚至是OSGI容器，由于各種原因，我們都可以在運行時輕松地取消部署和部署應用程序。 但是，我問，這是一個好習慣嗎？ 也許只有我一個人，但是我真的認為這是絕對可怕的做法。 但是您的運營/ DevOps團隊在做什么？

我想從“不可變基礎架構”的角度快速撰寫博客，該基礎隨著Linux容器格式開始的DevOps工具更改而得以保持。

James Strachan最近在他的博客中寫了關于Docker對JVM生態系統的影響的文章，他在使用Docker 容器時Java應用程序服務器的數量下降 。 如果您還沒有閱讀，我鼓勵您。

他談到的一件事是當動態取消部署和熱部署應用程序時，JVM對內存泄漏的敏感性。 一次重新部署后，您可能最終會遇到由于泄漏的對象，類結構，數據庫連接，套接字，線程，類加載器等原因而導致不穩定或不可預測的系統。

在某些情況下，泄漏這些物體很 容易 做到

因此，也許通過熱部署/重新部署破壞我們的運行時部署是一件壞事。

那么我們有什么選擇呢？ 如何使用新配置和部署的應用程序來啟動有問題的JVM的新實例，控制我們對啟動順序和部署配置所能進行的一切。 然后，我們可以將流量從較舊的實例定向到較新的實例，并在適當的時間終止較舊的實例。

這夠了嗎？

好吧，這個問題直接針對新應用程序和服務的新排列（新版本，新配置以及未更改的事物，例如，代碼部署的服務等）是否經過正確測試。 我個人將要部署到生產環境中的應用程序和服務的任何組合所做出的假設是，已經對相同的排列進行了完全測試， 就像在較低環境中一樣。 也就是說，確切的集合已經部署在DEV，QA，IST，UAT，產品鏡像，產品等中。更改生產中服務的唯一方法是在較低的環境中正確測試它們。

這種思路是基于強大的自動化，一致的測試，以及一套將變更從初始階段移植到生產階段的既定學科和流程。 Linxu容器和圖像格式為實現此目的而對工具進行了巨大改進，但即使在今天（即，甚至在您能夠使用Docker / Rocket /圖像格式之前），也可以灌輸思維定勢和這些最佳實踐。 ：

• 不要在運行時熱部署/重新部署/遷移生產中的Java服務
• 確實非常關注您的交付管道/自動化/測試，以快速更改系統

翻譯自: https://www.javacodegeeks.com/2015/05/immutable-infrastructure-hotdeploys-and-the-jvm.html

jvm 架構

總結

以上是生活随笔為你收集整理的jvm 架构_不可变的基础架构，热部署和JVM的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。