网站建设情况调查表,手机网站功能,泰安人才网最新招聘,seo发帖网站您是否在生产中部署和取消部署基于JVM的应用程序#xff08;无论JVM容器/无容器#xff09;#xff1f; 也就是说#xff0c;当您拥有某个应用程序或服务的新版本时#xff0c;是否通过“取消部署”和“热部署”该应用程序的新更新版本来更改正在运行的JVM#xff1f; 或… 您是否在生产中部署和取消部署基于JVM的应用程序无论JVM容器/无容器 也就是说当您拥有某个应用程序或服务的新版本时是否通过“取消部署”和“热部署”该应用程序的新更新版本来更改正在运行的JVM 或者您是否尝试在运行时将应用程序的部署从一个JVM“移动”到另一个JVM 许多流行的JVM的功能使您可以执行此操作。 无论是高级Java EE容器流行的servlet容器甚至是OSGI容器由于各种原因我们都可以在运行时轻松地取消部署和部署应用程序。 但是我问这是一个好习惯吗 也许只有我一个人但是我真的认为这是绝对可怕的做法。 但是您的运营/ DevOps团队在做什么 我想从“不可变基础架构”的角度快速撰写博客该基础随着Linux容器格式开始的DevOps工具更改而得以保持。 James Strachan最近在他的博客中写了关于Docker对JVM生态系统的影响的文章他在使用Docker 容器时Java应用服务器的数量下降 。 如果您还没有阅读我鼓励您。 他谈到的一件事是当动态取消部署和热部署应用程序时JVM对内存泄漏的敏感性。 一次重新部署后您可能最终会遇到由于泄漏的对象类结构数据库连接套接字线程类加载器等原因而导致不稳定或不可预测的系统。 在某些情况下泄漏这些物体很 容易 做到 因此也许通过热部署/重新部署破坏我们的运行时部署是一件坏事。 那么我们有什么选择呢 如何使用新配置和部署的应用程序来启动有问题的JVM的新实例控制我们有关启动顺序和部署配置的一切。 然后我们可以将流量从较旧的实例定向到较新的实例并在适当的时间终止较旧的实例。 这够了吗 好吧这个问题直接针对新应用程序和服务的新排列新版本新配置以及未更改的事物例如代码部署的服务等是否经过了正确的测试。 。 我个人将要部署到生产环境中的应用程序和服务的任何组合所做出的假设是已经对相同的排列进行了完全测试 就像在较低环境中一样。 也就是说确切的集合已经部署在DEVQAISTUAT产品镜像产品等中。更改生产中服务的唯一方法是在较低的环境中正确测试它们。 这种思路是基于强大的自动化一致的测试以及一套将变更从最初的系统移植到生产系统的既定学科和流程。 Linxu容器和图像格式为实现此目的而对工具进行了巨大改进但即使在今天即甚至在您能够使用Docker / Rocket /图像格式之前也都可以灌输思维定势和这些最佳实践。 不要在运行时热部署/重新部署/迁移生产中的Java服务 确实非常关注您的交付管道/自动化/测试以快速更改系统 翻译自: https://www.javacodegeeks.com/2015/05/immutable-infrastructure-hotdeploys-and-the-jvm.html
