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

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

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

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

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

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

因此，也許通過(guò)熱部署/重新部署破壞我們的運(yùn)行時(shí)部署是一件壞事。

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

這夠了嗎？

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

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

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

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

總結(jié)

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

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