一、前言
随着技术的不断更新迭代，发展出了很多本来是便于软件研发、维护的规范及工具，但有的时候此类技术封装的比较深，会导致我们各种无从下手。例如最近各种应用都强制要求打docker镜像，现场直接跑在arterydocker上面，但docker带来便捷之处的同时，也给我们带来了一些不便（除了不能犹如以前一样随时给现场替换个文件，增加一些日志外，这个技术的学习成本也不低）。某应用就是全部用docker部署，疑难问题排查起来各种费劲，但限于本人对docker不熟（门外汉，脚都没抬起来的那种），所以想到一个取巧的方案（调试时使用.jar启动，正式环境依然用docker），抛砖引玉，希望各位同事多多指导。
二、过程
2.1、研发相关工作
2.1.1、按需调整应用代码
大部分为增加日志输出，或者其他实验性的代码
给现场的代码需经过最低团队高工的人工审查，毕竟是生产环境，出了风险我们担不起
给现场的代码需经过最低团队高工的人工审查，毕竟是生产环境，出了风险我们担不起
给现场的代码需经过最低团队高工的人工审查，毕竟是生产环境，出了风险我们担不起
2.1.2、研发打包.jar版本的应用包
直接用maven命令打包即可，前提是写好了应用可编译成springboot版本jar的pom配置，此处不展开讲
2.2、运维相关工作（也可能是实施的同事）
2.2.1、创建app的测试路径
Windows：如E:\app-server
Linux：如/usr/local/thunisoft/app-server
2.2.2、复制app.jar到对应目录下
2.2.3、书写启动脚本
Windows（推荐脚本命名：startApp本服务的端口号.bat，例如startApp9999.bat）：
@echo off
rem 修改窗口标题
title app-9999
rem 修改中文乱码
chcp 65001
rem 启动springboot应用（下面包含应用依赖配置清单，请注意查看）
rem --server.port=9999 服务的对外端口号，根据实际需要配置即可，其他服务指向该服务的IP+端口
rem java -jar app.jar 命令是固定的，后面的就是应用启动参数，参数值前面加俩杠--，直接把docker里面的配置逐项添加上即可，docker中没有的配置可以不添加
rem 示例配置
java -jar app.jar --server.port=9999 --spring.myconfig=abc
Linux（推荐脚本命名：startApp本服务的端口号.sh，例如startApp9999.sh）:
# 启动springboot应用（下面包含应用依赖配置清单，请注意查看）
# --server.port=9999 服务的对外端口号，根据实际需要配置即可，其他服务指向该服务的IP+端口
# java -jar app.jar 命令是固定的，后面的就是应用启动参数，参数值前面加俩杠--，直接把docker里面的配置逐项添加上即可，docker中没有的配置可以不添加
# 示例配置
# 末尾的`> ./app.nohup 2>&1 &`是后台运行，不需要修改
nohup java -jar app.jar --server.port=9999 --spring.myconfig=abc > ./dossier.nohup 2>&1 &
2.2.4、运行shell脚本（推荐为startAppXXXX.bat或startAppXXXX.sh）
Windows：
直接双击命令文件即可
PS：分享一个windows上批处理命令运行闪退的排查小技巧。可以在bat文件所在的文件夹地址栏直接输入cmd（或者按下Shift+鼠标右键，或者其他方式无所谓，主要是打开命令窗口），在新打开的命令窗口中输入我们的命令文件并回车，这时候就可以看到运行命令的报错信息了
PSS：另外各种路径里面尽量不要包含中文，不要包含空格或括号等特殊字符（尤其是64位操作系统中C:\Program Files (x86)路径尽量不要使用），否则不一定什么时候就不兼容了
Linux：
sh 命令文件
2.2.5、验证新服务是否正常启动
在浏览器中输入地址并回车，查看页面是否可正常访问：http://新部署服务的IP:新部署服务的端口/swagger-ui.html，
例如http://ip:port/swagger-ui.html
或者http://ip:port/actuator/info
2.2.6、把docker中原来指向app服务的地址全部换为新地址并重启
2.2.7、验证整套应用是否可用（如果可用则直接每次修改日志，换一个jar即可快速试错）
2.2.8、更新app.jar（若不需要更新则后续的步骤可以忽略）
以下步骤主要是为了减少传输的文件包大小，甚至可以通过替换几个特定.class的方式来替换，见仁见智，自己根据实际场景决策即可
研发注意：使用maven打包后，在project\target中找到app.jar，并删除app.jar\BOOT-INF\lib\里面所有的依赖包（如果新包引用的jar清单有变更，则需要保证现场替换完后是最新的依赖清单）
现场注意：备份原有app.jar，把新的app.jar放入之前的位置，从原来app.jar\BOOT-INF\lib\中复制所有的*.jar到研发新给的app.jar对应目录中，然后重启服务即可
PS：普通的war和单层的jar使用以上方式一般情况下没有问题，但是springboot是双层jar，推荐直接使用同版本的jar命令来打包。
解压命令没什么不同，直接使用`jar -xvf app.jar`即可
压缩命令需要注意，需要单独增加M和0的参数控制，如`jar -cvfM0 app.jar ./*`（M代表不更新MANIFEST.MF文件，否则会重新生成一个该文件，丢失springboot特性；0代表不压缩，如果不写会导致lib下的jar无法被正确加载）
三、结语
1、注意以上步骤只是为了方便研发排查现场问题书写，正式环境一定不能使用springboot直接启动app.jar，应该继续使用docker的app服务。只不过因为docker里面无法直接替换文件，不方便添加日志排查错误才书写的本步骤
2、如果有其他小伙伴有更好的docker版本应用调试经验也可以一起讨论一下，教会徒弟的同时自己理解会更加深刻，所以不用怕饿死师傅的事儿
3、一直没抽出时间来学docker，希望会docker的各位前辈可以抽出一点儿时间来给大家多普及一下docker的使用经验，这样后续骚扰你们的次数也减少了，两全其美岂不快哉？