jvm虚拟机基于栈_守护基于JVM的应用程序

jvm虚拟机基于栈

部署体系结构设计是任何定制服务器端应用程序开发项目的重要组成部分。由于其重要性，部署架构设计应尽早开始，并与其他开发活动一起进行。部署体系结构设计的复杂性取决于许多方面，包括所提供服务的可伸缩性和可用性目标，部署过程以及系统体系结构的技术属性。

可维护性和操作问题，例如部署安全性，监视，备份/还原等，与部署体系结构设计的更广泛主题相关。这些问题本质上是跨领域的，可能需要从服务推出过程到实际系统管理细节的不同层次上加以解决。

在系统管理详细信息级别，使用纯基于JVM的应用程序部署模型（在类似Unix的平台上）时，经常会遇到以下挑战：

如何安全关闭应用服务器或应用程序？通常，使用侦听关闭请求的TCP侦听器线程。如果您在同一主机上部署了同一应用服务器的许多实例，则有时很容易混淆这些实例并关闭错误的实例。另外，您还必须防止未经授权访问关机监听器。
创建与系统启动和关闭机制（例如Sys-V init，systemd，Upstart等）无缝集成的初始化脚本
如果应用程序死了，如何自动重启？
日志文件管理。应用程序日志可以通过日志库进行管理（例如，旋转，压缩，删除）。有时也可以使用日志库来管理应用服务器或平台日志，但有时可能需要与OS级工具集成（例如logrotate）。

对于这些问题，有两种解决方案可以使操作系统与应用程序/应用程序服务器之间的集成更加紧密。一种广泛使用的通用解决方案是Java Service Wrapper 。 Java Service Wrapper擅长解决上述挑战，并且根据专有许可发布。还提供了基于GPL v2的社区许可选项。

Apache commons守护程序是另一个选择。它的根源是Apache Tomcat，并且与应用服务器很好地集成在一起，但它的通用性要强得多。除Java外，commons守护程序还可以与其他基于JVM的语言（例如Scala）一起使用。顾名思义，commons守护程序是Apache许可的。

Commons守护程序包括以下功能：

如果JVM死亡，将自动重启
使用标准OS机制启用JVM进程的安全关闭（基于Tomcat TCP的关闭机制容易出错且不安全）
重定向STDERR / STDOUT并设置JVM进程名称
允许与OS初始化脚本机制集成（记录JVM进程pid）
将JVM进程与父进程和控制台分离
以减少的OS特权运行JVM和应用程序
允许与OS工具（例如logrotate）协调日志文件管理（使用SIGUSR1信号重新打开日志文件）

部署Commons守护程序

从应用程序开发人员的角度来看，commons守护程序由两部分组成：用于启动应用程序的jsvc二进制文件和commons守护程序Java API。在启动期间，jsvc二进制文件通过应用程序实现的生命周期方法来引导应用程序，并由commons守护程序Java API定义。 Jsvc创建一个控制过程，以在异常终止时监视和重新启动应用程序。这是与应用程序一起部署commons守护程序的概述：

在应用程序引导程序类中实现commons守护程序API生命周期方法（请参阅直接使用jsvc ）。
编译并安装jsvc。（请注意，通常不建议在生产或QA服务器上安装编译器工具链）。
将commons-daemon API放在应用程序类路径中
找出用于通过jsvc运行应用程序的命令行参数。查阅Tomcat发行版中的bin / daemon.sh以获取参考。
根据上一步创建适当的初始化脚本。 Tomcat可以通过程序包管理器安装在许多Linux发行版上，并且该程序包通常带有一个可用作参考的初始化脚本。

实践经验

Tomcat发行版包括“ daemon.sh”，这是一个通用包装外壳脚本，可用作创建特定于系统的初始化脚本变体的基础。我遇到的问题之一是包装脚本的调用者无法覆盖wait配置参数的默认值。在某些情况下，Tomcat随机数生成器的初始化可能会超过最大等待时间，从而导致初始化脚本报告失败，即使最终启动应用程序服务器也是如此。现在似乎已解决此问题。

另一个问题是包装器脚本不允许传递带有空格的JVM参数。例如与JVM“ -XX：OnOutOfMemoryError”和co一起使用时，这可能很方便。参数。使用包装脚本是可选的，也可以轻松更改，但由于它包含一些有用的功能，因此我宁愿重用而不是复制它，因此我创建了一个功能请求并为此＃55104提出了一个小补丁。

在找出正确的命令行参数以使jsvc引导您的应用程序时，“-debug”参数对于进行故障排除非常有用。另外，默认情况下，jsvc将工作目录更改为/，在这种情况下，绝对路径通常应与其他选项一起使用。 “ -cwd”选项可用于覆盖默认的工作目录值。

守护码头

除Tomcat外，Jetty是我经常使用的另一个servlet容器。由于集成已经存在，因此将common守护程序与Tomcat结合使用不会带来任何挑战，因此我决定了解一下如何在不支持common守护程序的应用服务器上正常工作。

为了在Jetty中实现必要的更改，我克隆了Jetty源代码存储库，在Jetty bootstrap类中添加了jsvc生命周期方法，并构建了Jetty。之后，我开始尝试使用jsvc命令行参数来引导Jetty。 Jetty附带了jetty.sh启动脚本，该脚本具有称为“ check”的选项，用于输出与安装相关的各种信息。除其他外，它输出将与JVM一起使用的命令行参数。这为jsvc命令行提供了一个很好的起点。

这些是我最终得到的命令行：

export JH=$HOME/jetty-9.2.2-SNAPSHOT
export JAVA_HOME=`/usr/libexec/java_home -v 1.8`
jsvc -debug -pidfile $JH/jetty.pid -outfile $JH/std.out -errfile $JH/std.err -Djetty.logs=$JH/logs -Djetty.home=$JH -Djetty.base=$JH -Djava.io.tmpdir=/var/folders/g6/zmr61rsj11q5zjmgf96rhvy0sm047k/T/ -classpath $JH/commons-daemon-1.0.15.jar:$JH/start.jar org.eclipse.jetty.start.Main jetty.state=$JH/jetty.state jetty-logging.xml jetty-started.xml

这可以用作适当的生产级初始化脚本的起点，以启动和关闭Jetty。

我在Jetty项目问题跟踪器中将我的代码更改作为问题＃439672提交，并且刚刚得知更改已与上游代码库合并，因此您将来应该可以使用Apache commons守护程序jsvc来守护Jetty。盒子。