网站设计有限公司怎么样,企业微信开发,那个网站建设,河北病例最新情况jvm虚拟机 基于栈部署体系结构设计是任何定制服务器端应用程序开发项目的重要组成部分。 由于其重要性#xff0c;部署架构设计应尽早开始#xff0c;并与其他开发活动一起进行。 部署体系结构设计的复杂性取决于许多方面#xff0c;包括所提供服务的可伸缩性和可用性目标部署架构设计应尽早开始并与其他开发活动一起进行。 部署体系结构设计的复杂性取决于许多方面包括所提供服务的可伸缩性和可用性目标部署过程以及系统体系结构的技术属性。 可维护性和操作问题例如部署安全性监视备份/还原等与部署体系结构设计的更广泛主题相关。 这些问题本质上是跨领域的可能需要从服务推出过程到实际系统管理细节的不同层次上加以解决。 在系统管理详细信息级别使用纯基于JVM的应用程序部署模型在类似Unix的平台上时经常会遇到以下挑战 如何安全关闭应用服务器或应用程序 通常使用侦听关闭请求的TCP侦听器线程。 如果您在同一主机上部署了同一应用服务器的许多实例则有时很容易混淆这些实例并关闭错误的实例。 另外您还必须防止未经授权访问关机监听器。 创建与系统启动和关闭机制例如Sys-V initsystemdUpstart等无缝集成的初始化脚本 如果应用程序死了如何自动重启 日志文件管理。 应用程序日志可以通过日志库进行管理例如旋转压缩删除。 有时也可以使用日志库来管理应用服务器或平台日志但有时可能需要与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“ -XXOnOutOfMemoryError”和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。盒子。 翻译自: https://www.javacodegeeks.com/2014/07/daemonizing-jvm-based-applications.htmljvm虚拟机 基于栈
