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

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

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

James Strachan最近在他的博客中寫了關(guān)于Docker對JVM生態(tài)系統(tǒng)的影響的文章，他在使用Docker 容器時Java應(yīng)用服務(wù)器的數(shù)量下降 。 如果您還沒有閱讀，我鼓勵您。

他談到的一件事是當(dāng)動態(tài)取消部署和熱部署應(yīng)用程序時，JVM對內(nèi)存泄漏的敏感性。 一次重新部署后，您可能最終會遇到由于泄漏的對象，類結(jié)構(gòu)，數(shù)據(jù)庫連接，套接字，線程，類加載器等原因而導(dǎo)致不穩(wěn)定或不可預(yù)測的系統(tǒng)。

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

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

那么我們有什么選擇呢？ 如何使用新配置和部署的應(yīng)用程序來啟動有問題的JVM的新實例，控制我們有關(guān)啟動順序和部署配置的一切。 然后，我們可以將流量從較舊的實例定向到較新的實例，并在適當(dāng)?shù)臅r間終止較舊的實例。

這夠了嗎？

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

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

• 不要在運行時熱部署/重新部署/遷移生產(chǎn)中的Java服務(wù)
• 確實非常關(guān)注您的交付管道/自動化/測試，以快速更改系統(tǒng)

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。